Ich betreibe aktuell 2 Windows Server 2012R2, auf denen meine FileServices gehostet sind. Im Rahmen der Migration auf Windows Server 2019 sind nun diese Systeme an der Reihe. Nach dem Austausch sind keine weiteren Windows Server mit der „alten“ Version 2012 R2 in Betrieb. Damit lassen sich also auch Gruppenrichtlinien und andere Mechanismen leichter homogen gestalten.

Ich verwende mehrere Dateiserver (WS-FS1 und WS-FS2), um den FileService redundant anzubieten: Der Verlust eines Fileservers darf keine oder nur eine minimale Downtime beim Dateizugriff nach sich ziehen. Und so habe ich dieses Ziel realisiert:

• Jeder der beiden Server läuft als virtuelle Maschine auf einem eigenen Hyper-V-Host. Der Ausfall einer physikalischen Maschine und/oder eines Fileservers wird den Service „Dateifreigaben“ nicht beeinträchtigen.
• Beide Fileserver haben eine virtuelle Festplatte, auf der alle relevanten Freigaben abgelegt sind.
• Der Zugriff auf die Freigaben wird über einen AD-integrierten DFS-Namespace gesteuert. Dabei wurde für jede relevante Freigabe jeweils ein Ziel auf WS-FS1 und ein Ziel auf WS-FS2 definiert. Durch eine Vorgabe der Reihenfolge arbeiten alle Clients immer je Freigabe auf dem gleichen Server. So können Konflikte vermieden werden. Fällt dieser Server aus, dann wechseln alle Clients auf den anderen Fileserver.
• Änderungen am Datenbestand werden im Hintergrund über DFS-Replica vom aktiven Fileserver auf den passiven synchronisiert.

Weitere wichtige Informationen:

• Auf einem der beiden Fileserver ist noch ein Druckservice installiert. Dieser muss mit übertragen werden.
• Der Datenbestand wird mit einem Microsoft Data Protection Manager 2019 gesichert. Der Agent läuft dabei nur auf einem Fileserver.
• Das Monitoring des DFS-Replica (also der Dateisynchronisierung) wird über ein PowerShell-Script ausgeführt und täglich kontrolliert.

Hier sieht man den Aufbau schematisch:

Das sind meine Anforderungen für die Migration und die Zielsysteme danach:

• Beide Betriebssysteme sollen durch Windows Server 2019 ersetzt werden.
• Die Namen und die IPv4-Adressen der beiden Server sollen beibehalten werden, damit keine weiteren Anpassungen (in Scripten, in der Firewall-Konfiguration oder im Backup) notwendig werden.
• Ein Inplace-Upgrade wird ausgeschlossen. Die Wahrscheinlichkeit von Problemen ist einfach zu hoch. Zudem ist eine echte Migration doch einfach etwas professioneller.
• Das Migrationsszenario soll möglichst wenig zusätzlichen Speicherplatz auf den Hyper-V-Hosts belegen.
• Das Backup soll weiterlaufen. Es soll keine neue Vollsicherung erforderlich werden. Zusätzlich sollen Schattenkopien auf einem Fileserver implementiert werden.
• Die Migration soll möglichst ohne Downtime auskommen und damit währen der üblichen Bürozeiten ausgeführt werden.

Wie können die gesetzten Ziele erreicht werden? Eine Downtime kann dank der Datenredundanz mit DFS-R und DFS-N abgebildet werden. Ebenso sollte mit dem Beibehalten der Namen und IP-Konfigurationen auch die bestehende Datensicherung fortgeführt werden können.

Somit bleibt nur die Frage: Wie können die bestehenden Festplatten und Konfigurationen von einem alten Server auf einen neuen übertragen werden?

Storage Migration Service

Microsoft würde hier das Windows Admin Center mit dem Storage Migration Service als Lösung anbieten. Die Idee dafür ist ja auch nicht schlecht. Über einen Assistenten werden insgesamt 3 Phasen durchgeführt:

Die erste Phase analysiert den alten Fileserver und ermittelt bestehende Freigaben und Informationen der dazugehörigen Volumes. In der zweiten Phase werden dann alle Daten auf den schon existierenden, neuen Server kopiert. Im letzten Schritt wird der alte Server um seinen Namen und seine IP-Adresse erleichtert. Diese werden auf dem neuen Server konfiguriert. Und fertig ist der Austausch.

Doch halt: Das Szenario hat einige Schwächen! Zum einen werden die Daten kopiert! Daher muss zumindest temporär der doppelte Speicherplatz verfügbar sein. Viel dramatischer ist aber der Umstand, dass die Daten nur einmal von A bis Z kopiert werden! Ändern sich während der Kopieraktion noch Daten auf dem alten Server, dann werden diese nicht final synchronisiert! Man kann natürlich den Transfer neu starten, aber dann muss man diese Meldung bestätigen:

Wer gibt denn bitte so etwas als „Solution“ frei??

Abgesehen davon: ich habe keine Informationen zum Transfer der DFS-Namespace oder DFS-Replica-Konfiguration im Zusammenhang mit dem Storage Migration Service gefunden. Und diese möchte ich doch auch umziehen. Es scheint sich hierbei also um eine „Lösung“ für kleine Fileserver zu handeln.

Das ist also keine Lösung für mich!

Umhängen der Festplatten

Vielleicht kann zu einer Zeit einer der Fileserver offline genommen werden (Dank DFS-R gibt es ja keine Downtime). Dann könnte die virtuelle Festplatte mit den Freigaben in den neuen Server eingehängt werden. Ein paar Klicks später hat dieser Server den Namen und die IP-Adresse des alten Servers und die gleichen Freigaben sind auch konfiguriert. Das wäre sehr einfach und platzsparend.

Aber wie wird die Konfiguration im DFS migriert? Auch das ist einfach, wenn man sich mal den Datenspeicher der Konfiguration anschaut. Ein DFS-Namespace-Server hat einen aktiven Service. Dieser synchronisiert seine Einstellungen über das Active Directory (wenn wie in meinem Fall der Namespace AD-integriert wurde). Somit kann ein neuer Fileserver mit dem gleichen Namen und einer installierten DFS-N-Rolle diese Konfiguration einfach übernehmen. Dann fehlen nur noch die lokalen Freigaben für den Namespace. Alternativ kann ein Namespace-Server auch entfernt und neu integriert werden. Dann baut der neue Server alles wieder auf. Dabei werden aber mindestens 2 aktive Namespace-Server benötigt (Das Entfernen des letzten/einzigen Namespace-Servers entfernt auch den Namespace selber)

Fein. Und wie migriert man die DFS-Replikation? Na genauso einfach! Der Server hat durch die Rolleninstallation nur einen aktiven Service laufen. Dessen Konfiguration findet er zentral im Active Directory:

Damit kann ein neu installierter Server mit der gleichen Identität einfach da weitermachen, wo der alte Server aufgehört hat. Welche Daten bereits abgeglichen wurden und welche noch ausstehen? Diese Informationen liegen direkt in den Partitionen mit den Freigaben, die abgeglichen werden. Hängt man also die Platte des alten Servers um, dann ziehen diese Informationen also mit um:

Mit diesem Szenario kann ich also alle gestellten Anforderungen erfüllen. Los geht’s!

Um die Downtime möglichst kurz zu halten installiere ich zuerst einen neuen Windows Server 2019 in einer neuen VM:

Das Betriebssystem habe ich bereits in einer Base-VHDX installiert und mit Sysprep vorbereitet. Diese Base-File kopiere ich für den neuen Server:

Nach dem Start kommt das übliche Einrichtungs-Procedere mit der Out-Of-Box-Experience (OOBE). Die erforderlichen Eingaben sind bekannt und daher überspringe ich die Dialoge:

Jetzt ist der beste Zeitpunkt für Windows Updates gekommen. Dafür muss ich in meiner Infrastruktur den Server in ein anderes Netzwerk-Segment hängen. Im Servernetz kommt er nicht ins Internet:

So ist auch die Aktivierung kein Problem mehr:

Und auch die Updates werden gefunden und installiert:

Nach dem Neustart ist das System UpToDate:

Bisher gab es natürlich keine Beeinträchtigung meiner laufenden Dienste.

Auslesen der Freigaben

Bei jeder Migration sollte unmittelbar vor der Deaktivierung des Altsystems eine finale Analyse durchgeführt werden. Für eine Planung ist das natürlich auch im Vorfeld empfehlenswert.

Zuerst verschaffe ich mir einen Überblick über die existierenden Freigaben. Da ich diese 1:1 auf dem neuen Server benötige exportiere ich die Informationen in eine CSV-Datei. Einzelne Shares (z.B. administrative) überspringe ich dabei:

Sammeln von Informationen

Im Laufe der Zeit haben sich vielleicht auch einige lokale Dateien angesammelt. Diese bewahre ich meist in dem Ordner C:\Admin auf. Somit kann ich sie leicht finden:

Weiter sind aktuell installierte Rollen und Features interessant. Wir wollen doch keine Funktionen vergessen:

Sehr gerne setze ich geplante Aufgaben für Automationen ein. Ein Blick in die Konfiguration zeigt aber, das hier nichts mit einer Relevanz vorhanden ist:

Die Rollen- und Features haben die Präsenz der SubRolle Deduplication gezeigt. Welche Volumes wurden optimiert?

Und auch die Rolle File-Server-Resource-Manager wurde installiert. Gibt es hier was für die Migration? Nein, alles ist leer:

Zudem könnten Anwendungen installiert sein, die vorab übertragen werden müssen. Ideal ist hier natürlich der Single-Purpose-Ansatz: Ein Server mit einer Funktion! Tatsächlich ist eine Anwendung installiert (Serviio). Diese wird aber nicht mehr benötigt:

Die aktuelle Datensicherung ist in ein Problem gelaufen. Die Ursache liegt aber im DPM 2019 und wird laut Microsoft erst im Q1 2020 gefixt. (grrr):

Mehr ist nicht vorhanden. Es kann weiter gehen.

Im Monitoring (PRTG) pausiere ich die Überwachung der VM WS-FS2:

Danach kann ich den alten Fileserver einfach herunterfahren. Der automatische Start der VM sollte deaktiviert werden, damit nachher nicht versehentlich 2 Server online gehen:

Dank des DFS-Namespaces greifen nun alle Server und Clients auf den verbliebenen Fileserver WS-FS1 zu. Achtung: geöffnete Dateien werden nicht mit DFS-Replica synchronisiert. In Umgebungen mit vielen Zugriffen sollte die Abschaltung des alten Servers daher sauber koordiniert werden. Dazu könnte z.B. die Reihenfolge der DFS-Ziele auf den verbleibenden Fileserver rekonfiguriert werden. Damit werden neue Verbindungen nur dort geöffnet. Und dann sollten alle noch geöffneten Dateien des alten Servers geschlossen und repliziert werden.

Bei mir ist das einfach, da es weniger Zugriffe gibt.

Nun kann ich die IP-Konfiguration im neuen Server eintragen:

Ein paar Klicks später hängt der Server auch wieder im Servernetzwerk:

Nun benenne ich den neuen Server um. Dabei nehme ich ihn noch nicht in die Domäne auf:

Als Nächstes bereite ich das alte Computerkonto für die Übernahme vor (das ist erforderlich, damit die DFS-R/N-Konfiguration im Active Directory vom neuen Server übernommen wird). Also melde ich mich fix am Domain Controller an. Interessant: die Laufwerksanbindung dauert länger als gewöhnlich, da etliche Shares auf den ausgeschalteten Server zeigen. Erst nach einem Timeout wird der verbliebene Server verwendet:

Aber dann ist der Zugriff möglich:

Auf dem Domain Controller setze ich das Konto des WS-FS2 zurück und deaktiviere es:

Beim Domain Join „übernimmt“ nun der neue WS-FS2 dieses Konto:

Jetzt können die VHDX-Dateien im Hyper-V an die neue VM angebunden werden. Zuvor verschiebe ich aber noch den Speicherplatz in das richtige Verzeichnis:

Hier sind die Daten-Festplatten:

Und so können sie der neuen VM zugewiesen werden. Achtung: der alte Server darf jetzt nicht gleichzeitig aktiv sein! Sonst gibt es ggf. Zugriffsprobleme. Ihr könnt auf Nummer sicher gehen und der alten VM die VHDX entziehen. Das hab ich bei mir nicht gemacht:

Ein simpler Rename später ist der „neue“ WS-FS2 als VM einsatzbereit:

Ich hab mir noch eine andere Form der Bezeichnung überlegt und ändere daher die Konfiguration so ab:

Im laufenden Server WS-FS2 nehme ich nun die neuen Datenträger online:

Die Volumes werden erkannt. Nur die Laufwerksbuchstaben passen nicht. Aber das lässt sich mit einigen wenigen Klicks bereinigen:

Nun können die lokalen Freigaben aus der CSV-Datei des alten Server wieder erstellt werden. Das geht sehr einfach mit der PowerShell:

Ab jetzt wäre ein Zugriff wieder möglich. Es fehlen aber noch einige Kleinigkeiten…

… z.B. die zusätzlichen Rollen und Features:

Wenn meine Migrations-Strategie aufgeht, dann sollte jetzt die DFS-Replikation wieder arbeiten. Ein Blick in die Eventlogs des neuen Servers zeigt zwar einige Fehler, aber danach ist alles OK:

Interessant: genau dieses Word-Dokument hat einen Konflikt verursacht! Klar. Es war ja die gesamte Zeit für meine ScreenShots geöffnet. Das ist aber kein Problem. Ich speichere es einfach erneut ab.

Der Test der Replikation ist denkbar einfach: Ich erstelle auf WS-FS1 eine Datei und prüfe, ob diese auf dem Server WS-FS2 synchronisiert wird. Und umgekehrt:

Das war ein voller Erfolg: Die gesamte Konfiguration wurde ohne erneute Synchronisierung übernommen!

Und wie schaut es mit der Übernahme im Bereich des Namespaces aus? Die Management-Konsole sieht normal aus. Ich erstelle testweise einen neuen Ordner:

Auf dem alten Server wird dieser auch sofort angelegt:

Aber auf dem neuen Server kommt leider nichts an:

Na gut. Dann entferne ich den Server aus dem Namespace und nehme ihn neu auf. Damit sollte die Konfiguration repariert werden:

Der Fehler scheint sich aber weiter auszuwirken:

Egal. Der Server ist aus der Konfiguration entfernt. Nun nehme ich ihn neu auf:

Doch der Versuch schlägt fehl. Dies kündigte sich bereits bei dem Schalter „Durchsuchen“ im vorherigen Dialog an. Dort wurde das Laufwerk E: nicht gefunden…

Der Assistent vermisst die administrative Freigabe E$. Diese wird doch automatisch erstellt?? Eine Kontrolle mit der PowerShell zeigt, dass sie tatsächlich fehlt:

Aber die Ursache ist einfach: ich habe die virtuelle Festplatte mit dem Laufwerk E: im laufenden Betrieb eingebunden und die Laufwerksbuchstaben manuell angepasst. Da kam das System wohl nicht mehr mit. Und ohne die administrative Freigabe funktioniert die Konfiguration des DFS-Namespace-Servers nicht. Nach einem Neustart sollte das Problem behoben sein:

Und mit der administrativen Freigabe läuft auch der DFSN-Assistent erfolgreich durch:

Gut. Beim anderen FileServer werde ich die Reihenfolge der Anpassung abändern.

Der neue Fileserver soll wie der vorherige als Backup-Quelle für meinen DPM-Server dienen. Der DPM benötigt dafür einen lokal installierten Agent. Dieser kann einfach installiert werden:

Noch eine kleine Konfiguration für den Agent, dann weiß er, welcher DPM-Server zuständig ist:

Die Identität, der Name und die IP-Konfiguration des Servers ist die gleiche wie die des alten Servers. Merkt der DPM dennoch den Unterschied? In seiner Konsole wird die Agent-Konnektivität erfolgreich bestätigt:

Das Laufwerk X: habe ich nicht mehr übernommen. Damit wird hier eine Fehlermeldung angezeigt. Ich entferne die nicht mehr erforderliche Sicherungskonfiguration:

Nun benötigt das Betriebssystem des neuen Servers eine Sicherungskonfiguration. Meine Systeme sichere ich mit Windows Boardmitteln – der Windows Server Sicherung. Diese muss als Feature installiert sein:

Die Sicherung wird über eine geplante Aufgabe gestartet. Diese habe ich auf einem anderen Server als XML-Datei exportiert. So kann ich die erforderlichen Einstellungen schnell auf dem neuen Server übernehmen:

Der angegebene Benutzer ist aber nur ein Dummy-Account. Die Sicherung wird von einem Group Managed Service Account (gMSA) durchgeführt – dies ist ein benutzerähnliches Objekt, dessen Anmeldepasswort von den DomainControllern vergeben wird. Die Administratoren kennen es nicht. Daher kann es auch nicht über die (alte) Aufgabenplanung eingegeben werden. Daher nehme ich zum Speichern einen Dummy.

Den gMSA definiere ich mit einem PowerShell-Script auf meinem DomainController:

Den Sicherungserfolg prüfe ich morgen.

Der Server läuft. Also kann auch die Wartung im Monitoring beendet werden:

Damit ist diese Migration erfolgreich abgeschlossen. Weiter geht’s mit dem anderen FileServer!

Für den Austausch des zweiten, alten Fileservers bereite ich wie beim vorherigen zunächst eine neue VM im Hyper-V vor. Das Betriebssystem klone ich aus einer bestehenden BaseFile:

Um diese BaseFile baue ich nun die neue VM:

Der Start wird wieder die Out-Of-Box-Experience abschließen. Nach der Eingabe des lokalen Administrator-Passwortes ist der Server online:

Diesen Server habe ich gleich im Client-Netzwerk platziert. Damit erhält er via DHCP eine IPv4-Konfiguration und kann das Internet erreichen. So gelingt auch die Aktivierung:

Ebenso werden nun alle erforderlichen Updates heruntergeladen und installiert:

Nach dem Neustart ist das System bereit für den Austausch:

Auslesen der Freigaben

Bevor der alte Server abgeschaltet wird, lese ich wieder die Freigaben in eine CSV-Datei aus:

Sammeln von Informationen

Und natürlich sammle ich alle Informationen, die für die Rekonfiguration des neuen Servers erforderlich sind. Zum Beispiel die aktuell installierten Rollen und Features:

Ebenso kontrolliere ich die installierten Anwendungen. Hier ist ein Druckersystem installiert. Dieses wird gesondert übertragen:

In der Aufgabenliste gibt es keine interessanten Jobs:

Die aktuellen Volumes sind teilweise dedupliziert:

Auch auf diesem Server ist ein FileServer-RessourceManager installiert. Dieser hat aber im Vergleich zum ersten Fileserver eine Konfiguration: er erstellt jede Woche einige Speicherberichte:

Im Monitoring pausiere ich die Überwachung des Servers WS-FS1:

Doch noch kann ich den alten Server nicht deaktivieren. Die Rolle DruckService muss ebenfalls migriert werden. Dafür steht in der Management-Konsole ein Migrations-Szenario zur Verfügung. Aktuell ist nur ein Drucksystem freigegeben:

Dessen Konfiguration exportiere ich in eine Datei. Diese kann auf dem neuen Server importiert werden. Bleibt der Name und die IP-Adresse gleich, dann können die Benutzer einfach weiter drucken:

Nun kopiere ich die gesammelten Dateien auf ein zentrales Laufwerk. An dieser Stelle könnte eine DFS-Maintenance für den Server eingeleitet werden. Ist diese aktiv, dann wird der Server nicht mehr als Fileserver verwendet. Danach kann der alte Server ausgeschaltet werden. Das Dateisystem wird dann über den Partnerserver WS-FS2 bereitgestellt. Nur das Drucken ist nicht redundant. Aber das war keine Anforderung von mir.

Ich beginne wieder mit einigen Vorarbeiten im Hyper-V. Der alte Server ist nun abgeschaltet und wird umbenannt:

Dem neuen Server verpasse ich den alten Namen und die alte IP-Konfiguration:

Statt dem Neustart fahre ich den Server herunter. Nun ändere ich noch die Netzwerkschnittstelle. Der Server befindet sich sonst immer noch im Client-Netzwerk:

Im Active Directory bereite ich das Computerkonto für die Übernahme vor:

Nach dem Einschalten trete ich nun der Domäne bei:

Jetzt bekommt der Server die alten Festplatten zugewiesen. Dabei nutze ich die Gelegenheit, die Dateien neu zu benennen:

Im ServerManager schalte ich die Disks online:

Die Laufwerksbuchstaben werden nicht korrekt vergeben. Das korrigiere ich:

Dieses Mal sind alle administrativen Freigaben vorhanden:

Die restlichen Freigaben erstelle ich wieder mit der CSV-Datei und einem PowerShell-Script. Bei einem Share gibt es ein Problem. Diese Disk habe ich aber nicht mehr mit eingebunden. Der Inhalt ist jetzt auf der größeren Disk besser aufgehoben:

Nun fehlen noch die Rollen und Features:

Wie bei dem anderen Server lädt der neue Server WS-FS1 die DFS-Replica-Konfiguration dank des gleichen Namens automatisch. Ich teste die Replikation, indem ich auf beiden Servern eine Testdatei erstelle. Die Datei wird brav repliziert:

Und auch das Eventlog bestätigt die Funktion:

Beim Namespace-Server kenne ich ja nun den Weg. Zuerst entferne ich den Server aus beiden Namespaces:

Die Meldung über die fehlenden Freigaben ignoriere ich:

Danach nehme ich den Server wieder als Namespace-Server auf. Da die administrativen Freigaben vorhanden sind, läuft der Prozess fehlerfrei durch:

Mit diesem Schritt ist die Migration der FileServices erfolgreich abgeschlossen.

Auf diesem Server sichere ich nur das Betriebssystem. Die Nutzdaten sind durch DFS-Replica synchron mit denen auf WS-FS2. Und dieser Server hat eine aktive Datensicherung über einen Microsoft Data Protection Manager. Da ich auch DFS-R überwache, sollte es hier keine Lücken geben.

Die Datensicherung des Betriebssystems führe ich wieder mit meiner Scriptlösung aus. Diese ruft Windows Backup auf. Die erforderliche Aufgabe importiere ich über eine XML-Datei:

Der Account Admin-Setup ist dabei nur ein Platzhalter. Den tatsächlichen Account – ein gMSA – konfiguriere ich vom Domain Controller aus mit meinem PowerShell-Script:

Meine DPM-Sicherung synchronisiert 2x am Tag: um 12:00 und um 20:00. Somit kann ich 2 Wiederherstellungspunkte je Tag auswählen. Noch mehr Wiederherstellungspunkte kann ich nicht konfigurieren, da NTFS nur max. 64 unterstützt und ich im DPM aber gerne 30 Tage zurück gehen möchte (30 * 2 <= 64). Daher möchte ich auf dem neuen WS-FS1 zusätzlich noch Schattenkopien konfigurieren. Diese sollen als kurzfristige Wiederherstellungspunkte dienen.

Diese Daten möchte ich auf einer eigenen Festplatte speichern, damit ich sie aus Sicherungen explizit ausschließen kann. Also bekommt die VM eine neue VHDX:

Im laufenden Betrieb nehme ich den Datenträger online und erstelle ein Volume ohne Laufwerksbuchstaben:

Jetzt konfiguriere ich die Schattenkopien:

In den Optionen wähle ich den neuen Datenträger aus. Ohne Angabe des Laufwerksbuchstabens ist das etwas knifflig. Ich achte dabei einfach auf die Größe des Volumes:

Und nun konfiguriere ich noch die Zeitpläne. Gesichert wird 06:00, 09:00 und 15:00. Zusammen mit der DPM-Sicherung (12:00 und 20:00) habe ich dann je Tag 5 Wiederherstellungspunkte:

Die erste Schattenkopie erstelle ich von Hand. So kann ich die Funktionalität testen:

Wichtig ist aber, dass die Wiederherstellung nur im Netzwerk möglich ist, wenn der DFS-Namespace-Server auch auf diesen Fileserver verweist. Greife ich beispielsweise auf meine Freigabe \\ws.its\freigaben\business zu, dann lenkt mich DFSN auf WS-FS2 (wenn dieser Server online ist). So könnte ich nicht auf die Vorgängerversionen zugreifen. Daher merke ich mir, dass die Schattenkopien lokal auf dem Server WS-FS1 geöffnet werden können:

Nun muss noch der Druckservice eingerichtet werden. Die Rolle ist bereits installiert. Ich starte die Verwaltungskonsole und importiere die Einstellungen aus der zuvor exportierten Datei:

Damit ist auch der Druckservice wieder einsatzbereit:

Ein kurzer Testdruck bestätigt die Funktionalität. Da sich der Name nicht geändert hat, muss auch nichts auf den Clients angepasst werden:

Ich beende die Wartung in meinem Monitoring:

Der Server WS-FS1 ist jetzt migriert.

Ich nutze LAPS (Local Administrator Password Solution). Mit dieser kostenlosen Erweiterung von Microsoft ändern Domänen-Computer regelmäßig das Passwort des lokalen Administrators und speichern dieses in ihrem AD-Computerobjekt ab. Mit einer GUI und den erforderlichen Rechten können dann die Passwörter bei Bedarf ausgelesen werden:

LAPS wird bei mir komplett über eine GPO installiert und konfiguriert. Die GPO greift bereits. Aber die alten Fileserver hatten bereits ein Passwort hinterlegt. Über ein AD-Attribut wurde die Ablaufzeit definiert. Das bedeutet, dass meine neuen Fileserver bis zu diesem Zeitpunkt das Passwort nicht ändern.

Daher habe ich mit der GUI beide Fileserver aufgerufen und mit SET das Ablaufdatum auf JETZT gelegt. Beim nächsten gpupdate werden die Server also ein neuen Passwort eintragen:

So ist dieser Teil auch wieder sauber:

Nebenbei, wer nun meint, mein aktuelles Passwort vom Server ws-fs1 zu kennen: ich hab den Prozess natürlich nach dem ScreenShot noch einmal wiederholt.

Im Hyper-V entferne ich die alten Server-Objekte:

Das Löschen der VMs entfernt nur deren Konfigurationsdateien. Die VHDX-Dateien bleiben erhalten. Diese lösche ich ebenfalls:

Mit der Entfernung der beiden Server WS-FS1 und WS-FS2 sind die letzten Windows Server 2012R2 aus meiner Infrastruktur verschwunden. Ich habe jetzt eine Mischumgebung aus Windows Server 2016 und 2019. Damit kann ich die alte GPO entfernen. Ebenso kann der alte WMI-Filter weichen:

Im WSUS stehen die beiden Server noch als Windows Server 2012R2:

Die Betriebssysteme sind bereits uptodate. Daher stelle ich nur eine Verbindung zum WSUS her und berichte das aktuelle Patchlevel:

Jetzt wird auch das Objekt im WSUS aktualisiert:

Die Updates für Windows Server 2012R2 hatte ich bereits aus der Konfiguration des WSUS entfernt. Dies geht mit den Optionen im Punkt „Produkte“ recht einfach. Eine Bereinigung der nicht mehr erforderlichen Updates ist daher auch nicht notwendig.

Die neuen Server bringen den Windows Defender mit. Diesen konfiguriere ich mit einer Gruppenrichtlinie. Durch die aktive Suche nach Schadcode hat der Scanner einige Dateien in meinen Freigaben gefunden, die er als Bedrohung einstuft:

Diese Dateien möchte ich aber gerne behalten, da sie mir bei meinen Bedrohungs-LABs und meinen Forschungsarbeiten sehr nützlich sind. Daher verschlüssle ich die Funde in einem ZIP-Archiv und schütze dieses mit einem Passwort.

Um weitere Dateien zu erkennen, starte ich einen Vollscan:

Meine letzten Windows Server 2012R2 sind migriert. 2 weitere Server laufen nun mit Windows Server 2019. Die Portierung der DFS-Komponenten war einfacher als gedacht. Ebenso konnte ich meine Datensicherung fortführen und musste keine Daten duplizieren. Somit habe ich meine selbst gestellten Anforderungen alle einhalten können.

Wie üblich gibt es hier diesen Beitrag auch als PDF.

Stay tuned!