Fileserver Migration

Ein alltägliches Szenario. Ein betagter Fileserver soll auf ein neues Betriebsystem wandern. Das kann z.B. eine V2V Migration sein, etwa bei Wechsel von Server2000 auf Server2008. Aber auch eine P2V Migration mit gleichzeitigem Systemwechsel.

Der reine Transfer der Nutzdaten ist nicht wirklich problematisch. Tools wie z.B. Robocopy sind hier wertvolle Helfer. Schwieriger kann da schon die Wiederherstellung der Freigaben sein, vor allem wenn sich hier über die Jahre komplexe Strukturen entwickelt haben. Mit einem kleinen Trick lassen sich all diese Einstellungen leicht transferieren. Bei den Berechtigungen muß es sich jedoch um Benutzerkonten der Domäne handeln. Lokale Benutzer des Quellsystems werden vom Zielsystem nicht erkannt.

Achtung! Diese Methode funktioniert nur, wenn der Fileserver kein Domaincontroller ist!

Ablauf

  • Zielserver in die Domäne aufnehmen (wichtig für ACL) und die Fileserver-Rolle (Server 2008 und später) aktivieren.
  • Auf dem Zielsystem keine Shares anlegen! Diese werden später alle überschrieben.
  • Zunächst müssen die Nutzdaten zum Zielsystem. Bei P2V Szenarien hilft hier Robocopy sehr gut. In rein virtuellen Landschaften genügt es unter Umständen, die VMDK Dateien am Quellsystem zu deregistrieren und ins Zielsystem einzuhängen. Bei beiden Verfahren gehen die Shareinformationen verloren. Diese gilt es später wiederherzustellen.

Robocopy

Robocopy sollte auf dem moderneren System (Zielsystem) ausgeführt werden. Die Erfahrung zeigte, daß ein PULL von einem Windows Server 2008 R2 wesentlich schneller ist, als ein PUSH von einem Windows Server 2003.

robocopy <source> <target> /MIR /SEC /SECFIX /DCOPY:T /R:1 /W:1 /XD "\$RECYCLE.BIN" "\System Volume Information" /LOG:C:\Users\<myuser>\Desktop\transfer.log /TEE /V /NDL /NFL

<source> : UNC Pfad zum Quellserver. Beispiel: \\Server1\d$

<target> : Lokales Volume auf dem Zielserver. Beispiel: D:

 

  • Die Logging Optionen /TEE /V /NDL /NFL bewirken, daß im Log nur Fehlermeldungen erscheinen. Kopierte Files und Ordner werden nicht gelistet. Das hat den angenehmen Nebeneffekt, daß das Log nicht auf mehrere MB anwächst. /XD schließt Verzeichnisse aus. Wichtig ist hier, daß am Ende des Verzeichnis Namens kein Backslash angefügt wird. Verzeichnisnamen ohne Sonderzeichen oder Leerzeichen benötigen keine Anführungszeichen. Z.B. /XD d:\WSUS
  • Der Kopiervorgang muss fehlerfrei beendet werden. Eventuelle Kopierfehler [FEHLER 5 (0x00000005)] beruhen auf fehlenden Zugriffsrechten. Der kopierende Nutzer (Domain-Admin) muß Vollzugriff auf die Quelldaten haben. Oft funktioniert der erste Durchgang und es kommt beim 2. Durchgang zu Problemen, da der Admin auf dem Zielverzeichnis keine Schreibrechte hat und die Daten nicht aktualisieren kann. Das Problem muss auf der Quellseite behoben werden (ggf. Besitz übernehmen und Rechte setzen).

Export der Share Informationen

  • Am Quellsystem den Registry Editor regedit.exe oder regedt32.exe öffnen. und zu folgendem Key navigieren:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Shares
  • Den Schlüssel “Shares” exportieren als .reg Datei und auf das Zielsystem übertragen.
  • Am Quellserver einen Shutdown durchführen. Bei virtuellen Systemen danach den LAN Adapter deaktivieren, bei realen Servern das LAN-Kabel entfernen. Irgend ein Held kommt immer auf die Idee, das System zu starten und das verursacht ab jetzt Probleme.

Wechsel der Identität

  • Computerkonto des Quellservers im Active-Directory entfernen. Das ist wichtig, denn unser Zielserver wird jetzt die Rolle des Quellservers übernehmen.
  • IP Adresse des Zielservers auf die IP Adresse des Quellservers ändern.
  • Name des Zielservers in Namen des Quellservers ändern [reboot].

Import der Shares

  • Nach dem Neustart haben wir alles im Zielsystem (IP, Name, Files). Es fehlen nur noch die Shares. Sie werden durch Import des Registry-Keys (zuvor gespeicherte .reg Datei) importiert. Rechtsklick auf die .reg Datei und im Kontextmenü “Zusammenführen” auswählen. Die Warnung ignorieren, denn unser Zielsystem sollte bis jetzt keine eigenen Shares haben.
  • Zielserver neu starten

 Failback

Sollte doch etwas ganz schief gehen, kann man das alte System reaktivieren.

  • Neuen Server abschalten. Netzverbindung trennen.
  • Den alten Server starten. LAN Verbindung wieder aktivieren.
  • Das alte System glaubt noch in der Domäne zu sein, aber seit seiner Abschaltung hat sich einiges verändert. Es muss der Domäne nochmals beitreten. Das geht mit einem einfachen Trick, ohne den Umweg über die Workgroup. War der Server zuvor mit voll qualifiziertem Namen der Domäne beigetreten (mydomain.mycompany.com), so kann man nochmals mit dem Kurznamen beitreten (mydomain).

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert