Im meinem Außenstandort in Neufahrn habe ich einen Hyper-V-Host mit dem Namen WS-RDS3 aufgestellt. Dieser betreibt die virtuellen Maschinen mit den Services, die ich dort benötige. Der Server läuft aktuell mit Windows Server 2016.

Der Server soll auf Windows Server 2019 umgestellt werden. Dazu sind Anpassungen an den Services notwendig.

Die Umstellung findet in der Zeit des Betriebsurlaubes zwischen den Jahren (zwischen Weihnachten und Silvester) statt. Es kann also mit einer Downtime gearbeitet werden.

Die Hardware soll wiederverwendet werden.

Der Server hat eine durchaus bewegte Vergangenheit hinter sich. Ich wollte ursprünglich nur einen Server in dem Standort aufstellen. Meine Kolleginnen sollten darauf alle Dienste und Anwendungen vorfinden, die zum Arbeiten erforderlich sind.

Da die Hardware sehr begrenzt ist (Quadcore, 16GB RAM, 120GB SSD, 1x Gbit) musste ich Dienste auf den Servern zusammenfassen. Auch eine RDP-Anmeldung sollte möglich sein (daher der Name WS-RDS3). Im Nachhinein war das keine so gute Idee. Aber mit dieser Migration kann ich jetzt einige Korrekturen vornehmen.

Zuerst verschaffe ich mir einen Überblick über die installierten Rollen und Features:

Der Server ist also ein Hyper-V-Host, ein Fileserver mit DFS-Namespace und DFS-Replica, und der lokale Druckserver.

Über Hyper-V werden diese beiden VMs bereitgestellt: ein Domain Controller mit DHCP und DNS und eine virtuelle PFSense (Firewall):

Alle Freigaben musste ich direkt auf die Systempartition ablegen – genauso auch die Dateien der virtuellen Maschinen. Für eine zusätzliche Partitionierung war einfach kein Platz mehr:

Nur eine weitere Festplatte ist noch über USB angeschlossen. Auf dieser werden Datensicherungen gespeichert. Auf dem Systemdatenträger ist kaum noch freier Platz vorhanden:

Vielleicht wird Speicherplatz durch nicht mehr benötigte Dateien belegt? Ich starte die Datenträgerbereinigung und durchsuche dabei auch Systemverzeichnisse. Naja, besser als Nichts:

Warum ich nicht einfach eine weitere Festplatte einbaue? Ganz einfach: der Server ist eigentlich ein Mini-PC. Der kann nur eine 2,5“-Festplatte aufnehmen. Und mit externen Datenträgern möchte ich nicht in Kombination mit virtuellen Maschinen arbeiten.

Wie sieht es denn mit den anderen Ressourcen aus? Der Arbeitsspeicher ist noch etwas belastbarer. Aber eine Aufrüstung ist nicht möglich. Alle Slots sind belegt:

Ich durchsuche die installierten Anwendungen. Lokal ist ein Office 2016 vorhanden. Dieses war für den RDP-Zugriff gedacht, wird aber nicht (mehr) benutzt. Die Anmeldung ist mit DUO-Zweifaktor-Authentifizierung abgesichert. Und für eine spezielle Dateisicherung ist ein DPM-Agent installiert

Als weitere Besonderheit ist das Feature Bitlocker konfiguriert. Damit wird die gesamte SSD verschlüsselt.

Und zusätzlich habe ich meinen Exchange-Servern ein DAG-Witness-Share auf dem Server bereitgestellt.

In der Rolle Printserver ist nur ein Drucker freigegeben. Diese Freigabe hatte aber immer wieder Probleme und daher wird der Drucker von den Clients direkt angesprochen. Die Rolle wird nicht mehr verwendet.

Wenn ich die erforderlichen Services um die nicht mehr benötigten bereinige, dann verbleiben die Rollen Hyper-V und der Fileservice. Diese beiden haben keinen Bezug zueinander und sollten daher auch nicht in einem Betriebssystem konsolidiert sein. Daher werde ich den Server WS-RDS3 durch die Server WS-FS3 und WS-HV3 ersetzen. WS-FS3 wird dabei als neue VM unter WS-HV3 laufen und zusammen mit den Freigaben auch den DFS-Namespace und die DFS-Replikation bereitstellen.

Die zusätzliche VM kann mit dem verbleibenden Arbeitsspeicher gut auskommen. Für die CPU und die Netzwerkkarte sehe ich keine Engpässe.

Aber die derzeitige SSD wird mit 120GB nicht mehr ausreichen. Daher werde ich die SSD durch eine neue ersetzen. Eine SSD mit 500GB sollte hier bis zum Ende der Hardwarelaufzeit genügen. Dies spielt mir auch beim Migrieren der VMs positiv zu, denn so muss ich die VMs im Vorfeld nicht erst verschieben. Ich werde nach der Installation des WS-HV3 auf der neuen SSD einfach die alte SSD über USB anschließen und die VMs kopieren.

Die Migration der Server wird in 2 Schritten erfolgen:

• Zuerst separiere ich den Fileservice auf eine neue VM. Damit kann ich auch die Lieferzeit der neuen SSD überbrücken, auch wenn es sehr eng auf der alten SSD werden wird.
• Im zweiten Schritt wird der Server dann als WS-HV3 neu installiert.

Der neue Server WS-FS3 wird als ServerCore laufen. Ich habe für die Konfiguration der Services ja noch die beiden anderen Server WS-FS1 und WS-FS2, welche mit einer GUI installiert sind. Zudem habe ich mein Basefile mit dem Feature On Demand „Application Compatibility“ vorbereitet. Der Server hat also einige administrative Tools dabei. Zuerst kopiere ich die Basefile auf die alte SSD. Diese hatte ich ja im Vorfeld schon bereinigt:

Nun erstelle ich die virtuelle Maschine. Alle neuen Server haben bei mir die Generation 2:

Die Basefile füge ich im Nachgang ein. Ebenso passe ich die Werte für die CPU und den Arbeitsspeicher an. Aber auch die anderen Werte gehe ich kurz durch:

Nach dem Start der VM durchläuft die mit syspre vorbereitete VHDX die Hardwareerkennung und startet danach den Out-Of-Box-Experience-Modus, in dem das Passwort des lokalen Administrators eingegeben wird:

Danach starte ich das seit Windows Server 2008R2 bekannte Script sconfig und beginne die Grundkonfiguration. Zuerst benenne ich mit der Option 2 den Server um. Danach ist ein Neustart fällig:

Vor dem Domain Join erstelle ich noch das Computerkonto in der richtige OU. So greifen vom ersten Start als Domain Member die richtigen GPO. Den Join führe ich mit meinem Account admin-setup aus:

Die Änderung im Active Directory kann einen Augenblick für die Replikation gut gebrauchen. Daher kümmere ich mich derweil um die statische IPv4. Laut meiner Bestandsliste sollte die 192.168.101.3/24 frei sein. Ich pinge die Ressource an. ICMP kann aber durchaus geblockt sein. Daher prüfe ich zusätzlich von einem Rechner im gleichen Subnetz mit arp -a den ARP-Cache. Auf Layer 2 im OSI-Modell wird nicht gefiltert. Sollte das System mit dieser IP-Adresse online sein, dann muss es seine MAC-Adresse auf Nachfrage publizieren. Aber dem ist nicht so. Die IPv4 scheint frei zu sein:

Mit sconfig und der Option 8 konfiguriere ich die statische Adresse und die anderen Optionen (Gateway, DNS):

Nun ist es Zeit für den Domain Join. Auch diesen führe ich mit sconfig aus:

Nach dem Neustart ist der Server auch mit allen Gruppenrichtlinien versorgt. Noch kommt er ins Internet. Daher führe ich die Aktivierung des Betriebssystems aus. Mit slmgr.vbs und ipk #####-#####-#####-#####-##### installiere ich den ProductKey. Und mit slmgr /ato starte ich die Online-Aktivierung. Beim ersten Versuch kam der Server leider nicht ins Internet. Daher war eine temporäre Freischaltung erforderlich. Der zweite Versuch war dann erfolgreich:

Ein Fileserver benötigt Festplatten für seine Freigaben. Diese füge ich als zusätzliche VHDX an die VM an. Der Fileserver im Außenstandort hat nur wenige GB zu verwalten. Daher soll hier eine kleine Platte genügen:

Zusätzlich möchte ich gerne Schattenkopien erstellen lassen. Diese sollen auf einer weiteren VHDX abgelegt werden:

Alle weiteren Aktionen könnte ich lokal nur mit der PowerShell vornehmen. Das lohnt sich aber bei dem kleinen Server nicht wirklich. Daher verwende ich das Remoting des Server Managers auf meinem Admin Server. Zuerst füge ich den Server zur Liste hinzu:

Jetzt kann ich die im laufenden Betrieb angefügten VHDX remote online nehmen:

Je VHDX erstelle ich ein Volume. Das erste soll die Freigaben aufnehmen und bekommt daher einen Laufwerksbuchstaben:

Das zweite Volume soll die Schattenkopien des ersten aufnehmen. Da ist kein Laufwerksbuchstabe erforderlich:

Als nächstes installiere ich die erforderlichen Rollen und Features:

Nach der Serverauswahl selektiere ich die Rolle Dateiserver und beide DFS-Komponenten. Den Ressourcen-Manager für Dateiserver (File Server Resource Manager = FSRM) benötige ich wegen einer Besonderheit: Ich arbeite bei einer Freigabe mit Ressourcen-Eigenschaften. Diese stehen nur mit dem FSRM zur Verfügung:

Für die Datensicherung benötige ich das Windows Server Backup. Ein Dateiserver kann aber auch die Windows Suche konfiguriert bekommen, damit Clients schneller Dateien finden können. Doch dieses Feature wird nicht angeboten:

Zum Vergleich sieht man hier den Auswahldialog eines anderen Servers. Die Funktion „Windows Search“ steht (und stand noch nie) im Server Core zur Verfügung…

Egal, dann geht es ohne weiter:

Der Server Core unter Windows Server kann mit dem Feature On Demand „Application Compatibility“ erweitert werden. Das hatte ich bereits in der Basefile vorgenommen. Damit steht mir im Server Core der Windows Explorer zur Verfügung:

So kann ich lokal die Ordner, Freigaben und Berechtigungen konfigurieren. Oder? Leider fehlt hier der Reiter „Sicherheit“ komplett. Was soll denn das bitte? OK, dann erstelle ich nur die beiden Hauptverzeichnisse in dem neuen Volume:

Die ACL muss ich mit dem Windows Explorer auf einem GUI-Server über den UNC-Pfad konfigurieren. Ich habe eine besondere Rechtegruppe. Deren Mitglieder sind die Fileserver-Administratoren und erhalten Vollzugriff auf alle Shares. Zuerst entferne ich die vererbten Berechtigungen auf dem Hauptverzeichnis aller Freigaben:

Nur das System und die lokalen Administratoren haben noch Zugriff. Zusätzlich nehme ich die Fileserver-Admins in die Liste auf:

Das Hauptverzeichnis für alle Freigaben ist einsatzbereit. Die hier konfigurierten Rechte sollen in alle Unterverzeichnisse (Freigaben) vererbt werden.

Die Freigaben werden nicht direkt angesprochen. Ich betreibe 2 AD-integrierte DFS-Namespaces. Hier werden alle Freigaben hinter einer Verknüpfung maskiert. So kann ich mehrere Ziele erreichen:

• Ausfallsicherheit: stehen mehrere Server hinter einem Link, dann kann der Client zwischen beiden wechseln. Voraussetzung ist dafür natürlich ein identischer Datenbestand. Den erreiche ich durch ein überwachtes DFS-Replica.
• Verbindungsoptimierung: Ein Link mit mehreren Zielen kann den Active Directory Standort zur Auswahl des Zielservers verwenden. So kommunizieren Clients immer mit dem Server, der über die „beste“ Verbindung erreichbar ist.
• optimale Migrationsszenarien: Genau diese nutz ich hier. Ich kann den Link zu einem Ziel zentral verändern und so die Clients ohne deren Wissen auf einen anderen Server umleiten

Clients fragen für die Zielfindung die DFS-Namespace-Server. Ich habe diesen Service auf allen Fileservern installiert. So soll es auch weiter beibehalten werden. Daher nehme ich den neuen Fileserver WS-FS3 in die Liste der Namespace-Server auf. Diese Aktion muss je Namespace vorgenommen werden:

Der Namespace wird selber in einer Freigabe abgebildet. Diese erstelle ich direkt mit dem Assistenten:

Nun stehen in Neufahrn (meinem Außenstandort) auch 2 Namespace-Server zur Verfügung:

Auf dem zweiten Namespace wiederhole ich die Aktion:

Die Einstellungen werden von den Fileservern im Active Directory abgespeichert. Eine Änderung kann daher einige Minuten Zeit benötigen. Ich editiere mein DFS auf dem Server WS-FS1. Angenommen, dieser kommuniziert mit meinem WS-DC2, dann muss die Änderung folgende Hops nehmen (WS-DC1 ist ein IP-Bridgehead-Server):

WS-FS1 ==> WS-DC2 ==> WS-DC1 ==> WS-DC3 ==> WS-FS3

Daher bekommt die Veränderung einen Moment Zeit. Danach entferne ich den nicht mehr benötigten DFS-Namespace-Server WS-RDS3. Achtung: bei der Markierung des Servers im mittleren Teil des Fensters werden 2 Löschen-Schalter im Aktionsmenü sichtbar. Einer entfernt den Server aus dem Namespace. Der andere entfernt den gesamten Namespace!!! Klickt hier bitte bewusst und lest die Warnmeldung genau durch. Administratoren neigen dazu, Rückfragen ungelesen zu bestätigen…

Altenativ kann aber auch über das Kontextmenü gelöscht werden:

Nun verändere ich noch die Cachedauer für die Clients. Diese merken sich Antworten vom DFS. Bei einem Ausfall kann das recht lästig sein. Und es spricht nichts dagegen, wenn die Clients häufiger anfragen. 120 Sekunden ist ein praktikabler Wert:

Hier sieht man den Cache des Clients bei der Arbeit. Den alten Server habe ich bereits entfernt. Aber die vorab eingestellten 120 Sekunden sind noch nicht vorbei:

Aber eine kleine Pause später verwendet der Client den richtigen Server und hat seinen Vorgänger vergessen:

Der Namespace wird jetzt vom neuen Server bereitgestellt. Dieser lenkt die Benutzer aber immer noch auf den alten Fileserver WS-RDS3. Diese Einstellung muss noch angepasst werden.

Davor muss ich aber die Daten vom alten auf den neuen Server migrieren. Und ich erwähnte es bereits: Ich verwende eine spezielle Form der Zugriffsberechtigung. Diese gehört zu den unter Windows Server 2012 eingeführten „Dynamic Access Contols“. Dabei wertet der Fileserver zusätzlich zur Gruppenmitgliedschaft des Benutzers auch Eigenschaften der Ressource (also der Dateien und Ordner) aus. Und diese Ressourcen stellt der File Server Resource Manager bereit. Die Konsole ist auf dem Server Core nicht verfügbar. Daher starte ich sie auf dem Admin Server. Wie gewohnt kann ich hier die Verbindung mit einem anderen Server herstellen:

Leider fehlt für diese Aktion eine Firewall-Ausnahme. Diese setze ich auf dem Server Core WS-FS3 lokal. Hier kann ich eine MMC mit dem Snapin für die Firewall starten und die bereits vorhandenen Regeln aktivieren:

Danach funktioniert auch der Remotezugriff. In der Ebene „Klassifizierungseigenschaften“ werden meine Resource-Propierties angezeigt:

Diese habe ich zentral im Active Directory erstellt. Nur die PowerShell und das Active Directory Administrative Center sind dazu in der Lage:

Da diese Werte auf dem neuen Server vorhanden sind, kann ich nun die Daten migrieren.

Die eigentliche Datenübertragung möchte ich mit der DFS-Replikation durchführen. Das bietet sich durch den DFS-Namespace an. Dazu muss ich aber vorher die Freigaben erstellen, denn die Replikation bezieht sich auf den Inhalt von Freigaben.

Für jede Freigabe habe ich einen Ordner unter e:\Freigaben auf dem alten Server. Mit Robocopy kopiere ich genau diese Ordner auf den neuen Server. Die Option COPYALL nimmt dabei auch die Sicherheitseinstellungen mit. Mit LEV:2 geht der Befehl nicht weiter in die Verzeichnistiefe:

Der Ordner DFS-Roots war auf dem alten Server der Speicherort des DFS-Namespaces. Dieses Verzeichnis habe ich auf dem neuen Server bereits eine Ebene höher als E:\DFS-Namespaces erstellt. Eine Kontrolle der Übernahme der Sicherheitseinstellungen ist durch eine Stichprobe immer sinnvoll. Hier sieht man auch meine Form des Dynamic Access Control. Die Berechtigung ist an Bedingungen geknüpft. Diese lassen die sonst statischen ACL dynamisch werden:

Aber wozu das Ganze?

Normalerweise werden je Verzeichnis mit differenzierten Berechtigungen üblicherweise 2 Gruppen benötigt: eine Lesegruppe und eine Schreibgruppe. Meine Standard-ACL verlangt noch nach einer List-Gruppe, mit der durch Verzeichnisse durchnavigiert werden kann.

Durch das von mir angewandte Gruppenmodell AGDLP (Account ==> Globalgroup ==> LocalDomaingroup ==> Permission) sind diese 3 Gruppen vom Scope her DomainLocal. Zusätzlich benötige ich noch 2 weitere globale Gruppen, welche zwischen den Benutzern und den LD-Gruppen verschachtelt sind. So ergibt sich dieses Berechtigungsmodell für jedes Verzeichnis mit expliziter Berechtigung eine Menge von 5 Gruppen im Active Directory:

Je nach Anzahl der Verzeichnisse mit eigenem Berechtigungswunsch kommt schnell eine stattliche Menge von Gruppen zusammen. Das wollte ich im Verzeichnis Jungbrunnen vermeiden und gleichzeitig die Rechte sehr granular vergeben. Genau das liefert Dynamic Access Control.

Für meine Freigabe Jungbrunnen gibt es genau 2 Sicherheitsgruppen:

• LD-DAC-Mitarbeiter
• LD-DAC-Verwaltung

Man erkennt recht einfach, dass hier in 2 unterschiedliche Personenkreise differenziert werden soll. Die ACL wirkt nur auf dem Hauptordner E:\Freigaben\Jungbrunnen und wird komplett vererbt. DAC arbeitet mit den Bedingungen, welche im unteren Teil des Bildes sichtbar sind:

Man erkennt, dass jeder Ordner 2 Ressource-Eigenschaften hat. Diese legen fest, ob ein Recht vergeben wird oder nicht. Editieren kann ich diese in einem zusätzlichen Reiter in den Eigenschaften des Windows Explorers:

Die Werte und deren Optionen kommen vom Active Directory.

Und so arbeitet die Regel: Steht in der Ressource der Eigenschaftswert „JB-Berechtigung-Mitarbeiter“ auf „schreiben“ und ist der Benutzer Mitglied in der Gruppe LD-DAC-Mitarbeiter oder steht in der Ressource der Eigenschaftswert „JB-Berechtigung-Verwaltung“ auf „schreiben“ und ist der Benutzer Mitglied in der Gruppe LD-DAC-Verwaltung dann hat er das Schreibrecht.

Die gleiche Regel gibt es für das Leserecht und das Listrecht.

Das soll dazu aber mal genügen. Weiter geht es mit den Freigaben. Jedes Hauptverzeichnis erhält eine korrespondierende Freigabe, die dem Benutzer nicht direkt angezeigt werden soll. Das erledigt die PowerShell:

Nun aktiviere ich noch die SMB-Encryption. Diese ist seit Version 3 des Protokolls mit dabei und verhält sich ähnlich wie der Unterschied von HTTP zu HTTPS. Der Datenstrom ist auf Netzwerkebene verschlüsselt. Alle meine Clients und Server unterstützen diesen Standard. Daher aktiviere ich die Verschlüsselung auf Serverebene:

Jetzt kann die DFS-Replikation eingerichtet werden. Dazu verwende ich wieder die Management-Konsole auf einem meiner Fileserver. Bei 3 Freigaben wäre der Weg über die PowerShell zu aufwändig. Für die erste Freigabe konfiguriere ich die neue Freigabe als Ziel:

Normalerweise folgt direkt nach diesem Assistenten der Einrichtungsassistent für die DFS-Replikation. Hier kam aber nichts… Egal, dann richte ich die Replikation eben selber ein:

Dazu ist der Zielserver anzugeben:

Dazu muss definiert sein, von welchen anderen Servern der neue die Daten erhalten soll:

Mit einem sehr gut gemachten Dialog für den Replikationszeitplan kann genau die Zeit und die Bandbreite für die Übertragung definiert werden. Das ist besonders für langsame Standortverbindungen geeignet:

Natürlich muss auch der Ordner auf dem Zielserver angegeben werden:

Und dann kann es auch schon losgehen:

Eigentlich ist es nicht sinnvoll, wenn die beiden Server WS-FS1 und WS-FS2 aus dem anderen Standort ihre Daten zum neuen WS-FS3 senden. WS-RDS3 im gleichen Standort hat doch alle Daten. Damit spare ich Bandbreite im VPN und vor allem Zeit. Also lösche ich die nicht so optimalen Verbindungen:

Und dann geht es zum 2. Verzeichnis:

Interessant: hier kommt der Anschlussdialog, der mir beim ersten Verzeichnis fehlte:

Und nun noch der 3. Ordner:

Auch hier kommt der erwartete Einrichtungsassistent im Anschluss:

Damit die Replikation jetzt beginnt, überschreibe ich den Replikationszeitplan:

Die Veränderungen benötigen einige Zeit, da ja die Einstellungen im AC gespeichert sind und erst zwischen den Domain Controllern repliziert werden müssen. Und auch die DFS-R-Dienste auf den Fileservern lesen Veränderungen aus dem AD nicht in Echtzeit. Aber nach einigen Minuten beginnt die Übertragung. Ich hab ja auch mit einem Service-Neustart nachgeholfen:

Einige Minuten später prüfe ich mit meinem Monitoring, ob die Verzeichnisse repliziert wurden:

Auch mit einem robocopy-Befehl und er Option /L kann geprüft werden.

Nun wird der alte Pfad zum WS-RDS3 nicht mehr benötigt. Ich lösche also die Verknüpfung:

Nach meinen konfigurierten 120 Sekunden wissen alle Clients nichts mehr vom alten Server. Und wenn dann auch alle Dateien auf dem alten Server geschlossen sind, dann kann der Rückbau beginnen. Zuerst entferne ich die Freigaben:

Einige bleiben noch über. Die kommen später dran:

Jetzt kann ich die Verzeichnisse auf dem alten Server löschen und so den knappen Speicherplatz wieder etwas entlasten:

Der Server WS-RDS3 ist jetzt kein Fileserver mehr. Und auch die Rollen DFS-Namespace und DFS-Replication sind lastfrei.

Ich habe bei meiner Administration etwas übersehen: Beim Löschen der nicht mehr benötigten DFS-Namespace-Weiterleitung auf WS-RDS3 wird NICHT die DFS-Replikationseinstellung entfernt. Ordner können ja auch ohne DFS-N repliziert werden. Soweit war das noch kein Problem. Aber mit dem Löschen der Ordner auf dem alten WS-RDS3 (im oberen Bild gut sichtbar) ging der dort noch laufende DFS-Replikationsdienst davon aus, dass die Dateien nicht mehr benötigt werden. Und diese Info gab er an alle anderen Server weiter! So war nach wenigen Augenblicken auf allen 4 Fileservern nicht eine Datei mehr über!

Man sollte neben der Administration keine anderen Tätigkeiten ausführen.

Egal, es ist passiert und nun muss eine Wiederherstellung ausgeführt werden. Diese habe ich wegen der Dringlichkeit nicht mehr Live mitprotokolliert. Die nächsten Bilder entstanden also einige Tage danach.

Ich habe eine mehrstufige Datensicherung in meinem Fileservice:

• Meine Daten liegen üblicherweise auf mindestens 2 Fileservern und werden mit einer überwachten DFS-Replikation synchron gehalten. Fällt ein Server aus, dann habe ich die Daten auf einem anderen direkt verfügbar. Dieses Szenario greift in meinem aktuellen Fall aber nicht, da die Daten wegsynchronisiert wurden.
• Dann existiert die Datensicherung mit dem Data Protection Manager. Dieser sichert die Dateien mehrmals am Tag. Die Wiederherstellung ist etwas langsam, würde aber jetzt helfen.
• Und zusätzlich habe ich noch auf einem Server Schattenkopien eingerichtet. Diese verstärken das Sicherungsintervall des DPM (der DPM und die Schattenkopien laufen im Wechsel und damit wird doppelt so oft gesichert). Die Wiederherstellung ist sehr einfach über den Windows Explorer vorzunehmen.

Um möglichst wenig Datenverlust zu erleiden muss ich mich zwischen der DPM-Recovery und der Schattenkopien-Recovery entscheiden. Zuletzt wurde die Schattenkopie gesichert. Fein, denn hier geht es einfach schneller.

Aber vor der Wiederherstellung bereinige ich noch die DFS-Replikationskonfiguration. Nicht, dass es noch einmal passiert. Also entferne ich überall den alten WS-RDS3:

Anschließend gebe ich meinen Domain Controllern ein paar Minuten Zeit für die Replikation und starte auf allen 4 Servern (auf auf dem alten WS-RDS3) den DFS-Replikationsdienst neu. Im Eventlog des WS-RDS3 finde ich den Eintrag, dass der Server die Replikation als entfernt ansieht. Dazu habe ich leider kein Bild mehr erstellen können. Das Logfile befindet sich hier:

Auf dem Fileserver WS-FS1 starte ich als Administrator die Wiederherstellung. Ich öffne einen Windows Explorer, navigiere zu dem Verzeichnis Jungbrunnen und wähle mit einem Rechtsklich die Option „Vorgängerversion wiederherstellen“ im Kontextmenü aus:

Dann geht es weiter mit der Auswahl des richtigen Zeitpunktes. Und dann öffne ich den Snapshot. Wiederherstelle wäre als Option ebenfalls denkbar. Aber mit dem Öffnen kann ich selber die Ordner auswählen, die kopiert werden sollen:

Im letzten Schritt kopiere ich die Ordner per Drag&Drop in das leere Verzeichnis. Dabei nehme ich die wichtigen Ordner natürlich zuerst dran:

Jetzt werden die Ordner lokal auf WS-FS1 wiederhergestellt. Zwischen Server WS-FS1 und WS-FS2 besteht eine direkte Replikationsverbindung mit DFS-R. Die Daten werden mit 2 Gbit auf den zweiten Server kopiert. Hier angekommen werden sie vom DFS-R-Dienst über die VPN-Leitung zum WS-FS3 kopiert, denn zwischen WS-FS2 und WS-FS3 existiert ebenfalls eine Replikation. Dieser Teil dauert natürlich etwas länger.

Einige Zeit später kontrolliere ich das Ergebnis. Die Replikation kam zum erliegen. Die Ursache war aber schnell im Ereignisprotokoll gefunden:

DFS-Replica speichert die zu übertragenen Dateien in einem Staging-Verzeichnis zwischen. Für dieses Verzeichnis gilt eine Standardlimitierung von 4GB. Diese scheine ich erreicht zu haben. Der Wert lässt sich aber einfach anpassen:

Auch diese Veränderung benötigt einen Augenblick für die Replikation im AD. Danach geht die Datenreplikation weiter.

Naja, das hätte es nicht gebraucht. Damit euch das nicht passiert, hab ich mein Missgeschick mal mit aufgenommen. Denn auch solche Events gehören protokolliert. Fehler passieren. Ich steh dazu. Und vielleicht kommt ihr so um den Fehler herum.

Ein Hinweis: diesen Absatz habe ich nachträglich mehrere Tage später eingefügt. Im folgenden Text geht es also zu einer anderen Zeit weiter.

Diese Anwendung ist eine Access-Datenbank, die in einem Netzlaufwerk auf WS-RDS3 lag und von einem Client aus aufgerufen wird.

Die Migration ist denkbar einfach: ich erstelle ein neues Verzeichnis auf dem neuen Fileserver WS-FS3, definiere die ACL und gebe es frei. Anschließend verschiebe ich die Anwendung in die Freigabe und passe die Konfiguration in der Datenbank an den neuen Pfad an.

Auf dem Client muss ich nur die Verknüpfung zur Datei aktualisieren.

Zwischenzeitlich hat sich der neue Server im WSUS gemeldet. Die Konfiguration stammt aus einer GPO. Im WSUS unterscheide ich 2 Zeitpläne für die Installation von Updates. Der Server WS-FS3 ist in der verzögerten Gruppe dran:

Mein PRTG-Monitor soll die neue VM ebenfalls im Blick behalten. Dazu erweitere ich die Sensoren vom Server WS-RDS3 um eine VM:

Es werden alle verfügbaren VMs gelistet:

Eine Minute später beginnt die Überwachung:

Der neue Server soll natürlich auch gesichert werden. Es war doch einiges an Arbeit bis hierher. Bei einem schlechten Update oder einem administrativen Missgeschick soll die Wiederherstellung schnell gehen. Daher nehme ich den Server in meine Bare-Metal-Recovery-Sicherung (BMR) auf. Dabei sichere ich das Betriebssystem (nicht die Nutzdaten) mit der Windows Server Sicherung über eine eigene Scriptlösung mit einer Rotation in ein Netzlaufwerk. Die Sicherung wird zeitgesteuert über eine geplante Aufgabe ausgeführt. Diese habe ich bereits als xml-Datei exportiert. Diese lässt sich einfach in den neuen Server importieren:

Der ausführende Account ist ein Group Managed Service Account (gMSA). Dieser wird vom Domain Controller aus eingerichtet. Da nur die PowerShell für dessen Administration zur Verfügung steht, habe ich mir eine kleine PowerShell-GUI als Werkzeug erstellt. Zuerst erlaube ich dem neuen Server, dass er das Passwort des Accounts synchronisieren darf:

Dann wähle ich die Taskliste aus. Diese Funktion stellt eine Remoteverbindung zum neuen Server her und listet mir alle bereits vorhandenen Aufgaben. Mit einem Klick auf „setze gMSA ein“ wird der Task remote rekonfiguriert:

Die Aufgabe startet ein Script in einem Netzlaufwerk. Dieses wiederum läd meine Einstellungen aus einer simplen ini-Textdatei. Darin sucht der Scriptprozess nach einer Zeile mit dem Namen des Servers, der die Aufgabe gestartet hat. Und in dieser Zeile steht drin, wann der Server was wohin zu sichern hat. Diese ini-Datei muss ich natürlich auch erweitern:

Alle Server starten den Task zur gleichen Zeit. Mit dem Delay kann ich eine Pause in Minuten angeben, damit nicht alle gleichzeitig sichern. 3@135 bedeutet, dass der Server an den Tagen Montag (1), Mittwoch (3) und Freitag (5) sichern soll und insgesamt 3 Sicherungen aufbewahrt werden sollen. Die 4. Sicherung überschreibt also die erste. Und die 2 am Ende ist eine Variable für das Sicherungsziel. Dieses ist im Kopf der Datei definiert:

Eine sehr simple Form. Aber mit diesem Script sichere ich bereits seit Windows Server 2008, habe eine zentrale Konfigurationsmöglichkeit und ein zentrales Monitoring per Mail:

Die scriptgesteuerte Sicherung erfasst nur das Betriebssystem des neuen Fileservers. Die eigentlichen Nutzdaten – also die Freigaben – sichert mein Microsoft System Center Data Protection Manager 2019. Für diesen ist ein lokaler Agent erforderlich. Die Dateien für das Setup habe ich lesend am DPM-Server freigegeben. Ich kopiere das Setup auf dem Server Core über den von mir integrierten Windows Explorer auf den lokalen Datenträger. So kann ein Wackler im VPN keinen Schaden bei der Installation verursachen:

Anschließend starte ich das Setup:

Der Prozess dauert nur wenige Sekunden und endet mit einer Erfolgsmeldung:

Zusätzlich muss der Agent noch mit seinem Server getaggt werden. Dafür habe ich ein kleines Script:

Der Agent ist nun einsatzbereit. Ich kann ihn im DPM verbinden. In dessen Konsole sehe ich noch die alte Sicherung des Servers WS-RDS3. Diese kann natürlich nicht mehr fortgesetzt werden:

Den alten Agent entferne ich später:

Zuerst verbinde ich den neuen vom WS-FS3:

Den Server kann ich einfach suchen:

Der Account benötigt nur kurz die administrativen Rechte:

Und dann wird der Agent aktiv:

Im nächsten Schritt kann ich die alte Schutzgruppe modifizieren. Darin ist der Sicherungsjob beschrieben:

Ich nehme die erforderlichen Verzeichnisse des neuen Servers in die Liste auf und entferne gleichzeitig die alten Sicherungen des WS-RDS3:

Den Rest kann ich einfach durchbestätigen, da hier keine Anpassungen erforderlich sind:

Die Sicherung des neuen Servers startet. Währenddessen entferne ich die Reste der alten Sicherung:

Danach ist der alte Agent nicht mehr gebunden und kann entfernt werden. Das geht wieder nur mit der PowerShell:

Nach einigen Minuten ist die Sicherung abgeschlossen:

Bisher konnten meine Exchange Server auf dem alten WS-RDS3 eine Freigabe als DAG-Witness verwenden. Diese Funktion stellt das Quorum in meinem Datenbankverfügbarkeits-Cluster dar. Die Freigabe ziehe ich jetzt auf den neuen Fileserver um. Das erledige ich aus einer PowerShell heraus. Aktuell zeigt der Witness auf den alten Server:

Die Exchange Server kümmern sich um die Freigabe. Dafür benötigen sie aber administrative Rechte auf dem Fileserver. Das erledige ich fix remote:

Und jetzt überschreibe ich die Clusterkonfiguration im Exchange Server:

Der Ordner mit der Freigabe wird erstellt:

Und im Clustermanager des Exchange Servers kann ich die Bestätigung einholen:

Die alte Freigabe auf dem WS-RDS3 lasse ich bestehen. Die fliegt mit der Neuinstallation raus. Damit sind die Dateidienste komplett aus dem alten Hyper-V-Server herausgelöst.

Diesen Teil habe ich in einen separaten Beitrag verschoben. Davor musste ich aber noch meine beiden neuen Hyper-V-Hosts umbenennen.

Den Artikel gibt es wie üblich hier zum herunterladen.

Stay tuned!