Einer unserer Kunden kam Mitte 2006 zu uns, um den Aufbau eines Kundenportals auf Sharepoint-Basis zu besprechen. Nach intensiver Durchsprache der Anforderungen haben wir uns für SharePoint 2007 als Basis entschieden, obwohl zu diesem Zeitpunkt erst die Beta2-Version von SharePoint 2007 verfügbar war.
Wir haben also die Portal-Entwicklung mit der Beta2-Version gestartet - wohlwissend, dass wir mit einer Beta-Version arbeiten und später auf die finale Version updaten müssen. Während der Entwicklungszeit haben wir dann mit einigen Mühen und manueller Nacharbeit ein erstes Upgrade vollzogen. Die ursprüngliche MOSS-Beta2-Installation wurde auf den Stand "Technical Refresh" gebracht.
Als dann die finale SharePoint-Version verfügbar war, haben wir ein weiteres Upgrade durchgeführt. Diesmal haben wir ein Upgrade vom Stand "Technical Refresh" auf die finale Sharepoint-Version durchgeführt. Auch hierbei gab es das eine oder andere Problem, welches sich nur mit viel manueller Nacharbeit lösen lies.
Die SharePoint-Installation war jetzt zwar auf dem finalen Stand, aber ein ungutes Gefühl blieb. Schließlich waren beide Upgrade-Vorgänge nicht problemlos durchgelaufen und hatten jedesmal einige manuelle Nacharbeit erfordert. Als dann auch noch ein paar seltsame Probleme auftauchten (z.B. verschwand mehrmals der Inhalt der Startseite, ohne dass jemand daran gearbeitet hätte), haben wir uns entschlossen, den Server neu auzusetzen.
Um die Downtime möglichst gering zu halten, haben wir uns zuerst überlegt, wie wir am sinnvollsten vorgehen sollten. Einerseits sollte möglichst viel 'alter Ballast' entfernt werden, andererseits sollte die Downtime des produktiven Portals möglichst gering gehalten werden. Wir haben uns dann in Absprache mit unserem Kunden dazu entschlossen, den Server neu zu installieren und das Portal durch einen Transfer der Content-Database auf den neu-installierten Server zu übertragen. Da diese Aktion nicht ganz risikolos ist, haben wir das Vorgehen zuerst mit einem 1:1-Image des Servers in einer Testumgebung durchgeführt.
So sind wir vorgegangen:
-
wir haben als Rettungsanker ein Komplett-Image des ursprünglichen Servers erstellt. Falls es zu größeren Problemen gekommen wäre, hätten wir so rechtzeit abbrechen und den alten Stand wiederherstellen können.
-
danach haben wir eine Sicherung der Content-Database erstellt. Wie man das am besten macht, habe ich vor einiger Zeit bereits
hier beschrieben.
-
da nun alle wichtigen Daten mehrfach gesichert waren, konnte unser Rechenzentrum den Server nach unseren Vorgaben neu installieren. Wir haben uns dafür entschieden, den kompletten Server (also inkl. Betriebssystem) neu zu installieren.
-
nach der Installation des Servers und der nötigen Software (u.a. SQL-Server 2005 und .NET-Frameworks 2/3/3.5) haben wir SharePoint neu installiert und bei dieser Gelegenheit gleich ein Update auf SP1 durchgeführt.
-
der Server war nun komplett neu installiert und die SharePoint-Installation (inkl. SP1) lief problemlos durch. Auf dieser Basis konnten wir nun die Inhaltsdatenbank (Content-Database) zurückspielen und ein paar manuelle Umkonfigurationen vornehmen.
-
zum Abschluß haben wir noch die Daten aus der zurückgespielten Content-Database auf den SP1-Stand gebracht. Dazu reicht folgender Aufruf: stsadm -o upgrade -inplace -forceupgrade
Serverinstallation und Transfer des Portals haben auf diese Art problemlos geklappt. Zwar war auch auf diesem Weg ein wenig manuelle Nachkonfiguration nötig, aber diese Arbeiten blieben im normalen und erwarteten Rahmen. Nach einem gründlichen Abschlußtest, der keine Probleme zeigte, konnten wir das Portal sehr zügig wieder online bringen. Bisher läuft dieses Portal ohne Probleme, die seltsamen Fehler, die wir immer auf die früheren Upgradevorgänge geschoben haben, sind nicht mehr aufgetreten und alles in allem läuft das ganze Portal jetzt sogar ein wenig flotter. Wir werden diese Vorgehensweise bei uns intern als "Best Practice" aufnehmen.
