Erfahrungsbericht: Migration von SBS 2003 nach Windows Server 2012 R2

Bei einer Migration zwischen verschiedenen Betriebssystemversionen kann viel schief laufen. Datenverlust ist nur eine der Gefahren, die im Endeffekt dafür sorgen, dass man sich die Haare vom Kopf reissen könnte. In diesem Beitrag zeigen wir auf, was wir für verschiedene Fehler hatten und wie wir Sie umgangen sind.

Situation

Wir haben einen SBS 2003 (aktuell gepatcht) im Einsatz, der durch einen Windows Server 2012R2 ersetzt werden und alle Funktionen weiterhin zur Verfügung stellen soll. Damit diese Migration funktioniert, muss z.B. der Windows Small Business Server 2011 als Zwischenschritt genommen werden - die Unterschiede allein im Active Directory wären sonst zu groß. Ein weiterer Vorteil der Migration über den SBS2011 ist, dass dieser bereits mit einem Exchange-Server ausgestattet ist und somit dessen temporäre Installation entfällt.

Achtung: Für die Migration sind die Installationsmedien für den SBS 2003, SBS 2011, Windows Server 2012 R2 und Exchange Server 2013 notwendig!

Wir haben ein Fazit, dieses finden Sie ganz unten (siehe hier) - der hier beschriebene Weg ist umständlich und sehr Zeitintensiv!

Migration SBS 2003 zu SBS 2011

Ein SBS 2003 ist nicht sofort bereit für eine Migration zum SBS 2011, hierfür müssen folgende Schritte durchgeführt werden (Reihenfolge ist wichtig!):

1. Installieren von Update KB968930 (auf Bit-Version achten)
2. Installieren von 2MBCA_Setup32_Win8 (auf Bit-Version achten)
3. Installieren von KB943494 (s. SBS2011 Installationsmedium ( \TOOLS\KB943494 ))
4. Installieren von sourcetool.msi (s. SBS2011 Installationsmedium ( \TOOLS\ )

Nach diesen Schritten muss ein temporärer Administrator-Account angelegt werden, der folgende Gruppen benötigt:

• Administratoren
• Domänen-Admins
• Mail Operators
• Organisations-Admins
• Schema-Admins
• Server-Operatoren

Nach dem der Account angelegt wurde, ist ein Neustart des Servers zwingend erforderlich. Andernfalls funktionieren nachfolgende Schritte nicht sauber. Nach dem Neustart müssen Sie das "Tool zum Vorbereiten der Migration von Windows Small Business Server 2011 Standard" ausführen. Es ist empfohlen, wichtige Updates gleich mit abzurufen - dadurch entfällt ein Großteil des manuellen Patchens vom SBS2011 - sollte es aber nicht mgölich sein, können auch keine Updates installiert werden. Bevor an diesem Punkt weitergemacht wird, ist ein Backup des gesamten Systems unbedingt notwendig, da dieser Prozess sehr tief in das System eingreift. Der Assistent wird folgend den Quellserver auf die Migration vorbereiten und diesen auf ggf. vorhandene Probleme überprüfen. Warnungen zu konfigurierten Smart-Hosts (SMTP) und abweichenden SMTP-Ports (normal 25) können ignoriert werden.

Nun ist der Quellserver vorbereitet. Damit der Migrationsprozess möglichst zügig vonstatten geht, erstellen wir eine Antwortdatei und wählen "Migration" im Assistenten aus. Viele der Felder sind selbst erklärend-  für die Uhrzeit-Einstellungen sollte man jedoch die Zeitzone manuell konfigurieren, da der Quell- sowie Zielserver maximal einen Offset von 5 Minuten haben dürfen. Zu beachten ist außerdem, dass der Quell- und Zielserver nicht den gleichen Namen haben dürfen. Die Eingabe des Kennworts für den Admin erfolgt im Klartext und sollte daher nicht mit dem permanenten Admin-Account durchgeführt werden - wir verwenden hierfür den temporären Admin-Account.
Die Antwortdatei wird am Besten auf einem FAT-formatierten USB-Stick gespeichert oder auf eine Diskette. Der Stick/Die Diskette müssen während des Installationsvorgangs des Zielservers dauerhaft verbunden sein - der Installer des SBS2011 findet die Antwortdatei selbstständig.

Nun kann der Installationsprozess auf dem Zielserver durchgeführt werden: Hierfür legen wir das Installationsmedium in das Laufwerk des Servers ein und starten von dieser. Der USB-Stick ist zu diesem Zeitpunkt bereits angeschlossen. Sobald der Installer alle notwendigen Daten geladen hat, können wir zwischen einer Neuinstallation oder Migration wählen - in unserem Fall nehmen wir natürlich die Migration. Der Rest geschieht im Regelfall von allein. Sollten z.B. falsche Benutzerdaten oder eine falsche IP-Adresse angegeben worden sein, so wird der Installer erneut nach den richtigen Daten fragen. Nun folgen die Probleme, die an diesem Punkt vor uns standen und wie wir diese gelöst haben.

Probleme und Lösungen SBS2011-Installer im Migrationsmodus

Während der Migration erscheint eine Abfrage "Windows SBS":

Die Active-Directory-Replikation dauert länger als erwartet. Sie können entscheiden, ob Sie weiterhin warten möchten. [...] Möchten Sie warten, bis die Replikation abgeschlossen ist? (Ja/Nein)

 Dieses Problem, ist nicht zwingend eines - um sicherzustellen, dass alles in Ordnung ist, muss <Shift + F10> gedrückt werden und in der sich öffnenden CMD folgendes eingegeben werden:

notepad "C:\Program Files\Windows Small Business Server\Logs\SBSSetup.log"

Folgende Zeilen deuten daraufhin, dass die Meldung problemlos mit "Nein" beantwortet werden kann:

[5052] 150811.162352.3641: Setup: Attempting LDAP bind.
[5052] 150811.162352.3681: Setup: Bind successful
[5052] 150811.162352.3691: Task: Waiting for replication to finish
[5052] 150811.162852.3831: Task: Finished waiting.
[5052] 150811.162852.3861: Setup: DsGetDcName returned: 0
[5052] 150811.162852.3861: Setup: DsGetDcName returned name: old.domain.local
[5052] 150811.162852.3871: Setup: Expected name: new.domain.local
[5052] 150811.162852.4061: Task: There are 0 pending replication operations.

 Der Assistent meldet, dass keine Verbindung zum AD-Source-Server aufgebaut werden kann. Source- & Quell-Server können sich gegenseitig anpingen, die Firewall ist aus (bzw. testweise deaktiviert) worden - das Problem aber bleibt bestehen.

Bei Suchen im Netz  findet man alles mögliche, darunter z.B. die RPC-Dienste, die damit eng in Verbindung stehen können. Viel schneller, als sich durch die RPC-Einstellungen auf Quell- und Source-Server zu hangeln ist es jedoch, wenn man mit <SHIFT + F10> eine CMD öffnet, control.exe eingibt und dort in die Zeiteinstellungen geht. Die Uhrzeit & Datum darf sich maximal um 5 Minuten vom Quellserver unterscheiden. Hier kann man notfalls auch gleich die Zeit korrigieren, danach "Erneut versuchen" und schon sollte es gehen.

Nach Installation: Migration fortsetzen

Bevor die Migration fortgesetzt werden kann, muss sichergestellt werden, dass der SBS 2011 mindestens Service Pack 1 aufweist, man kann ihn an diesem Punkt natürlich auch schon fertig durchpatchen. Einige der nachfolgenden Schritte funktionieren nicht, wenn gewisse Updates fehlen!

Der SBS2011 nimmt einem viele Migrationsschritte (z.B. das Active Directory) ab, verlangt jedoch, dass einige Sachen manuell durch den Administrator durchgeführt werden. Hierfür loggen wir uns nicht mit dem Administrator ein, sondern den vorher temporär angelegten Admin-Benutzer. Der Migrationsassistent vom SBS2011 lässt sich nämlich nicht mit dem integriertem Admin-Account ausführen.

In den folgenden Schritten kann man zwischen den Punkten "Task wird ausgeführt", "Task abgeschlossen" & "Task überspringen" wählen. "Task wird ausgeführt" auszuwählen ist eigendlich unnötig, da man sonst in die Übersicht zurückgelangt. Es ist zwingend notwendig die "Checkliste" abzuarbeiten, da man sonst später die Migration nicht vollständig beenden kann. Auch kann man den Migrationsassistenten zwischendrin schliessen - allerdings muss man die bereits erledigten Punkte zumindestens noch einmal als erledigt markieren.

Im Ersten Schritt lassen sich Datenverzeichnisse für Exchange, SharePoint, User Shared Files, Umgeleitete Dokumente, und WSUS verschieben. Das macht z.B. dann Sinn, wenn man kleine SSDs im Server verbaut hat, die nur bestimmte Dienste besonders schnell zur Verfügung stellen soll. So macht es z.B. Sinn, wenn Exchange, Betriebssystem sowie Benutzerdaten (sofern nicht zu groß) auf schnellen Medien liefert - WSUS hingegen muss nicht zwingend schnellstmöglich ausgeliefert werden, da der Benutzer hiervon meist nie direkt betroffen ist.

Der zweite Schritt richtet das Netzwerk des SBS ein - dieser Schritt ist nicht zwingend notwendig, da wir uns bereits in einem konfigurierten Netzwerk befinden. Der Assistent prüft verschiedene Gegebenheiten (z.B. nach Existenz eines DHCP-Servers) und bietet entsprechende Konfigurationsmöglichkeiten an bzw. schlägt "Verbesserungen" vor.

Schritt drei ist da eher wichtiger: Dieser ist zur Einrichtigung der Internetadresse des SBS2011 zuständig. Auch hier steht ein Assistent zur Verfügung und hilft beim Großteil der Schritte. Dieser Schritt betrifft auch Zertifikate.

Nachfolgend im nächsten Schritt kann man Netzwerkeinstellungen migrieren. Im Endeffekt ist dieser Schritt meist unnötig, da es hier Einstellungen wie DNS und ähnlichem geht. Diese Einstellungen sollten zwingend händlich über die entsprechenden Konsolen kontrolliert und wenn nötig migriert werden. So kann man ggf. auch alte Einträge ausmisten.

Anschließend wird es im fünften Schritt etwas anspruchsvoller: Die Migration der Exchangedaten steht an. Entgegen der Empfehlung von Microsoft verzichten wir auf das Kopieren der Exchange-Daten vom Quellserver auf den Zielserver und starten direkt die Exchange Management Console. Das erste Starten dauert einen Moment, da nun die Organisationseinheit auf dem Zielserver vorbereitet wird. In unserem Fall wurden die Mail-Accounts der Benutzer bereits angezeigt (mit Verweis auf den Quellserver). Unter Microsoft Exchange (lokal) > Empfängerkonfiguration > Postfach können nun alle Accounts ausgewählt werden. Mit einen Rechtklick auf die markierten Accounts kann nun "Lokale Verschiebungsaufforderung" angeklickt werden. Ein Assistent öffnet sich und fragt nach der neuen Datenbank, in die die Accounts gespeichert werden soll. Nach Angabe derer und Abschluss dieser Aufforderung, sollte der Quell-Exchange-Server nicht sofort außer Betrieb genommen werden. Das Gleiche muss nämlich noch mit dem Öffentlichen Adressbuch gemacht werden, sodass nur noch Quellangaben zum Zielserver angezeigt werden. Ein anderer Grund des Wartens ist, dass viele Daten im Hintergrund synchronisiert werden. Das lässt sich sehr gut mit dem Performance-Monitor auf dem Zielserver beobachten. Der Synchronisationsvorgang dauert je nach gesamter Datenbankgrößer, sowie Geschwindigkeit beider Server entsprechend lang. In unserem Fall brauchten 12GB ca. eine Stunde (bei jeweils einem Quad-Core, 8GB RAM & vDisk auf einem Raid).

Der sechste Schritt sieht das Entfernen von Legacygruppenrichtlinien und -anmeldeinstellungen vor. Mit Anmeldeeinstellungen sind unter anderem Logon-Scripte gemeint oder Einstellungen, die auf den alten Quellserver verweisen. Sobald dieser abgeschaltet ist, würde es ggf. zu entsprechenden Problemen führen die unnötige Arbeit hinter sich ziehen.

Schritt sieben bedeutet selbst Hand anlegen: Hier wollen die Benutzerdaten (Freigaben, Dateien und Ordner) auf den Zielserver migriert werden. Das geht am einfachstem mit einem kleinen robocopy /MIR, dass die Verzeichnisse beider Seite automatisch abgleicht. Anschließend müssen nur noch die Freigaben ggf. händisch angelegt bzw. kontrolliert werden.

Auch Schritt acht ist eher manuell zu bewähltigen: Die Migration der Sharepoint-Seiten. Dieser Schritt ist nur dann notwendig, wenn es benutzerdefinierte Seiten gibt. Das OWA ist hiervon z.B. nicht betroffen. In unserem expliziten Fall war es nicht notwendig und konnte übersprungen werden.

Um in Schritt neun die Faxdaten migrieren zu können, mussten wir händisch die Faxserver-Rolle und die dazugehörigen Features nachinstallieren (Serverneustart erforderlich). Die Migration wird mit klicken auf den Link im Migrationsassistenten automatisch durchgeführt. In unserem Fall brauchen wir die Faxdaten jedoch nicht, weshalb wir den Schritt übersprungen haben.

Der vorletzte Schritt ist wichtig, damit die bereits durch die AD-Replikation migrierten Sicherheitsgruppen auch über die SBS-Konsole auf dem Zielserver administriert werden können. Er kann übersprungen werden, wenn der SBS2011 nur ein Zwischenschritt wie in unserem Fall ist. Wenn die Gruppen migriert werden müssen, hilft der folgende Converter (Boardmittel) bei dieser:
C:\Program Files\Windows Small Business Server\bin\GroupConverter.exe 

Im letzten Schritt wird die Migration abgeschlossen, hier hat man zum letzten Mal die Möglichkeit, übersprungende Aufgaben doch noch durchzuführen. Wenn man das nicht möchte, kann man abschliessen wählen - der Migrationsassistent möchte nun sicherstellen, dass der Quellserver kein Domänencontroller mehr ist. 

Deinstallation Exchange 2003

Bevor der SBS 2003 demotet und entfernt werden kann, muss der Exchange-Server auf dem Quellserver weichen. Bevor das geschehen kann, müssen auf dem Zielserver in der Exchange-Shell (als Admin) folgende Befehle ausgeführt werden:

cd \
cd '.\Program Files\Microsoft\Exchange Server\V14\Scripts'
Set-AddressList „Alle Benutzer" -IncludedRecipients MailboxUsers
Set-AddressList „Alle Gruppen" -IncludedRecipients MailGroups
Set-AddressList „Alle Kontakte" -IncludedRecipients MailContacts
Set-AddressList „Öffentliche Ordner" -RecipientFilter { RecipientType -eq „PublicFolder" }
Set-GlobalAddressList „Globale Standardadressliste" -RecipientFilter {(Alias -ne $null -and (ObjectClass -eq „user" -or ObjectClass -eq „contact" -or ObjectClass -eq „msExchSystemMailbox" -or ObjectClass -eq „msExchDynamicDistributionList" -or ObjectClass -eq „group" -or ObjectClass -eq „publicFolder")
.\MoveAllReplicas.ps1 -Server FWEX2003 -NewServer FWEX2010


Nun müssen die Connectoren unter Name (Exchange) > Administrative Gruppen > (...)administrative Gruppe(...) > Routinggruppen > Routinggrupe > Connectors und Name (Exchange) > Administrative Gruppen > Exchange Administrative Group (...) > Routinggruppen > Exchange Routing Group (...) > Connectors entfernt werden. Bei uns lies sich der POP3-Connector-Manager nicht entfernen.

Zu guter Letzt muss die Softwaresteuerung geöffnet werden und Windows Small Business Server "geändert/entfernt" werden. Bis zur Komponentenauswahl durchklicken und dann den Exchange-Server zur Deinstallation auswählen. Während der Deinstallation des Exchange-Servers bittet das Setup um die SBS 2003 Disc 2. Bei uns sind folgende Fehler / Handycaps aufgetreten:

1. Die Empfängeraktualisierungsrichtlinie wurde automatisch immer wieder auf den Quellserver gestellt (wenn wir zu lange warteten), weshalb die Deinstallation der Exchange-Server-Komponente nicht möglich war und laufend gemeldet wurde, dass der Quellserver noch für domain.tld zuständig wäre.
2. Die Deinstallation der Exchange-Server-Komponente war ebenfalls nicht möglich, da die Übertragung eines Postfachs nicht funktionierte - die Fehlermeldung des Setups sagte nur aus, dass nicht alle Postfächer übertragen wurden. Ob die Synchronisation der Postfächer erfolgreich verlief bzw. welchen Status diese aktuell haben, kann mit Get-MoveRequest für alle angefragten Postfächer eingesehen werden. Sollte  ein Postfach den Status "Failed" wie bei uns tragen, kann die MoverRequest mit Get-MoveRequest -MoveStatus Failed | Resume-MoveRequest erneut angestossen werden. Da es bei uns nicht funktionierte, exportierten wir eine PST im Outlook des Benutzers und konnten das Problem mit Deaktivierung des Postfaches im SBS 2011 so umgehen. Dies ist ein schmutziger Workaround.

Zum Abschluss muss der Quellserver mittels dcpromo demotet werden, sodass dieser nicht mehr Teil der Domäne bzw. nur noch Member ist. Bei uns traten folgende Fehler auf:

1. Die Fehlermeldung, dass der Quellserver noch der Globale Katalog des AD wäre und man sicherstellen müsse, dass Clients im AD noch die Möglichkeit zur Anmeldung an einem anderen Server haben müssten. Dcpromo bricht an diesem Punkt ab.
   
   Lösung
   
   1. Öffnen von Active Directory-Benutzer und -Computer
   2. erweitern von domäne.tld, erweitern von Domain Controllers
   3. Rechtsklick auf den Zielserver
   4. Unter allgemein "NTDS-Einstellungen" anklicken
   5. Im neuen Fenster unter Allgemein "Globaler Katalog" aktivieren
   6. gpupdate /force auf beiden Servern durchführen & Neustarten (sofern dazu aufgefordert)
   7. 1-2 wiederholen und die Schritte 3-5 mit dem Quellserver durchführen
   8. erneutes gpupdate /force auf beiden Servern
2. Die Fehlermeldung, dass der Domänencontroller nicht kontaktiert werden könne. Entweder wäre der AD-Server nicht erreichbar oder die Domäne könne nicht aufgelöst werden. Selbst mit ipconfig /flushdns, deakivieren des DNS-Servers auf dem Quellserver und Kontrolle der Einstellung gelang es uns nicht, diesen Fehler zu beheben
   
   Als letzte Option kann man das Austragen mit dcpromo /forceremoval erzwingen. Man sollte sich sicher sein, dass man von diesem Server nichts mehr benötigt!
   
   Dies hat zur Folge, dass auf dem Zielserver händisch aufgeräumt werden muss (den Quellserver händisch löschen)

Fazit

Nach dem erforderlichen Neustart beider Server, mussten wir feststellen, dass der Zielserver nicht sauber als Domainserver konfiguriert wurde. Das hatte zur Folge, dass die durchgeführte Migration für uns beendet und nutzlos war. Wir  denken, dass die von Microsoft beschriebene Vorgehensweise leider nicht vollkommen korrekt ist und sehr viele Steine im Weg zur erfolgreichen Migration liegen. Fraglich ist, ob es nicht deutlich schneller und effektiver ist, wenn die Outlook-Datendateien sauber exportiert werden und man alles in einer neuen Domäne sauber neu integriert.

Diese Tipps dienen als knowledgebase zur internen Nutzung. Es steht natürlich jedem frei, dieses Wissen auf eigene Gefahr anzuwenden. Wir empfehlen, den Rat Ihres Netzwerk-Administrators einzuholen, oder uns mit der Lösung Ihres Problems zu beauftragen. Verwendete Markennamen und Warenzeichen sind Namen/Eigentum der jeweiligen Firmen/Hersteller.