Verwenden eines Testupgrades auf SharePoint 2013 zum Ermitteln möglicher Probleme

Artikel
03/08/2023

GILT FÜR: yes-img-13 2013 no-img-16 2016 no-img-19 2019 no-img-se Subscription Edition no-img-sop SharePoint in Microsoft 365

Bevor Sie ein Upgrade von SharePoint 2010-Produkte auf SharePoint 2013 starten, sollten Sie den Upgradeprozess testen, um sicherzustellen, dass Ihnen die erforderlichen Schritte für ein erfolgreiches Upgrade bekannt sind. Ein Testupgrade zum Testen des Prozesses kann folgende Probleme aufzeigen:

Ob ein Upgradeplan funktioniert, oder ob er angepasst werden muss.
Die Anpassungen in Ihrer Umgebung, damit Sie deren Berücksichtigung während des Upgrade planen können.
Sollte die Hardware aktualisiert werden, damit das Upgrade effizienter und schneller ausgeführt werden kann?
Die Zeitplanung für das Upgrade bzw. die Dauer des Upgrades der Umgebung.
Welche Pläne müssen im Betrieb erstellt werden, welche Ressourcen müssen z. B. verfügbar sein?

Darüber hinaus können Sie das Testupgrade dazu verwenden, sich mit den Upgradetools und dem eigentlichen Vorgang vertraut zu machen, sodass Sie genau wissen, was Sie während des tatsächlichen Vorgangs erwartet. Durch die Tests können Sie folgende Probleme ermitteln:

Wie sieht die Upgradebenutzeroberfläche aus? Wie können Sie erkennen, wann eine Phase beendet ist und eine weitere Phase beginnt?
Wo befinden sich die Protokolldateien, und wie werden sie gelesen? Welche Informationen sind darin enthalten?
Ob während des Upgradeprozesses verwendete Skripte oder Befehle angepasst werden müssen, insbesondere Skripts, die bereits für das Upgrade auf SharePoint 2010-Produkte verwendet wurden.
Ob Ihr Plan für den Umgang mit Ausfällen geeignet ist.

In diesem Artikel werden grundlegende Schritte zum Testen des Upgrades beschrieben. Zudem sind Empfehlungen zum Überprüfen der Ergebnisse und zum Anpassen der Upgradepläne auf der Grundlage der während der Tests gewonnenen Erkenntnisse enthalten.

Darüber hinaus können die folgenden Ressourcen beim Testen des Upgradevorgangs hilfreich sein:

SharePoint 2013 - Modell zum Testen des Upgradevorgangs

Laden Sie das Poster SharePoint 2013 Products Preview - Modell zum Testen des Upgradevorgangs herunter, um eine grafische Darstellung der Informationen zum Testen des Upgradevorgangs zu erhalten.
Bewährte Methoden zum Testen des Upgradevorgangs finden Sie unter Bewährte Methoden beim Upgrade von SharePoint 2010 auf SharePoint 2013.

Einrichten einer Testumgebung

Zum Testen des Upgradevorgangs kann entweder virtuelle oder physische Hardware verwendet werden. Jede Umgebung ist einzigartig. Daher gibt es keine allgemeinen Richtlinien dafür, wie lange das Upgrade dauert oder wie schwierig das Upgrade einer bestimmten Anpassung sein wird. Die beste Möglichkeit, um zu beurteilen, wie das Upgrade ausgeführt wird, besteht darin, eine Reihe von Testupgrades durchzuführen.

Berücksichtigen Sie beim Erstellen der Testumgebung Folgendes:

Erstellen Sie die Testfarm möglichst ähnlich der realen Farm, z. B. in Bezug auf die verfügbare Hardware, Software und den verfügbaren Speicherplatz.
Verwenden Sie dieselben URLs in der Testfarm wie in der realen Farm. (Andernfalls werden Sie für die Diagnose von Problemen bezüglich der URLs viel Zeit aufwenden, die beim eigentlichen Upgrade gar nicht auftreten werden.) Sie können dazu dieselben URLs verwenden und nur auf Computern mit Hostdateiänderungen testen.
Verwenden Sie für Ihre Web- und Anwendungsserver unterschiedliche Computernamen.

Dadurch werden AD DS (Active Directory Domain Services)-Konflikte vermieden.
Verwenden Sie separate Server, auf denen SQL Server für Ihre Testfarm ausgeführt wird.

Wenn Sie die gleichen Server verwenden, auf denen SQL Server für Ihre Test- und Produktionsfarm ausgeführt wird, können Sie sich auf die Leistung Ihrer Produktionsfarm auswirken, während Sie die Tests ausführen. Es wird empfohlen, verschiedene SQL Server-Computer (nicht nur Instanzen) für Ihre Produktions- und Testfarmen zu verwenden.
Verwenden Sie in Ihrer Testumgebung dieselben Datenbanknamen.

Auf diese Weise können Sie Skripte zur Verwaltung Ihrer Umgebung validieren. Achten Sie wieder darauf, separate Server zu verwenden, auf denen SQL Server ausgeführt wird, andernfalls riskieren Sie eine Beeinträchtigung Ihrer Produktionsumgebung.
Stellen Sie sicher, dass Sie alle Einstellungen und Anpassungen auf die Testumgebung übertragen. Informationen zum Sammeln dieser Informationen finden Sie im Abschnitt Identifizieren und Installieren von Anpassungen.

Stellen Sie sicher, dass in der Testumgebung ausgeführte Aktionen die Live-Umgebung nicht beeinträchtigt wird. Gehen Sie bei Folgendem vorsichtig vor:

Externe Datenverbindungen

Auch wenn Sie mit einer Kopie der Umgebung arbeiten, ist die Verknüpfung mit der Datenquelle echt. In der Testumgebung vorgenommene Änderungen an den Daten wirken sich auf die Produktionsumgebung aus.
Ausführen von Befehlen für eine Livedatenbank, die sich noch in der Produktion befindet

Achten Sie darauf, beim Testen Kopien Ihrer Datenbanken zu verwenden und keine Liveversion in Ihrer Produktionsumgebung. Falls Sie beispielsweise Test-SPContentDatabase für eine Livedatenbank statt für eine Kopie ausführen, wird möglicherweise die Leistung in Ihrer Produktionsumgebung beeinträchtigt.

Verwenden einer virtuellen Testumgebung

Wenn Sie die Tests mithilfe einer virtualisierten Umgebung durchführen, ist nur wenig Hardware erforderlich. Sie können die Umgebung mithilfe von nur zwei Servern replizieren, auf denen Hyper-V ausgeführt wird. Ein Server enthält Abbilder für die Front-End-Webserver und Anwendungsserver, und der andere Server enthält Abbilder der Datenbankserver.

In virtuellen Umgebungen sind jedoch u. U. nicht dieselben Leistungsmetriken wie in physischen Umgebungen vorhanden. Ist Ihre Produktionsumgebung physisch, so müssen Sie diesen Unterschied bei der Berechnung der für das Upgrade der Produktionsumgebung erforderlichen Zeit berücksichtigen. Im Allgemeinen können Sie bessere Leistungsschätzungen erhalten, wenn Sie einen physischen Server für SQL Server verwenden. Stellen Sie sicher, dass sie über ähnliche Leistungsspezifikationen wie ihr Server verfügt, auf dem SQL Server in Ihrer Produktionsumgebung ausgeführt wird.

Verteilung der Server in einer virtuellen Testumgebung

Virtuelle Testfarm für Upgrade

Verwenden einer physikalischen Testumgebung

Wenn Sie die Tests mithilfe einer physikalischen Umgebung durchführen, müssen Sie die vorgeschlagene Produktionsserver-Farmumgebung so genau wie möglich replizieren. Wenn Sie die Anzahl von Front-End-Webservern, Anwendungsservern oder Datenbankserver zu stark vereinfachen, erhalten Sie keine präzise Schätzung, wie lang der Upgradevorgang dauern wird. Komplikationen, die sich aus Interaktionen zwischen Servern derselben Rolle ergeben (z. B. SQL Server-Transaktionen), dürfen nicht berücksichtigt werden. Falls in der vorgeschlagenen Produktionsfarm mehrere Server in einer Rolle vorhanden sind, müssen Sie mindestens zwei Server für diese Rolle in der Testfarm verwenden, um den Vorgang auf derartige Probleme hin zu testen.

Verteilung der Server in einer physischen Testumgebung

Physische Farm zum Testen des Upgrades

Identifizieren und Installieren von Anpassungen

Für einen präzisen Testvorgang müssen Sie alle Anpassungen in der aktuellen Umgebung ermitteln und diese in die Testumgebung kopieren. Weitere Informationen zu den zu identifizierenden Anpassungstypen finden Sie unter Create a plan for current customizations during upgrade to SharePoint 2013.

Verwenden Sie den Vorgang Stsadm -o enumallwebs für alle Inhaltsdatenbanken in Ihrer SharePoint 2010-Produkte-Umgebung, um bestimmte Anpassungen in Unterwebsites zu ermitteln. Mit diesem Vorgang werden eine ID für jede Websitesammlung und Unterwebsite in der Umgebung und die Vorlagen, auf denen die Website basiert, aufgelistet. Weitere Informationen finden Sie unter Enumallwebs: Stsadm-Vorgang.
Verwenden Sie ein Tool wie WinDiff (dieses Tool wird mit den meisten Betriebssystemen von Microsoft bereitgestellt), um die Server in der Produktionsumgebung mit den Servern der Testfarm zu vergleichen. Mithilfe dieses Tools können Sie ermitteln, welche Dateien auf den Servern vorhanden sind und welche Unterschiede zwischen diesen bestehen.
Überprüfen Sie die web.config -Dateien auf Änderungen, und suchen Sie im SafeControls -Element nach benutzerdefinierten Steuerelementen.
Erstellen Sie eine Liste aller gefundenen Anpassungen. Identifizieren Sie nach Möglichkeit die Quelle der Anpassungen. Ein Beispiel: Sind Add-Ins oder Vorlagen von Drittanbietern vorhanden, die intern angepasst wurden? Nachdem Sie die Quelle identifiziert haben, können Sie nach aktualisierten Versionen der Anpassungen suchen.

Tipp

[!TIPP] An wen wenden Sie sich zu Anpassungen, die Sie nicht selbst erstellt haben? > Wenden Sie sich an Microsoft, wenn Sie Probleme mit einer Vorlage haben, die Sie von der Microsoft-Website heruntergeladen haben. > Wenden Sie sich an den Lösungsanbieter Ihres Drittanbieters, wenn Sie Probleme mit einer Vorlage oder Komponente haben, die ihnen für die frühere Version bereitgestellt wurde. Möglicherweise ist eine aktuellere Version verfügbar.

Nachdem Sie alle Anpassungen identifiziert haben, kopieren Sie diese auf die entsprechenden Server in der Testfarm. Stellen Sie sicher, dass die folgenden Anpassungen bereitgestellt wurden:

Lösungen - Vorversionslösungen werden standardmäßig in den Verzeichnissen vom Typ "/14" bereitgestellt. Verwenden Sie beim Installieren der Lösungen den Parameter CompatibilityLevel, um sie in den Verzeichnissen vom Typ "/15" bereitzustellen. Weitere Informationen finden Sie unter Install-SPSolution.
Benutzerdefinierte Gestaltungsvorlagen
Benutzerdefiniertes JavaScript
Benutzerdefinierte CSS-Dateien (einschließlich der Dateien für Designs)
Benutzerdefinierte Workflowaktionen (müssen in der Aktionsdatei enthalten sein)
Bestätigen Sie die Einstellungen für die Anfrageneinschränkung für umfangreiche Listen, um die erwartungsgemäße Anzeige großer Listen sicherzustellen.

Verwenden Sie beim Testen der Anpassungen die folgende Anleitung:

Führen Sie eine Überprüfung auf visuelle Änderungen durch.
Führen Sie eine Überprüfung auf Verhaltensänderungen durch.
Testen Sie in Websitesammlungen sowohl im 2010- als auch im 2013-Modus.
Ermitteln Sie ggf. Probleme mit Sprachen oder beim Laden von Ressourcen.

Dieses Problem kann auftreten, wenn vorhandene Anpassungen im 2010-Modus durch neue Anpassungen im 2013-Modus ersetzt werden. Da nur ein globales Verzeichnis für Sprachressourcen vorhanden ist, kann beim Laden der richtigen Datei ein Fehler auftreten. Stellen Sie sicher, dass die 2013-Ersatzanpassungen die Ressourcen aus 2010 enthalten, damit die Anpassungen weiterhin in beiden Modi ordnungsgemäß funktionieren.
Überprüfen, dass durch das Upgrade keine Anpassungen beeinträchtigt wurden. Stellen Sie sicher, dass das Upgrade der Websitesammlung nicht durch Anpassungen blockiert wird.

Sie können das Microsoft PowerShell-Cmdlet Test-SPContentDatabase verwenden, bevor Sie eine Datenbank an SharePoint 2013 anfügen, um zu ermitteln, ob in der Umgebung Anpassungen fehlen. Führen Sie diesen Befehl für jede Datenbank aus, nachdem Sie die Datenbanken auf dem Datenbankserver wiederhergestellt haben, aber bevor Sie das Upgrade ausführen. Beachten Sie, dass dieses Cmdlet im Hintergrund ausgeführt wird und keine Daten ausgibt, wenn kein Fehler ermittelt wird.

Kopieren der realen Daten in die Testumgebung und die Upgrade-Datenbanken

Sie können die Testziele nur dann erreichen, wenn Sie die tatsächlichen Daten verwenden. Verwenden Sie die Microsoft SQL Server-Sicherungs- und Wiederherstellungstool, um eine Kopie Ihrer Inhalts- und Dienstdatenbanken zu erstellen.

Es gibt keine bessere Möglichkeit, die Vorgänge während des Upgrades vorherzusagen, als den Test mit einer Kopie aller Daten durchzuführen. Diese Option kann jedoch für eine erste Testphase nicht immer realistisch sein. Sie können den Test in Phasen unterteilen, indem Sie jeweils nur eine Datenbank testen (wenn die Datenbanken sehr umfangreich sind), sodass Sie sicherstellen können, dass Sie jede Besonderheit des Datasets testen können. Sie können auch eine Teilmenge der Daten aus repräsentativen Websites in der Umgebung zusammenstellen. Wenn Sie zunächst nur eine Teilmenge der Daten testen möchten, müssen Sie sicherstellen, dass die Teilmenge die folgenden Eigenschaften besitzt:

Die Datenteilmenge enthält Websites, die für die in der Umgebung unterstützten Websites typisch sind.
Die Größe und Komplexität der Datenteilmenge ist der tatsächlichen Größe und Komplexität der Umgebung sehr ähnlich.

Wichtig

Beim Testen einer Teilmenge der Daten wird kein gültiger Vergleichswert dazu erstellt, wie lange die Verarbeitung des gesamten Umfangs der Daten in der Umgebung dauern wird.

Starten Sie nach dem Kopieren der Daten einen ersten Durchlauf des Upgradevorgangs, um zu sehen, was geschieht. Hierbei handelt es sich erst einmal um einen vorläufigen Durchlauf. Führen Sie zum Testen des Upgrades durch Datenbankanfügungen die unter Upgrade content databases from SharePoint 2010 to SharePoint 2013 beschriebenen Schritte aus.

Achten Sie beim Testen des Upgradeprozesses darauf, Dienste zu testen, die von mehreren Farmen gemeinsam verwendet werden. Berücksichtigen Sie alle Status wie z. B. folgende:

Eine SharePoint Server 2010-Farm, die mit einer SharePoint 2013-Dienstfarm verbunden ist.
Eine SharePoint 2013-Farm, die mit einer SharePoint 2013-Dienstfarm verbunden ist.
Farmen verschiedener Versionen für verschiedene Dienste.

Verwenden Sie die Testumgebung, um Sicherheits-, Konfigurations-, Kompatibilitäts- und Leistungsprobleme bei Dienstanwendungen zu ermitteln.

Überprüfen der Ergebnisse nach dem Upgrade der Datenbanken

Nach Abschluss des Testupgrades können Sie die Ergebnisse überprüfen und Ihre Pläne überarbeiten. Sehen Sie sich die Protokolldateien an, sehen Sie sich die aktualisierten Websites an, und überprüfen Sie die Anpassungen. Wie hat das Upgrade in der Umgebung funktioniert? Was haben Sie herausgefunden? Welche Aspekte müssen Sie im Upgradeplan überdenken?

Überprüfen der Protokolldateien

Überprüfen Sie die Upgradeprotokolldatei und die Upgradefehlerprotokolldatei (diese werden beim Ausführen des Upgrades generiert). Die Upgradeprotokolldatei (LOG-Datei) und die Upgradefehlerprotokoll-Datei (ERR-Datei) finden Sie unter %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS. Die Protokolldateien werden im folgenden Format benannt: Upgrade- YYYYMMDD-HHMMSS-SSS.log, wobei JJJJMMDD das Datum und HHMMSS-SSS die Uhrzeit ist (Stunden im 24-Stunden-Format, Minuten, Sekunden und Millisekunden).

Das Format der Protokolldateien entspricht den ULS-Namenskonventionen (Unified Logging System). Wenn Sie die Protokolldateien überprüfen möchten, um Probleme zu finden und zu beheben, starten Sie ganz oben in den Dateien. Fehler oder Warnungen wiederholen sich möglicherweise, wenn sie für mehrere Websitesammlungen in der Umgebung auftreten oder wenn sie den Upgradevorgang vollständig blockieren. Ein Beispiel: Wenn Sie keine Verbindung mit der Konfigurationsdatenbank herstellen können, wird der Upgradevorgang mehrmals gestartet (und es tritt ein Fehler auf), und diese Versuche werden in der Protokolldatei aufgeführt.

Überprüfen der Websites im 2010-Modus

Überprüfen Sie, dass die Websitesammlungen, für die kein Upgrade vorgenommen wurde, im 2010-Modus erwartungsgemäß funktionieren. Websites sollten wie in SharePoint 2010-Produkte aussehen und sich auch so verhalten. Einige Änderungen sind zu erwarten. Beispielsweise wurden Office Online und die Web Analytics-Features in SharePoint 2013 geändert, und Websites, die diese Features genutzt haben, sind von den Änderungen betroffen. Weitere Informationen zu spezifischen Aspekten, die zu beachten sind, finden Sie unter Overview of the upgrade process from SharePoint 2010 to SharePoint 2013.

Erneutes Ausführen des Upgrade (falls erforderlich)

Gegebenenfalls können Sie den Upgradeprozess für eine Datenbank mithilfe Microsoft PowerShell-Cmdlets Upgrade-SPContentDatabase erneut starten. Weitere Informationen zu diesem Cmdlet finden Sie unter Upgrade-SPContentDatabase. Weitere Informationen finden Sie unter Restart a database-attach upgrade or a site collection upgrade to SharePoint 2013.

Upgrade von Websitesammlungen und Meine Websites

Nachdem Sie das Upgrade des Inhalts und der Dienstdatenbanken getestet und überprüft haben, können Sie den Upgradevorgang für Websitesammlungen testen. Führen Sie die Schritte in Upgrade a site collection to SharePoint 2013 aus, um den Upgradeprozess für die Websitesammlung zu testen. Wenn in Ihrer Umgebung Meine Websites vorhanden sind, finden sie unter Overview of the upgrade process from SharePoint 2010 to SharePoint 2013 weitere Informationen zum entsprechenden Upgradeprozess.

Hinweis

Inhalt zu Meine Websites gilt nur für SharePoint 2013.

Überprüfen der Ergebnisse nach dem Upgrade der Websitesammlungen

Überprüfen Sie die aktualisierten Websites visuell, um Probleme zu erkennen, die gelöst werden müssen, bevor Sie den Upgradevorgang in der Produktionsumgebung ausführen. Weitere Informationen zu spezifischen Aspekten, die zu beachten sind, finden Sie unter Overview of the upgrade process from SharePoint 2010 to SharePoint 2013.

Überprüfen Sie die Protokolldateien für das Websitesammlungsupgrade von oben nach unten, um Sie auf Probleme zu überprüfen. Überprüfen Sie im unteren Teil der Protokolldatei den Zusammenfassungsabschnitt, der die Anzahl der Probleme und den tatsächlichen Upgradestatus enthält (ist kein Status vorhanden, bedeutet dies, dass der Upgradevorgang fehlgeschlagen ist und das Websiteupgrade erneut gestartet werden muss). Die Websitesammlungs-Protokolldateien werden in der Websitesammlung selbst (in der Dokumentbibliothek "_catalogs/Upgrade") und im Dateisystem gespeichert. Die Dateisystem-Protokolldatei enthält mehr Informationen, falls Sie Einzelheiten zu den Problemen anzeigen möchten. Die Dateisystemversion der Websiteupgrade-Protokolldatei befindet sich in "%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS". Die Protokolldateien werden im folgenden Format benannt: SiteUpgrade- YYYYMMDD-HHMMSS-SSS.log, wobei JJJJMMDD das Datum und HHMMSS-SSS die Uhrzeit ist (Stunden im 24-Stunden-Format, Minuten, Sekunden und Millisekunden).

Anpassen der Pläne und erneutes Testen

Wiederholen Sie den Testvorgang, bis Sie sicher sind, dass Sie alle möglicherweise auftretenden Probleme erkannt haben und wissen, wie Sie diese lösen können. Ihr Ziel besteht darin, zu wissen, wie Ihr Plan um 16:00 Uhr am Sonntag aussieht, wenn Sie am Montag wieder online sein müssen und nicht alles so läuft, wie es soll. Gibt es einen Punkt, nach dem es nicht mehr zurück geht? Testen Sie den Fallbackplan, und stellen Sie sicher, dass er funktioniert, bevor Sie mit dem tatsächlichen Upgrade beginnen.