Problembehandlung und Fortsetzen des Upgrades (Windows SharePoint Services)
Inhalt dieses Artikels:
Allgemeine Informationen zur Problembehandlung und zum Neustart des Upgrades
Bekannte Probleme beim Ausführen eines Scans vor dem Upgrade
Bekannte Probleme beim direkten Upgrade
Bekannte Probleme beim schrittweisen Upgrade
Bekannte Probleme bei der Datenbankmigration
Bekannte Probleme bei angepassten Websites
Allgemeine Informationen zur Problembehandlung und zum Neustart des Upgrades
Wenn das Upgrade angehalten wird, können Sie die Probleme mithilfe der folgenden Methoden behandeln:
Suchen Sie in den Updateprotokolldateien nach dem Wort "error". Die Updateprotokolldateien befinden sich im Verzeichnis %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\LOGS. Weitere Informationen zum Anzeigen der Updateprotokolldatei finden Sie unter Überprüfen des Upgrades (Windows SharePoint Services).
Tipp
Suchen Sie mit der Windows-Funktion Nach Dateien und Ordnern suchen nach Vorkommen des Worts "error" in den Protokolldateien.
Überprüfen Sie die Ereignisse in der Ereignisanzeige, und suchen Sie nach Anwendungsfehlern.
Suchen Sie in der Infodatei nach bekannten Problemen und Problemumgehungen. Bei Fehlern handelt es sich häufig um Probleme, die Sie umgehen können.
Wenn Sie eine schrittweise Aktualisierung ausführen, müssen Sie überprüfen, ob die ausgeführten Websitesammlungen in einer neuen Version veröffentlicht wurden. In diesem Fall können Sie die beschriebene Problemumgehung ausführen oder die Website von der Version 3 auf die Version 2 zurücksetzen und erneut versuchen, die Website zu aktualisieren. Weitere Informationen zum Zurücksetzen von Websites finden Sie unter Wiederherstellen einer vorherigen Version einer Website (Windows SharePoint Services).
Eine direkte Aktualisierung kann mit dem Befehl stsadm -o upgrade neu gestartet werden. Bei der Aktualisierung werden die bereits abgeschlossenen Aufgaben übersprungen. Die Fortsetzung erfolgt an der Stelle, an der die Unterbrechung aufgetreten ist. Weitere Informationen zum Aktualisierungsvorgang finden Sie unter Aktualisieren von Websites (Windows SharePoint Services).
Bekannte Probleme beim Ausführen eines Scans vor dem Upgrade
Das Upgrade wird beendet, wenn "localhost" als Servername verwendet wird
Das Verwenden von localhost als Servername kann zahlreiche Probleme in der Umgebung verursachen und wird nicht empfohlen. Wenn Sie localhost als Servername verwenden und das Tool zum Ausführen eines Scans vor der Aktualisierung ausführen, wird dieses Problem protokolliert, und die Aktualisierung kann nicht fortgesetzt werden. Sie müssen den Server umbenennen und anschließend einen Scan ausführen, bevor Sie die Aktualisierung fortsetzen können. Führen Sie die nachfolgend beschriebenen Schritte aus, um den Server umzubenennen und das Problem mit dem Tool zum Ausführen eines Scans vor der Aktualisierung zu beheben.
Sichern Sie die Konfigurationsdatenbank.
Wechseln Sie in der Befehlszeile zum Pfad %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\60\bin, und führen Sie dann den folgenden Befehl aus, um den Servernamen in der Konfigurationsdatenbank zu ändern:
Stsadm.exe -o setconfigdb -databaseserver <
Servername> -connect
Wechseln Sie in der Befehlszeile zum Pfad %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\bin, und führen Sie dann den folgenden Befehl aus, um das Problem mit dem Tool zum Ausführen eines Scans vor dem Upgrade zu beheben:
Prescan /fixlocalhost
Führen Sie in der Befehlszeile den folgenden Befehl aus, um den Scanvorgang vor dem Upgrade erneut auszuführen:
Prescan /all
Wenn der Vorgang erfolgreich abgeschlossen wird, setzen Sie das Upgrade fort.
Wenn der Vorgang weiterhin nicht erfolgreich abgeschlossen wird, verwendet ein weiterer Dienst localhost als Servername. Die Aktualisierung ist zwar nicht mehr blockiert, aber bestimmte Dienste werden möglicherweise nicht erfolgreich aktualisiert.
Bekannte Probleme beim direkten Upgrade
Für Upgrades der Serverfarm muss statt des Netzwerkdiensts ein Domänenkonto verwendet werden
Verwenden Sie für direkte oder schrittweise Aktualisierungen in einer Serverfarmumgebung sowohl für die Umgebung mit der Version 2 als auch für die Umgebung mit der Version 3 dieselben Anmeldeinformationen. Wenn Sie jedoch in der Umgebung mit der Version 2 ein Netzwerkdienstkonto verwendet haben, müssen Sie unter Version 3 ein Domänenkonto verwenden. In der Umgebung mit der Version 2 kann zwar weiterhin ein Netzwerkdienstkonto verwendet werden, aber beim Installieren der Version 3 und dem Erstellen der neuen Farm müssen Sie stattdessen ein Domänenkonto angeben. Vergewissern Sie sich, dass dem Domänenkonto die geeigneten Berechtigungen für die Datenbanken in SQL Server erteilt wurden (muss Mitglied der Gruppen der Datenbankersteller, Prozessadministratoren und Datenbankbesitzer für sämtliche Datenbanken unter Version 2 sein).
Einige Einstellungen bleiben bei einer direkten Aktualisierung in der Webanwendung nicht erhalten
Wenn Sie Secure Sockets Layer (SSL) verwenden und eine direkte Aktualisierung durchführen, müssen Sie die URL in Windows SharePoint Services mithilfe des Features AAM (Alternate Access Mapping, alternative Zugriffszuordnungen) ändern, da einige Einstellungen in der Webanwendung nicht erhalten bleiben.
Angenommen, ein AAM-Eintrag, der HTTPS verwendet, sieht vor der Aktualisierung wie folgt aus:
Eingehende URL: https://<Servername>
Ausgehende URL: https://<Servername>
Nach einer direkten Aktualisierung von Windows SharePoint Services 3.0 wird dieser Eintrag falsch festgelegt als:
Eingehende URL: https://<Servername>
Ausgehende URL: http://<Servername>
Klicken Sie zum Korrigieren der URL auf der Website für die SharePoint-Zentraladministration auf der Seite Vorgänge auf Alternative Zugriffszuordnungen und dann auf Öffentliche URLs bearbeiten, um die URL wie folgt zurückzusetzen:
Eingehende URL: https://<Servername>
Ausgehende URL: https://<Servername>
Weitere Informationen zu alternativen Zugriffszuordnungen finden Sie unter Planen der alternativen Zugriffszuordnungen (Windows SharePoint Services).
Die Aktualisierung wird auf dem ersten Front-End-Webserver mit Fehlern durchgeführt
In einer Farm mit mehreren Front-End-Webservern wird bei einer fehlerhaften Aktualisierung auf dem ersten Front-End-Webserver empfohlen, zunächst das Problem zu beheben und die Aktualisierung dann erneut durchzuführen. Fahren Sie erst dann mit der Aktualisierung weiterer Front-End-Webserver fort.
Wenn Sie den Fehler aus irgendeinem Grund außer Acht lassen möchten (z. B. weil der Fehler mit einer selten verwendeten Websitesammlung zusammenhängt), können Sie mit der Aktualisierung des zweiten Front-End-Webservers mithilfe des Befehlszeilentools Psconfig fortfahren. Verwenden Sie dazu den folgenden Befehlszeilenvorgang:
Psconfig -cmd upgrade -inplace b2b -wait -force
Hinweis
Bei Verwendung des Befehlszeilentools Psconfig steht Ihnen der Konfigurations-Assistent für SharePoint-Produkte und -Technologien nicht für die Aktualisierung weiterer Front-End-Webserver zur Verfügung.
Sequenzfehler "SPConfigurationDatabase2" im Aktualisierungsprotokoll
Wenn Sie eine direkte Aktualisierung durchführen und diese schlägt fehl, überprüfen Sie die Datei Upgrade.log im Ordner COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS. Wenn Sie die Fehlermeldung “[SPConfigurationDatabaseSequence2] [ERROR] [date]: The role 'WSS_Content_Application_Pools' already exists in the current database” erhalten, können Sie das Problem wie folgt umgehen:
Führen Sie die folgenden SQL-Abfragen in der Konfigurationsdatenbank aus.
delete from dependencies
delete from objects
delete from classes
delete from sitemap
exec sp_droprole N'WSS_Content_Application_Pools'
Hinweis
Verfügt die zu entfernende Rolle beim Auftreten des Fehlers über Mitglieder, gibt der Aufruf sp_droprole die Namen dieser Mitglieder zurück. Sie müssen dann den folgenden Befehl für jedes Mitglied ausführen.
exec sp_droprolemember N'WSS_Content_Application_Pools',
N'usernameReturnedFromSP_DropRole'
Sie müssen dann die folgende Abfrage erneut ausführen.
exec sp_droprole N'WSS_Content_Application_Pools'
Erstellen Sie eine neue Farm der Version 3, und fügen Sie dann die vorhandene Inhaltsdatenbank an. Bei dieser Option bleiben alle Benutzerdaten erhalten, während die in der Konfigurationsdatenbank der Version 2 gespeicherten Konfigurationsdaten, wie z. B. Webpartpakete und Einstellungen der virtuellen Server, verloren gehen.
Wenn der ursprüngliche Fehler behoben wurde (die Ursache des Fehlers lag beispielsweise bei einer getrennten Netzwerkverbindung oder bei unzureichendem Speicherplatz auf dem Computer mit SQL Server und wurde mittlerweile beseitigt), können Sie die Farm der Version 2 wiederherstellen und die Aktualisierung erneut starten.
Hinweis
Denken Sie daran, die Aktualisierung nach der Problemumgehung erneut zu starten.
Führen Sie bei direkten Aktualisierungen auf eigenständigen Servern die Aktualisierung in der Befehlszeile aus, wenn in Bezug auf die Datenbank ein Anmeldungs- oder Verbindungsfehler auftritt
Wenn Sie eine direkte Aktualisierung auf einem eigenständigen Server mit einer WMSDE-Datenbank ausführen, kann eine Zeitüberschreitung bei der Aktualisierung auftreten und einen Fehler wie die folgenden generieren:
SPContentDatabaseSequence] [ERROR] [10/18/2006 12:42:44 PM]: Cannot open database "STS_DATABASE_NAME_1" requested by the login. The login failed.
Fehler bei der Anmeldung für den Benutzer 'NT-AUTORITÄT\NETZWERKDIENST'.
[SPContentDatabaseSequence] [ERROR] [10/18/2006 12:42:44 PM]: at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
Wenn Sie diesen Fehler oder einen Datenbankverbindungsfehler erkennen, müssen Sie das Upgrade über die Befehlszeile abschließen.
Öffnen Sie ein Eingabeaufforderungsfenster, und wechseln Sie zu folgendem Verzeichnis: %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\bin
Führen Sie den folgenden Befehl aus, um das Upgrade fortzusetzen und abzuschließen:
psconfig –cmd upgrade –inplace v2v –force -wait
Weitere Informationen zum Befehlszeilentool psconfig.exe finden Sie unter Befehlszeilenreferenz für den Konfigurations-Assistenten für SharePoint-Produkte und -Technologien (Windows SharePoint Services).
Bekannte Probleme beim schrittweisen Upgrade
Für Upgrades der Serverfarm muss statt des Netzwerkdiensts ein Domänenkonto verwendet werden
Verwenden Sie für direkte oder schrittweise Aktualisierungen in einer Serverfarmumgebung sowohl für die Umgebung mit der Version 2 als auch für die Umgebung mit der Version 3 dieselben Anmeldeinformationen. Wenn Sie jedoch in der Umgebung mit der Version 2 ein Netzwerkdienstkonto verwendet haben, müssen Sie unter Version 3 ein Domänenkonto verwenden. In der Umgebung mit der Version 2 kann zwar weiterhin ein Netzwerkdienstkonto verwendet werden, aber beim Installieren der Version 3 und dem Erstellen der neuen Farm müssen Sie stattdessen ein Domänenkonto angeben. Vergewissern Sie sich, dass dem Domänenkonto die geeigneten Berechtigungen für die Datenbanken in SQL Server erteilt wurden (muss Mitglied der Gruppen der Datenbankersteller, Prozessadministratoren und Datenbankbesitzer für sämtliche Datenbanken unter Version 2 sein).
Für das schrittweise Upgrade von reinen SSL-Servern sind zusätzliche Schritte erforderlich
Bei einer schrittweisen Aktualisierung werden IIS-Websites parallel verwendet, auf denen die ursprüngliche (nicht aktualisierte) bzw. die neue (aktualisierte) Website gehostet werden. Standardmäßig wird für die neu erstellte Website SSL nicht verwendet. Wenn auf dieser Website SSL verwendet werden soll, müssen Sie während der schrittweisen Aktualisierung zusätzliche Schritte ausführen, um die IIS-Einstellungen und die Portnummer auf die richtigen Werte für SSL festzulegen.
Führen Sie die folgenden Schritte aus, nachdem Sie die Zielwebanwendung für Ihre Websites erstellt haben, aber bevor Sie die Websites aktualisieren.
Weitere Informationen zum Erstellen der Zielwebanwendung finden Sie unter Aktualisieren von Websites (Windows SharePoint Services) im Abschnitt "Erstellen einer neuen Webanwendung zum Hosten aktualisierter Websites".
Ändern der Portnummern und der SSL-Einstellungen im IIS-Manager
Klicken Sie im IIS-Manager auf das Pluszeichen (+) neben dem Namen des Servers, auf dem sich die zu ändernde Anwendung befindet.
Klicken Sie auf das Pluszeichen (+) neben Websites.
Klicken Sie mit der rechten Maustaste auf Standardwebsite, und klicken Sie anschließend auf Eigenschaften.
Geben Sie auf der Registerkarte Website im Feld SSL-Port den Wert 444 ein, und klicken Sie dann auf OK.
Klicken Sie mit der rechten Maustaste auf die Kopie der Standardwebsite, und klicken Sie anschließend auf Eigenschaften.
Geben Sie auf der Registerkarte Website im Feld SSL-Port den Wert 443 ein, und klicken Sie dann auf Übernehmen.
Klicken Sie auf der Registerkarte Verzeichnissicherheit im Abschnitt Sichere Kommunikation auf Serverzertifikat.
Folgen Sie den Anweisungen des Assistenten, um ein neues Zertifikat zuzuweisen.
Klicken Sie auf der Registerkarte Verzeichnissicherheit im Abschnitt Sichere Kommunikation auf Bearbeiten.
Aktivieren Sie im Dialogfeld Sichere Kommunikation das Kontrollkästchen Sicheren Kanal voraussetzen (SSL), und klicken Sie dann auf OK.
Klicken Sie auf OK, um das Dialogfeld Eigenschaften für die Kopie der Standardwebsite zu schließen.
Aktualisieren der alternativen Zugriffszuordnungseinstellungen und Zurücksetzen von IIS
Öffnen Sie ein Eingabeaufforderungsfenster, und wechseln Sie zu folgendem Verzeichnis: %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\bin.
Führen Sie den folgenden Befehl aus, um die alternative Zugriffszuordnung für die ursprüngliche Standardwebsite in Port 444 zu ändern:
Stsadm -o addzoneurl -url https://server_name:port -urlzone default -zonemappedurl https://server_name:444
Dabei ist Servername:Port der Speicherort für die Standardwebsite.
Wechseln Sie zu folgendem Verzeichnis: %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\60\bin.
Führen Sie den folgenden Befehl zum Ändern der alternativen Zugriffszuordnung für die umgeleitete Website aus:
Stsadm -o addzoneurl -url http://server_name:port -urlzone default -zonemappedurl https://server_name:443
Dabei ist Servername:Port der Speicherort für die beim Erstellen der Zielwebanwendung erstellte Website.
Führen Sie den folgenden Befehl aus, um IIS zurückzusetzen:
iisreset /noforce
Das Upgrade wurde abgeschlossen, aber es wurden noch nicht alle Websites aktualisiert. Welche Schritte muss ich ausführen?
Nach Abschluss der Aktualisierung können Sie die verbleibenden Websites nicht mehr mithilfe der schrittweisen Aktualisierung aktualisieren. Sie können die Websites allerdings mithilfe der Datenbankmigration aktualisieren. Weitere Informationen zum Aktualisieren von Websites mithilfe der Datenbankmigration nach dem Abschluss einer schrittweisen Aktualisierung finden Sie im Artikel 926718 der Microsoft Knowledge Base (https://support.microsoft.com/kb/926718/de-de/de).
Ich habe mich auf dem Setupbildschirm gegen die Aktualisierung entschieden, nun aber meine Meinung geändert und möchte doch eine Aktualisierung durchführen
Wenn Sie während des Setups die Option Nicht aktualisieren ausgewählt haben und nach dem Ausführen des Konfigurations-Assistenten für SharePoint-Produkte und -Technologien Ihre Meinung ändern, müssen Sie den Konfigurations-Assistenten für SharePoint-Produkte und -Technologien erneut ausführen, um zu einer schrittweisen Aktualisierung zu wechseln.
Verwenden des Konfigurations-Assistenten für SharePoint-Produkte und -Technologien zum Wechseln von der Option “Nicht aktualisieren” zu einer schrittweisen Aktualisierung
Führen Sie den Konfigurations-Assistenten für SharePoint-Produkte und -Technologien aus, um die Verbindung mit der Farm zu trennen.
Navigieren Sie zu %COMMONPROGRAMFILES%\Microsoft shared\Web Server Extensions\12.0\WSS\, und ändern Sie den Registrierungsschlüssel für SetupType und SetupTypeBackup in V2V_GRADUAL_UPGRADE.
Führen Sie den Konfigurations-Assistenten für SharePoint-Produkte und -Technologien erneut aus, um die Aktualisierung durchzuführen.
Bekannte Probleme bei der Datenbankmigration
Einer Farm kann eine Inhaltsdatenbank nur einmal hinzugefügt werden, auch in verschiedenen Webanwendungen
Jeder Websitesammlung in einer Inhaltsdatenbank (einschließlich der Portalwebsites) ist ein global eindeutiger Bezeichner (GUID) zugeordnet, der in der Konfigurationsdatenbank registriert ist. Daher kann einer Farm dieselbe Websitesammlung (oder dasselbe Portal) nur einmal hinzugefügt werden. Zwar kann die Datenbank in dieser Situation erfolgreich angefügt werden, doch die Websitesammlung kann nicht gestartet werden. Wenn Sie ein Duplikat einer Websitesammlung (oder eines Portals) in derselben Farm benötigen, müssen Sie zuerst die Datenbank mit der Websitesammlung an eine andere Farm anfügen und dann mithilfe der Vorgänge backup und restore im Befehlszeilentool Stsadm.exe die Websitesammlung in die andere Farm kopieren. Während des Sicherungs- und Wiederherstellungsvorgangs wird eine neue GUID für die Websitesammlung erstellt.
Bekannte Probleme bei angepassten Websites
Nach unzulässigen Anpassungen in "Web.config"-Dateien können Anwendungsfehler auftreten
Bestimmte Anpassungen sind in Web.config-Dateien für Unterordner innerhalb eines virtuellen Servers nicht zulässig. Beispielsweise sind die Knoten AUTHENTICATION und SESSIONSTATE auf dieser Ebene in der Datei Web.config nicht zulässig. Das Ändern der Datei Web.config in nicht empfohlener Weise kann zu unerwünschten Aktualisierungsergebnissen führen. Befolgen Sie die empfohlenen Verfahren für Anpassungen auch für die Datei Web.config. Weitere Informationen finden Sie unter Bewährte Methoden zum Sicherstellen der Wiederverwendbarkeit und Aktualisierung von Anwendungen in Windows SharePoint Services (in englischer Sprache) auf der MSDN-Website (https://msdn.microsoft.com/de-de/library/dd583161.aspx).
Herunterladen dieses Buchs
Dieses Thema wurde zum leichteren Lesen und Ausdrucken in das folgende Buch zum Herunterladen aufgenommen:
Die vollständige Liste der verfügbaren Bücher finden Sie unter Bücher zum Herunterladen für Windows SharePoint Services.