Verwenden eines Testupgrades zur Ermittlung möglicher Probleme (SharePoint Foundation 2010)

 

Gilt für: SharePoint Foundation 2010

Letztes Änderungsdatum des Themas: 2016-11-30

Bevor Sie den Upgradevorgang von Windows SharePoint Services 3.0 auf Microsoft SharePoint Foundation 2010 beginnen, sollten Sie den Upgradevorgang testen, um sicherzustellen, dass Ihnen die Schritte für ein erfolgreiches Upgrade genau bekannt sind. Mit einem Testupgrade zum Testen des Vorgangs können Sie Folgendes ermitteln:

  • Welche Anpassungen werden in der Umgebung ausgeführt, sodass Sie deren Behandlung während des Upgrades planen können?

  • Sollte die Hardware aktualisiert werden, damit das Upgrade effizienter und schneller ausgeführt werden kann?

  • Wie sieht die Zeitplanung für das Upgrade aus bzw. wie lang dauert das Upgrade 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 Folgendes ermitteln:

  • Welche Sonderfälle gelten für Ihre Umgebung, und welche Upgrademethode kann am effizientesten verwendet werden?

  • 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?

  • Mit welchen Techniken kann die Gefahr von Ausfallzeiten verringert werden?

In diesem Artikel sind grundlegende Schritte zum Testen des Upgrades bereitgestellt. 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.

Inhalt dieses Artikels:

  • Einrichten einer Testumgebung

  • Identifizieren und Installieren von Anpassungen

  • Kopieren der realen Daten in die Testumgebung und Testen des Upgrades

  • Überprüfen der Ergebnisse

  • Anpassen der Pläne und erneutes Testen

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

Einrichten einer Testumgebung

Zum Testen des Upgradevorgangs kann entweder virtuelle oder physische Hardware verwendet werden. Jede Umgebung ist einzigartig, daher können keine allgemeinen Richtlinien zur Dauer des Upgrades oder zu Schwierigkeiten beim Upgrade einer bestimmten Anpassung erstellt werden. Am besten kann der Verlauf des Upgrades durch das Durchführen einiger Testupgrades eingeschätzt werden.

Beachten 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 viel Zeit für die Diagnose von Problemen bezüglich der URLs aufwenden, die beim eigentlichen Upgrade gar nicht auftreten werden.)

  • Stellen Sie sicher, dass Sie alle Einstellungen und Anpassungen auf die Testumgebung übertragen. Hinweise zum Sammeln dieser Informationen finden Sie im Abschnitt Identifizieren und Installieren von Anpassungen.

Verwenden einer virtuellen Testumgebung

Wenn Sie die Tests mithilfe einer virtualisierten Umgebung durchführen, ist nur wenig Hardware erforderlich. Sie können die Umgebung replizieren, indem Sie nur zwei Server verwenden, 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.

Virtuelle Testumgebung für Testupgrade

Verwenden einer physischen Testumgebung

Wenn Sie die Tests mithilfe einer physischen Umgebung durchführen, müssen Sie die gesamte Serverfarmumgebung 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. Zudem können Sie möglicherweise Komplikationen nicht erkennen, die aus Interaktionen zwischen Servern in derselben Rolle entstehen (z. B. SQL Server-Transaktionen). Falls in der ursprünglichen Farm 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.

Physische Testfarm für ein Testupgrade

Zusätzliche Testumgebungen für das Upgrade durch Datenbankanfügungen

Wenn Sie die Upgrademethode durch Datenbankanfügungen verwenden, müssen Sie möglicherweise eine weitere Testumgebung erstellen: eine Farm mit einem einzelnen Server, in der Windows SharePoint Services 3.0 ausgeführt wird. Diese Farm können Sie zum Ausführen der Überprüfung vor dem Upgrade verwenden, bevor Sie mit dem Upgrade der Daten beginnen.

Sie können diesen Schritt vermeiden, indem Sie die Überprüfung vor dem Upgrade in der vorhandenen Produktionsfarm ausführen.

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 Bestimmen des Umgangs mit Anpassungen (SharePoint Foundation 2010).

  • Verwenden Sie die Überprüfung vor dem Upgrade, um Websitedefinitionen, Websitevorlagen und Features in der Umgebung zu identifizieren.

    Bei der Überprüfung vor dem Upgrade wird jede Websitesammlung überprüft und ein Bericht über den Status der einzelnen Websites erstellt. Darüber hinaus werden für alle Listen Informationen zur Listendefinition gespeichert. Mithilfe der Berichte können Sie vor Beginn des Upgrades nach Problemen suchen und diese beheben. Im Gegensatz zum Tool zum Ausführen eines Scans vor dem Upgrade für Windows SharePoint Services 3.0 ist die Überprüfung vor dem Upgrade ein ausschließlich lesendes Tool, von dem keine Änderungen an Websites vorgenommen werden. Weitere Informationen zu diesem Tool und eine Anleitung zum Ausführen des Tools finden Sie unter Überprüfung und Berichterstellung vor dem Upgrade auf zukünftige Versionen (Windows SharePoint Services) und Ausführen des Tools zum Ausführen einer Überprüfung vor dem Upgrade (SharePoint Foundation 2010).

  • Verwenden Sie den Vorgang Stsadm –o enumallwebs für alle Inhaltsdatenbanken in der Windows SharePoint Services 3.0-Umgebung, um spezielle Anpassungen in Unterwebsites zu identifizieren. Bei diesem Vorgang werden für jede Websitesammlung und Unterwebsite in der Umgebung eine ID sowie die Vorlagen aufgelistet, auf denen die Website beruht. Dieser Vorgang wurde in Windows SharePoint Services 3.0 mit Service Pack 2 (SP2) eingeführt. Weitere Informationen finden Sie unter Enumallwebs: Stsadm-Vorgang (Windows SharePoint Services).

  • 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.

  • Verwenden Sie das SharePoint-Diagnosetool (SPDiag) für die Suche nach bereitgestellten Lösungen. Weitere Informationen finden Sie unter SharePoint-Diagnosetool (SPDiag).

  • 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. Es gibt ein Arbeitsblatt, in das Sie Informationen zu Ihrer Umgebung eintragen können, und zwar basierend auf den Daten aus den Ergebnissen des Tools zum Ausführen einer Überprüfung vor dem Upgrade und Ihrer Suche nach Anpassungen. Dieses Arbeitsblatt können Sie von der Webseite http://go.microsoft.com/fwlink/?linkid=179928&clcid=0x407 herunterladen und Ihren Anforderungen entsprechend anpassen.

Tipp

An wen wenden Sie sich zu Anpassungen, die Sie nicht selbst erstellt haben?

  • Wenden Sie sich an Microsoft, wenn Sie mit einer von der Microsoft-Website heruntergeladenen Vorlage Probleme haben (z. B. mit den Windows SharePoint Services 3,0-Anwendungsvorlagen).

  • Wenden Sie sich an den Hersteller einer Lösung von Drittanbietern, wenn Sie Probleme mit einer Vorlage oder Komponente haben, die von diesem Hersteller für die vorherige Version bereitgestellt wurde. Möglicherweise erhalten Sie dort eine aktualisierte Version.

Nachdem Sie alle Anpassungen identifiziert haben, kopieren Sie diese auf die entsprechenden Server in der Testfarm. Sie können vor dem Anfügen einer Datenbank an SharePoint Foundation 2010 mithilfe des Windows PowerShell-Cmdlets test-spcontentdatabase ermitteln, ob Anpassungen in der Umgebung 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 auftritt.

Kopieren der realen Daten in die Testumgebung und Testen des Upgrades

Sie können die Testziele nur dann erreichen, wenn Sie die tatsächlichen Daten verwenden. Zum Erstellen einer Kopie der Daten können Sie die folgenden Methoden verwenden:

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.

Testen eines direkten Upgrades

Wenn Sie ein direktes Upgrade testen möchten, führen Sie zum Testen des Upgradevorgangs die folgenden Schritte aus:

  1. Erstellen Sie eine Sicherung der Serverfarm.

  2. Stellen Sie die Sicherung in der Testfarm wieder her.

    Weitere Informationen finden Sie unter Verwalten von Sicherung und Wiederherstellung mit der Windows SharePoint Services 3.0-Technologie.

  3. Führen Sie die Überprüfung vor dem Upgrade aus. Notieren Sie alle erkannten Probleme. Sie sollten diese Probleme in der ursprünglichen Umgebung lösen, bevor Sie das Upgrade in der Produktionsfarm ausführen. Weitere Informationen finden Sie unter Ausführen des Tools zum Ausführen einer Überprüfung vor dem Upgrade (SharePoint Foundation 2010).

  4. Führen Sie zum Testen eines direkten Upgrades die Schritte unter Ausführen eines direkten Upgrades (SharePoint Foundation 2010) aus.

  5. Überprüfen Sie die Ergebnisse.

Testen eines Upgrades durch Datenbankanfügungen

  1. Erstellen Sie eine SQL Server-Sicherung der Inhaltsdatenbanken.

  2. Verwenden Sie SQL Server, um die Sicherungen in der Testfarm mit einem einzelnen Server wiederherzustellen, und fügen Sie die Inhaltsdatenbanken an diese Umgebung an.

    Weitere Informationen finden Sie unter Sichern und Wiederherstellen von Inhaltsdatenbanken (Windows SharePoint Services 3.0).

  3. Führen Sie das Tool zum Ausführen einer Überprüfung vor dem Upgrade aus. Notieren Sie alle erkannten Probleme und alle vorgenommenen Änderungen. Sie sollten diese Probleme in der ursprünglichen Umgebung lösen und die entsprechenden Änderungen vornehmen, bevor Sie das Upgrade in der Produktionsfarm ausführen. Weitere Informationen finden Sie unter Ausführen des Tools zum Ausführen einer Überprüfung vor dem Upgrade (SharePoint Foundation 2010).

  4. Führen Sie zum Konfigurieren der Testumgebung für ein Upgrade durch Datenbankanfügungen die unter Vorbereiten der neuen SharePoint Foundation-Umgebung beschriebenen Schritte aus.

  5. Führen Sie zum Testen des Upgrades durch Datenbankanfügungen die unter Anfügen von Datenbanken und Durchführen eines Upgrades auf SharePoint Foundation 2010 beschriebenen Schritte aus.

Überprüfen der Ergebnisse

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 folgenden Protokolldateien:

  • Die Protokolldatei der Überprüfung vor dem Upgrade.

    Die Protokolldateien für die Überprüfung vor dem Upgrade (stsadm -o preupgradecheck) befinden sich unter %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\LOGS. Die Protokolldateien werden nach dem folgenden Format benannt: PreUpgradeCheck_JJJJMMTT-HHMMSS-SSS-Zufallszahl.log. Dabei gibt JJJJMMTT das Datum und HHMMSS-SSS die Zeit an (Stunden im 24-Stunden-Format, Minuten, Sekunden und Millisekunden), und die Zufallszahl dient zur Unterscheidung zwischen möglichen gleichzeitig ausgeführten Versuchen zur Ausführung der Überprüfung vor dem Upgrade.

  • Die Protokolldatei Konfigurations-Assistent für SharePoint-Produkte (Psconfig.exe) (sie wird beim Ausführen dieses Assistenten als Teil des direkten Testupgrades generiert).

    Die PSCDiagnostics-Protokolldateien befinden sich unter %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\14\LOGS.

  • Die Upgradeprotokolldatei und die Upgradefehler-Protokolldatei (sie 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\14\LOGS. Die Protokolldateien werden nach dem folgenden Format benannt: Upgrade-JJJJMMTT-HHMMSS-SSS.log, wobei JJJJMMTT das Datum und HHMMSS-SSS die Uhrzeit ist (Stunden im 24-Stunden-Format, Minuten, Sekunden, Millisekunden).

Wenn Sie die Protokolldateien überprüfen möchten, um Probleme zu finden und zu beheben, beginnen Sie ganz oben in den Dateien. Fehler oder Warnungen werden möglicherweise wiederholt, wenn sie für mehrere Websitesammlungen in der Umgebung auftreten oder wenn sie den Upgradevorgang insgesamt 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.

Suchen Sie mit der Suchfunktion oder visuell nach folgenden Einträgen:

  • Finished upgrading SPFarm Name= <Name der Konfigurationsdatenbank>

  • In-place upgrade session finishes. Root object = SPFarm= <Name der Konfigurationsdatenbank> , recursive = True. 0 errors and 0 warnings encountered.

Wenn Sie diese Einträge finden, war die Installation erfolgreich.

Wenn die Einträge aus dem vorherigen Schritt nicht zu finden sind, können Sie bestimmte Probleme erkennen, die möglicherweise zu dem Fehler beigetragen haben, indem Sie die Datei Upgrade.log nach den folgenden Elementen durchsuchen oder visuell scannen:

  • Suchen Sie in den Protokolldateien nach ERROR, um nach Fehlern (z. B. Fehler bei Komponenten oder fehlerhafte Datenbankverbindungen) zu suchen.

  • Suchen Sie nach WARNING, um nach Problemen wie z. B. fehlenden Features oder Komponenten zu suchen.

Zur Suche nach Upgradeproblemen kann es hilfreich sein, einen Protokollparser zum Ausführen von Abfragen in den Protokolldateien zu verwenden.

Ausführen eines Neustarts der Upgrades bei Bedarf

Während eines Upgrades durch Datenbankanfügungen werden alle Websites, die nicht aktualisiert werden können, übersprungen. Wenn während eines direkten Upgrades der Server neu gestartet wird oder wenn beim Upgrade Fehler auftreten, müssen Sie den Upgradevorgang neu starten, um die verbleibenden Websites zu aktualisieren.

Wenn Sie feststellen möchten, ob Websites beim Upgrade ausgelassen oder übersprungen wurden, führen Sie den Stsadm-Vorgang stsadm -o localupgradestatus auf jedem Front-End-Webserver in der SharePoint Foundation 2010-Serverfarm aus. Weitere Informationen zu diesem Vorgang finden Sie unter Localupgradestatus: Stsadm-Vorgang (Windows SharePoint Services).

Falls beim Upgrade Websitesammlungen übersprungen wurden, können Sie den Upgradevorgang für die Datenbank, die diese Websitesammlungen enthält, mit folgendem Windows PowerShell-Cmdlet neu starten: upgrade-spcontentdatabase -id <GUID>. Weitere Informationen zu diesem Cmdlet finden Sie unter Upgrade-SPContentDatabase.

Weitere Informationen finden Sie unter Fortsetzen des Upgrades (SharePoint Foundation 2010).

Überprüfen aktualisierter Websites

Überprüfen Sie die aktualisierten Websites, 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 Überprüfen der Aktualisierung und der aktualisierten Websites (SharePoint Foundation 2010).

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 kein Zurück mehr gibt? Testen Sie den Rollbackplan, und stellen Sie sicher, dass er funktioniert, bevor Sie mit dem tatsächlichen Upgrade beginnen.