Normalerweise migriert man einen Windows Small Business Server zu einer neueren Version mit Hilfe der Anleitungen von Microsoft. Was aber, wenn man einen SBS hat, dem es nicht gerade gut geht? Damit ist z.B. gemeint, das Komponenten nicht installiert (Setup nicht abgeschlossen) oder gar (gewaltsam) entfernt wurden, das System jenseits der Assistenten konfiguriert wurde und schlicht weg in keinem guten Zustand ist. Noch dazu die Auslastung mehr als hoch ist, so ist z.B. der Arbeitsspeicher voll und das System lagert permanent aus, das Storagesubsystem ist am Anschlag, so dass das Öffnen von Firefox durchaus zwei Minuten benötigt, die Konsole von Acronis sogar mindestens 10 Minuten, usw. Im konkreten Fall gehört da auch dieser Fehler beim Exchange Server 2003 dazu.

Recht einfache Antwort: Man versucht, so viele Altlasten wie möglich nicht zu übernehmen. Konkret ging es mir darum, möglichst das Active Directory und vor allem den Exchange Server samt seiner Einstellungen soweit wie möglich nicht zu übernehmen. Schließlich sollten keine Fehler mitwandern. Nun muss man im Vorfeld gleich darauf hinweisen, das z.B. kein Faxdienst und auch kein SharePoint verwendet wurden. So das es primär um die Benutzerkonten, die Daten auf den Freigaben und den Exchange geht.

Nun könnte man hergehen und sagen, man macht einen Schnitt, baut ein komplett neues System/Netz auf und arbeitet mit ex-/import von verschiedenen Dingen. Das ging in diesem Fall gleich aus mehreren Gründen nicht. So gibt es z.B. Abhängigkeiten zwischen den SIDs der Benutzer und Gruppen und einem CRM, “einfach” neu machen wäre mit erheblichen Aufwand verbunden gewesen. Von den zu erwartenden Ausfallzeiten, die auf Kundenwunsch praktisch nicht vorhanden sein dürfen, ganz zu schweigen.

So kam es, das die Migration über eine Woche verteilt stattfand und zwar weitgehend Abends bzw. Nachts. Einzig das CRM wurde während der regulären Geschäftszeiten migriert, da aber dafür schon die Dateien mittels robocopy weitgehend synchronisiert waren, musste nur noch die zugehörige SQL-Datenbank umziehen und den Arbeitsplätzen die Änderung mitgeteilt werden. Das soll aber nun nicht Bestandteil dieses Beitrags sein.

Benutzerkonten und Gruppen migrieren

Der klassische Weg Objekte wie Benutzer und Gruppen im Active Directory zu einem neuen Server zu migrieren besteht in der Verwendung des ADMT:

• ADMT 3.0 für Windows Server 2003 herunterladen und installieren. Die Installation muss auf dem Windows Small Business Server 2003 erfolgen!
• In der Quelldomäne eine domänen-lokale Gruppe mit dem Namen “QUELLDOMÄNE$$” anlegen.
• Die beiden SBS müssen sich via DNS auflösen können. Zu diesem Zweck jeweils eine bedingte Weiterleitung auf den beiden Server einrichten.
• Das ADMT mit folgendem Befehl ausführen:

runas /netonly /user:ZIELDOMÄNE\Administrator "mmc C:\Windows\ADMT\migrator.msc"

Troubleshooting: Wird beim Ausführen via “runas” das Setup des ADMT erneut angestartet, zunächst den Vorgang abbrechen (es wäre ohnehin nicht erfolgreich), den Benutzer ab- und wieder anmelden. Hilft das auch nicht, so muss der SBS 2003 neu gestartet werden.

Nun können die Benutzer und deren Gruppen migriert werden. Auf die Migration der Kennwörter wurde bewusst verzichtet, da der PES nicht mit Windows Server 2003 funktioniert und bei dem Kunden sowieso fast jeder das gleiche Kennwort hat (wir haben’s nicht “verbrochen”, wir “baden’s” nur aus!).

Dateien und Ordner migrieren

Zwar gibt es die Möglichkeit, Dateiserver zu migrieren, in diesem Fall sollten aber nur die Freigabenamen als auch die Berechtigungen und die darin enthaltenen Dateien und Ordner übernommen werden. So installiert man zunächst robocopy für Windows Server 2003 (aus den Ressource Kit Tools) auf dem SBS 2003 und erstellt ein Skript für einen geplanten Task. Natürlich kann man den Vorgang auch direkt ausführen. Da aber das Tagesgeschäft nicht gestört werden soll, erfolgte der Kopiervorgang über Nacht.

Der eigentliche Befehl sieht dann z.B. so oder so ähnlich aus:

robocopy \\QUELLE\FREIGABE \\ZIEL\FREIGABE /mir /sec /xj

Statt des UNC-Pfades kann bei der Quelle auch der lokale Pfad verwendet werden.

Wichtig an dieser Stelle ist, das der Benutzer die notwendigen Berechtigungen auf dem Ziel hat. Alternativ kann man natürlich auch ein Netzlaufwerk verwenden.

Ferner müssen den Arbeitsplätzen die neuen Netzlaufwerke bzw. die Änderungen daran bekannt gemacht werden. In diesem Fall wurde schlicht das Anmeldeskript geändert.

Daten aus dem Exchange Server 2003 exportieren

Die besondere Herausforderung bestand bei diesem Server darin, aus dem angeknacksten Exchange Server die Daten (Kontakte, Termine, E-Mails) herauszubekommen. Für Postfächer < 2 GB eignet sich dafür Exmerge, um den Vorgang z.B. via Skript durchführen zu können. Allerdings ist die MAPI-Schnittstelle nicht besonders performant, was bei diesem ausgelasteten Server die Aufgabe zusätzlich erschwert hätte.

So wurde die Entscheidung getroffen, mittels Exmerge lediglich die Termin- und Kontaktdaten zu exportieren und die E-Mails mittels MailStore Server zu ex-/importieren bzw. zu migrieren. Dieses Vorgehen hat den Vorteil, das man bereits im Vorfeld (und vor allem bei großen Postfächern) bereits fleißig archivieren kann, und das noch dazu auf einem gesonderten System, ohne dadurch den ohnehin schon ausgelasteten Server allzu groß zu beeinflussen.

Bevor das E-Mail-Thema live ging, wurde zunächst ein MailStore Server auf einem Leihsystem installiert und konfiguriert. Damit das Zeitfenster für die Umstellung möglichst gering bleibt, wurde bereits zwei Nächte zuvor die Archivierung der einzelnen Postfächer durchgeführt, so das am eigentlichen Migrationstag nur noch die Differenz erfasst werden und im Anschluss alle E-Mails auf den neuen Server exportiert werden musste. Am Tag X wurde dann die SMTP-Zustellung an den SBS 2003 auf den SBS 2011 geändert (entsprechende Konfiguration in einer Securepoint UTM) und der Export der archivierten E-Mails angestoßen werden. Ferner wurde mittels Exmerge die Kontakte und Termine exportiert.

Man könnte auch Outlook verwenden, um die Postfächer zu exportieren. Wer möchte sich aber schon eine oder zwei Nächte lang hinsetzen und Postfach für Postfach einhängen und exportieren?!

Auf diese Art wurden über 64.000 E-Mails umgezogen. Leider machte uns der neue Server unerwartet etwas Probleme, wie man hier Nachlesen kann:

MailStore Server, Export zu Exchange-Postfach und Fehler EWS 507

SBS 2011 Standard / Exchange Server 2010 und die Postfachgröße von 2 GB

Daten in den Exchange Server 2011 importieren

Dank Exmerge liegen die Kontakt- und Termin-Daten der Benutzer in Form von *.pst-Dateien (Outlook-Datendateien vor) und können mittels PowerShell oder alternativ mittels Outlook importiert werden. Der erstgenannte Weg ist dabei letztlich der Schnellere.

Computer migrieren

Die einzelnen PCs wurden im übrigen nicht mittels ADMT übernommen, es hätte im übrigen mit ADMT v3.0 und Windows 7 auch nicht funktioniert, sondern per TeamViewer in einer nächtlichen Aktion “abgeklappert”. Da es mit gut 15 PCs eine noch recht überschaubare Menge war, konnte das gut bewältigt werden. Zuvor wurde der DHCP-Server auf dem SBS 2003 deaktiviert und auf dem SBS 2011 aktiviert.

Lokale Benutzerprofile

Der Kunde hatte bis zur Migration keine servergespeicherten Benutzerprofile (roaming profiles). Angedacht war das schon ein paar Mal, nicht zuletzt aus dem Grund, da die Mitarbeiter mittlerweile nicht immer am gleichen Platz sitzen. Nur durchgeführt wurde es aufgrund des knappen Plattenplatzes auf dem alten Server und der hohen Last eben Diesem bislang nicht.

Aber irgendwie mussten die Benutzerprofile übernommen werden. Die Lösung dazu war der User Profil Wizard von ForensiT.

Nicht vergessen

Hat man ein öffentliches Zertifikat im IIS, z.B. für OWA, ActiveSync usw. so muss Dieses auf dem SBS 2003 samt Schlüssel ex- und auf dem SBS 2011 importiert werden.

Je nach Verwendung eines Servers können noch mehr Schritte notwendig sein. In diesem Fall war das hier beschriebene die Hauptaufgabe. Der Umzug eines SSL-Zertifikats für OWA ist dabei kein wirkliches Thema gewesen.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.