Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Zielsetzung

IST-Situation

Meine Windows Infrastruktur soll auf Windows Server 2019 aktualisiert werden. Nur noch zwei Server sind mit Windows Server 2016 unterwegs. Einer davon ist mein Server WS-CM. Auf ihm läuft mein Windows Server Update Service (WSUS) und mein Windows Deployment Service (WDS)

Der WSUS hat derzeit Updates für Windows Server 2016 und 2019 geladen. Er braucht also recht viel Platz. Der WDS hat ebenfalls einige Betriebssysteme im Katalog, die ich nicht mehr benötige.

SOLL-Situation

Der Service WSUS muss unbedingt weiter betrieben werden. Idealerweise natürlich nur noch mit Updates für Windows Server 2019 und mein Windows 10. Natürlich könnte ich den Service auf einen neuen Server portieren, aber durch eine Neuinstallation kann ich nur noch die erforderlichen Produkte im WSUS hinzufügen und einfach alles neu herunterladen lassen. Und auch die ganzen Server und Clients melden sich wieder im WSUS – dank der Gruppenrichtlinien.

Wenn ich also einfach einen neuen Server für WSUS installiere, dann kann ich eine gute Bereinigung durchführen. Aber was ist dann mit dem Service WDS? Derzeit habe ich für ihn keine Verwendung mehr. Und sollte ich ihn dennoch wieder benötigen, dann würde ich ihn gerne auf einem anderen Windows Server betreiben. Damit könnte ich den alten Server WS-CM einfach abschalten und einen WS-WSUS und optional einen WS-WDS neu installieren.

Migrationsszenario

Und genau das wird mein Migrationsszenario: Es wird bis auf die Scriptlogik keine Datenübernahme geben. Der alte Server WS-CM wird abgeschaltet und ich installiere heute einen neuen WS-WSUS. Dort werde ich auch das Layout des WSUS etwas anpassen.

Und später werde ich bei Bedarf einen WS-WDS bereitstellen.

Vorarbeiten

Sichtung der Basisinfos

Für eine Neuinstallation sammle ich erst einmal einige Daten. Der aktuelle Server hat eine IPv4 in meinem Servernetz. An dieser hängt die Freigabe in meiner Firewall für die WSUS-Netzwerkverbindungen. Die IPv4 gebe ich später dem neuen Server:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Aktuell sind für jeden der Services eine eigene VHDX-Datei im Hyper-V vorhanden. Diese sind als eigene Volumes eingebunden. Hier kann man gut den Platzbedarf ablesen und eine Ersparnis durch die Neuinstallation erahnen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Meinen WSUS habe ich mit 2 kleinen PowerShell-Scripten verbessert. Eines ist für die tageweise Genehmigung der neuen Updates gedacht. Und das andere zeigt mir den realen Updatestand bereinigt um die noch nicht genehmigten Updates an (das schafft Microsoft bis heute nicht). Diese Scripte muss ich auf dem neuen Server wieder einspielen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Die Scripte werden als Script-Tasks automatisch ausgeführt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Ich exportiere hier beide Aufgaben in je eine XML-Datei. So kann ich sie auf dem neuen Server leicht wieder importieren:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Dann kopiere ich die Scriptverzeichnisse auf mein AdminShare:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Mein WSUS kann direkt über den Standardport 8530 angesprochen werden. Daher hat er keine weiteren interessanten Zertifikate im persönlichen Speicher:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Früher hatte ich den WDS auch für einen Bitlocker-NetworkUnlock-Service verwendet. Dabei konnte ein Client über eine GPO angewiesen werden, beim Start via PXE-Boot einen WDS mit einem Sicherheitszertifikat zu suchen. Wenn er diesen findet und das Sicherheitszertifikat passt, dann war für den Bitlocker-Prozess keine Start-PIN-Eingabe erforderlich. Das Zertifikat hatte ich in einem Container erstellt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Wie man aber erkennen kann, ist das Zertifikat seit einigen Monaten abgelaufen. Ich habe den Service deaktiviert, da er den Startprozess unangenehm lang verzögert. Da gebe ich lieber die PIN beim Hochfahren ein. Das Feature wird also nicht mehr benötigt.

Zuletzt sichte ich noch die installierten Rollen und Features. Dies gibt ggf. Aufschluss auf Services, die nicht so offensichtlich sind:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Sonst ist auf dem Server aber nichts weiter zu finden.

Sichtung der Rolle WDS

Ich werde heute die Rolle Windows Deployment Service nicht mit migrieren. Aber dennoch werde ich den aktuellen Stand hier dokumentieren. Das kann bei einer neuen Bereitstellung durchaus helfen.

Im WDS ist ein Server-Image vorhanden. Das ist schon fast zwei Jahre alt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Bei den Clients sieht es nicht viel besser aus:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Dann gibt es noch diverse Start-Images. Eines davon ist eine Recovery Environment. Mit dieser kann eine Bare Metal Recovery durchgeführt werden. Alles ist aber veraltet:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

In den Optionen sammle ich noch einige Screen-Shots:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Das soll dann aber auch genügen.

Sichtung der Rolle WSUS

Im Service WSUS dokumentiere ich auch noch einmal den aktuellen Stand. Derzeit habe ich für meine Windows Server 2 Container für die Aktualisierung. Mein Genehmigungs-Script wird die neuen Updates nach 7 Tagen Liegezeit auf dem Container „Updates-Sofort“ genehmigen. Erst weitere 7 Tage später ist der Container „Updates-Verzoegert“ an der Reihe. Durch eine gezielte Platzierung meiner Windows Server kann ich so steuern, wann welcher Server seine Updates installiert. Cluster-Systeme lassen sich so schön voneinander trennen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

In meinem aktuellen WSUS lade ich für diese Produkte Updates herunter:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Die Updates sind in einzelne Klassifizierungen aufgeteilt. Hier fahre ich sehr gut mit dieser Einstellung:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Die Updates werden erst nach der Genehmigung geladen. Das macht mit meinem Genehmigung-Script besonders Sinn, denn dieses lehnt nicht erwünschte Updates ab. So kann ich viel Speicherplatz und Bandbreite sparen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Meine eigene Umgebung enthält ausschließlich deutsche Installationen. Daher kann ich hier gut filtern:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Mein WSUS schaut einmal am Tag nach neuen Updates. Die Zeit ist kein Zufall. Nach der Synchronisierung läuft das Genehmigungsscript und kann bei Bedarf Updates genehmigen. Diese werden dann heruntergeladen. Und wenn dann am Folgetag 03:00 die Update-Installationen beginnen, dann hab ich die Server gleich mit dem Setup versorgt.

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Ich verwende die Standardgenehmigung nur für die Updates von Windows Defender. Den Rest erledigt mein Script:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Diese Einstellung hatte ich nicht verändert:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Bei dem neuen WSUS werde ich einige Anpassungen vornehmen.

Migration

Bereitstellung der neuen VM

In meinem Hyper-V benenne ich den aktuellen Server um:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Dann erstelle ich eine neue VM:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Als Betriebssystemdatenträger kopiere ich mein vorbereitetes Master-Image als VHDX in den VM-Ordner:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Die neue System-Partition liegt nun an der richtigen Stelle:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Jetzt bekommt die VM den Feinschliff: etwas mehr CPU, die neue VHDX und einige Konfigurationsanpassungen für z.B. den automatischen Start gehören eingetragen. Ebenso braucht der Server eine Netzwerkverbindung. Für die Aktivierung kommt er erst einmal in mein Client-VLAN 110:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Dann passe ich die Boot-Reihenfolge an:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Und danach erhält der Server eine zusätzliche VHDX, in der er die Updates abspeichern kann. Diese lege ich auf einem langsameren Datenträger ab – ein NVMe-Storage ist mir dafür zu schade:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

An dieser Stelle habe ich mich dann dazu entschlossen, den Servernamen nicht zu übernehmen. Die VM WS-CM habe ich jetzt in WS-WSUS geändert. Ebenso habe ich die Dateien der VM in einen passenden Ordner auf meinem Dateisystem im Hyper-V verschoben.

Abschaltung des alten Servers & Maintenance

Der alte Server kann einfach abgeschaltet werden, denn er hat keine weiteren Abhängigkeiten. Damit mich mein Monitoring nicht permanent anpiept, pausiere ich die Sensoren für den alten WSUS:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Jetzt fahre ich den alten Server einfach herunter.

Betriebssystemvorbereitung

Danach starte ich den neuen Server. Das Setup wird mit einer Out-of-Box-Konfiguration abgeschlossen. Danach kann ich mich lokal anmelden:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Durch den neuen Servernamen wird auch ein neues Computerkonto im Active Directory benötigt. Dieses erstelle ich VOR dem Domain Join in der richtigen Organisationseinheit. So kann ich sicherstellen, dass der neue Server von der ersten Minute an die für ihn richtigen Gruppenrichtlinien bezieht. Der Server kommt in meinen Standard-Tier-ServerContainer:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Dann passe ich noch im gleichen Dialog den Namen der für den Domain Join berechtigten AD-Gruppe an. Das muss ja nicht immer ein Domain Admin erledigen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Der nächste Schritt ist das Ändern des Servernamens. Dabei verzichte ich bewusst auf den Domain Join: Der Server würde sonst mit seinem generischen Namen ins AD wechseln und sich DANACH umbenennen. Er würde also ein eigenes Computerkonto im Standard-Container „CN=Computers“ erstellen und würde so nicht in meiner Wunsch-Organisationseinheit landen. Zudem würde der Rename fehlschlagen, denn es gibt ja schon einen anderen Computer mit diesem Namen – den habe ich ja eben im AD vorprovisioniert… Also lieber eins nach dem Anderen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Vor dem Neustart bekommt der Server die alte IPv4 des Servers WS-CM. Damit spare ich mir in der Firewall die Anpassungen der Ausnahmen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Nach einem Neustart melde ich mich wieder an und bereite den Domain Join vor. Mit meinem PAM-Tool delegiere ich die Berechtigung an meine T3-Kennung. Der Account hat sonst keine Rechte:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Und dann kann der Domain Join starten:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Das wäre dann auch erledigt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Jetzt kommt noch die Aktivierung:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Und zuletzt wird auf dem zusätzlichen Datenträger eine Partition für die Ablage der WSUS-Updates erstellt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Rollen und Features

Im Server Manager starte ich die Rollen-Installation. Die Auswahl ist übersichtlich. In den Details wähle ich die Windows Internal Database aus. Diese reicht für meine Anforderungen locker aus:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Die Rollen-Installation fragt nun den Speicherort der Updates ab. Auf der neuen Partition erstelle ich noch ein Verzeichnis in der Root. Diesen Pfad übergebe ich dann dem Server Manager:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

An der erforderlichen IIS-Auswahl verändere ich nichts:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Nach der Rollen-Installation starte ich das Post-Deployment:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Das dauert nur wenige Sekunden:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Konfiguration Rolle WSUS

Weiter geht es mit der Feinkonfiguration des WSUS. Ich starte die Management-Konsole und mir wird der Einrichtungsassistent angezeigt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Meine flache Struktur besteht aus einem einzelnen WSUS. Dieser soll sich seine Updates direkt bei Microsoft holen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Dafür ist keine Proxy-Konfiguration erforderlich:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Danach vergeht eine kleine Ewigkeit, in der mein WSUS alle Informationen online abfragt und zusammenstellt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Danach kann ich die Sprachen auswählen. Wie beim alten WSUS benötige ich ausschließlich deutsche Updates:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Weiter geht es mit der Auswahl der Produkte. Meine Infrastruktur ist durch meine Windows Server 2019 Migrationen sehr homogen geworden. Ich benötige nur noch Updates für dieses Server-Betriebssystem (mein letzter Server mit Windows Server 2016 wird morgen umgestellt). Windows 10 migriere ich in einigen Tagen auf 20H2. Daher lasse ich diese Werte noch außen vor:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Die Klassifizierungsauswahl hat sich bewährt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Die Synchronisierung soll wieder vor Mitternacht durchlaufen. Eine „geradere“ Zeitangabe als beim alten Server sieht aber irgendwie harmonischer aus:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Die Erstsynchronisierung starte ich später. Die Einrichtung ist damit erst einmal abgeschlossen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Anpassung Gruppenrichtlinie

Dennoch wird der neue Server von meinen Systemen nicht gefunden, denn er hat einen anderen Namen. Auf meinem Domain Controller passe ich nun die entsprechenden Gruppenrichtlinien an. So lenke ich meine Clients und Server auf den neuen WSUS. Die Server-GPO editiere ich direkt auf dem Domain Controller:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Die Clients arbeiten aber nicht mit Windows Server 2019, sondern mit Windows 10 v1909. Dieses Betriebssystem unterscheidet sich vom Server. Demnach gibt es auch immer wieder Probleme mit der Verwendung der falschen Gruppenrichtlinien-Vorlagen (ADXM). Daher editiere ich die Client-GPO auf einem Windows 10 Rechner, den ich als GPO-Editorsystem eingerichtet habe. Meine T2-Kennung (Clientadmin) muss dafür temporär für die Editierung der Gruppenrichtlinien berechtigt werden. An die Gruppe GG-Admin-AD-GPO habe ich das Recht im AD delegiert:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Dann suche ich die Client-GPO und passe den WSUS-Eintrag an:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Feintuning WSUS

Nach einem gpupdate oder einer passenden Wartezeit melden sich die Systeme meiner Infrastruktur nach und nach beim neuen WSUS. Dabei werden alle im Container „nicht zugewiesene Computer“ aufgenommen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Meine Aktualisierungen möchte ich direkt mit der WSUS-Konsole kontrollieren können. Meine Gruppenrichtlinie weist alle Clients und Server an, Updates automatisch zu installieren (es gibt für meine Hyper-V-Hosts eine Ausnahme). Wenn nun aber alle Systeme im gleichen Container liegen und ich auf diesem die Updates genehmige, dann installieren alle zeitgleich die Updates und starten danach auch neu. Das würde einiges durcheinanderbringen. Daher werde ich ein anderes Verfahren konfigurieren:

  • Ich erstelle neue Container und verteile meine Server und Clients sinnvoll auf diese.
  • Die Updates werden dann an unterschiedlichen Tageb auf den Containern genehmigt.
  • So kommen zwar alle Systeme täglich zum WSUS, aber nur die Systeme im passenden Tages-Container erhalten ihre Updates und starten neu.

Das verteilt die Last und auch die Neustarts. Zudem kann ich so auch „schlechten“ Updates begegnen. Diese würden eben nur einen Teil meiner Server „versauen“ und ich könnte die Verteilung auf den anderen Containern rechtzeitig aufhalten.

Neue Container können einfach erstellt werden:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Ein paar Minuten später ist meine Wunsch-Struktur fertig. Der Haupt-Container „Genehmigung“ wird durch mein Genehmigungs-Script vollautomatisch bearbeitet. Hier muss jeder Server in genau einem Tages-Container platziert werden:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Der Haupt-Container „Ansichten“ ist für eine logische Gruppierung der Systeme gedacht. Hier setzt ein anderes Script an zud zeigt mir das Ergebnis der Updates gruppiert nach Clients und Server an – oder welche Gruppierung ich auch immer wünsche. Jedes System muss auch hier genau einer Ansicht zugeordnet werden.

Das muss ich nun für jeden Computer konfigurieren:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Ein Computer kann in mehreren Containern Mitglied sein. Und meine Regel lautet: genau eine Ansicht und genau ein Tages-Container muss ausgewählt werden:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Nachdem ich mir hier ein neues Layout definiert habe geht es zu einer fehlenden Erweiterung. Die Details zu den Computern und Updates werden nur nach der Installation dieses Hilfstools angeteigt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Das Setup habe ich bereits in der Schublade auf meinem Fileserver. Der Report Viewer braucht zusätzlich noch die CLR Types vom SQL Server:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Danach kann der Report Viewer installiert werden:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Nach einem Neustart der WSUS-Konsole wird ein Testbericht generiert:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Script-Automation

Im nächsten Schritt bringe ich meine Automationsscripte in den WSUS ein. Dabei handelt es sich um PowerShell-Scripte, die über geplante Aufgaben automatisch gestartet werden. Die Aufgaben hatte ich auf dem alten Server in XML-Dateien exportiert. Zuerst kopiere ich mir die Verzeichnisse und die XML-Dateien nach Laufwerk C:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Dann kann ich die Aufgaben importieren. Ich beginne mit dem Genehmigungsscript „WSUS-UpdateApproval.ps1“:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Auf die gleiche Weise hole ich das Script „WSUS-RealUpdateState.ps1“ als Aufgabe dazu:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Das Feintuning nehme ich später vor.

Datensicherung

Denn eine Datensicherung ist bei den geplanten Aufgaben auch mit dabei. Auch hier importiere ich eine XML-Datei. Der Task soll über einen Group Managed Service Account laufen. Diesen kann ich aber nicht direkt eintragen. Also hinterlege ich temporär meine T3-Anmeldeinformationen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Für den gMSA-Delegierungsvorgang muss ich auf meinen Domain Controller wechseln. Dort benötigt meine T3-Kennung aber noch die administrativen Rechte auf Zeit delegiert:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Danach ist die Anmeldung am Domain Controller als Stephan-T3 kein Problem. Hier starte ich mein PowerShell-Tool „gMSA-Admin“ und privilegiere den neuen WS-WSUS für den Abruf der aktuellen Anmeldeinformationen vom Backup-gMSA:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Direkt im Anschluss kann ich über mein Script den Task-Account austauschen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Der Server ist neu. Daher muss ich für den Sicherungsjob noch einen Auftrag auf meinem Backup-Server konfigurieren. Dafür nutze ich meine T1-Kennung und privilegiere sie für den Zugriff auf meinem Backup-Server:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Meine ServerImage-Backup-Lösung basiert auf dem Windows Server Backup Feature, das über ein VB-Script zeitgesteuert ausgeführt wird. Die dazugehörige Konfiguration liegt zentral auf meinem Backup-Server und ist eigentlich auch nur eine ini-Datei. Hier steht noch der alte WS-CM drin:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Den alten Servernamen passe ich einfach an:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Danach lösche ich noch die Sicherungen des alten Servers von der Backup-Festplatte:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Damit sollte die nächste Sicherung fein durchlaufen.

Monitoring

Eine Kleinigkeit für das Daily Business fehlt noch: Die Integration ins Monitoring. Bei mir werkelt dafür ein PRTG-Server, dem ich ein paar zusätzliche PowerShell-Scripte als Custom-Sensors programmiert habe. Einer davon erfasst die Basisdaten für meine Windows Server. Dafür modifiziere ich den alten Eintrag WS-CM:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Den zweiten Sensor kann ich einfach durch eine Namensanpassung modifizieren:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Aber der erste Sensor wird besser gelöscht und neu erstellt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Für den neuen Sensor kann ich bequem den Dialog im Webportal vom PRTG verwenden:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Einige Eingaben später ist der Sensor eingerichtet:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Und einen weiteren Moment später ist der Sensor aktiv:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

WSUS-UpdateApproval

So. Nachdem die Basics erledigt sind, kann ich nun wieder an meine Automations-Scripte für den WSUS ran. Wie schon erwähnt, soll mein Script „WSUS-UpdateApproval“ einmal am Tag Updates auf vordefinierten WSUS-Containern genehmigen. Zusätzlich soll es nicht erwünschte Update ablehnen. Die Konfiguration basiert ebenfalls auf einer ini-Datei. Diese muss ich an die neue Struktur im WSUS anpassen. Wichtig ist dabei, dass es für jeden WSUS-Container einen passenden Eintrag für den Genehmigungsprozess gibt:

  • Genehmigt werden Updates nur auf den Containern im Hauptordner „Genehmigung“. Die anderen Container unter „Ansichten“ erhalten keine Updates.
  • Das GeneralDelay kennzeichnet die „Liegezeit“ von neu synchronisierten Updates: Wenn mein WSUS heute ein neues Update bei Microsoft erkennt, dann wird mein Script dieses Update beim nächsten Lauf erkennen und mir per Mail eine Info zukommen lassen. Dann wird das Update die nächsten 6 Tage ignoriert. Erst nach 7 Tagen wird das Update auf den an diesem Tag aktiven Containern genehmigt.

Aus der Grafik kann man die Zusammenhänge ableiten:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Der Server hat zwischenzeitlich die Synchronisierung neuer Updates vom Microsoft Update Server abgeschlossen. Bisher sind keine Updates genehmigt worden:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Denn ich habe die Standard-Genehmigungsregel NICHT aktiviert:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Jetzt müsste ich die Updates ablehnen, die synchronisiert wurden aber nicht gebraucht werden. Bei der Menge an Updates ist das extrem zeitraubend:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Aber auch das kann mein Script für mich automatisieren. Dafür habe ich die Sektion „BlockWords“ in der Konfiguration eingebaut. Hier kann ich die Textbausteine angeben, die ich in den Updates nicht haben möchte. Beim nächsten Lauf werden passende Update dann automatisch abgelehnt.

Das Muster dabei lässt sich gut in der Konfiguration erkennen. Ich benötige z.B. verschiedene Windows 10 Versionen nicht mehr. Warum soll ich die also pflegen, genehmigen und herunterladen? Gleiches gilt für x86-basierte Systeme oder ARM-Plattformen. Die verwende ich nicht. Also: raus damit.

Mit der Sektion „IgnoreWords“ kann ich mit den Texten übereinstimmende Updates ignorieren, statt sie abzulehnen oder zu genehmigen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Es wird Zeit für einen Scriptlauf. Dann kann man die Logik in Aktion sehen. Das Script baut eine Verbindung zum WSUS auf, liest die Konfiguration ein und bestimmt, welcher WSUS-Container heute passende Updates genehmigt bekommt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Dann werden die Updates im Datenbestand geladen. Aus der Gesamtmenge werden die bereits abgelehnten Updates ausgefiltert. Dann greifen meine Textfilter. Alle Updates mit einer Übereinstimmung in den Blockwords werden für die Ablehnung vorgemerkt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Das Script erkennt bei jedem Update den Tag der Synchronisierung. Dieses Datum wird für die Berechnung der Verzögerungsdauer verwendet:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Eine Ausnahme kann aber auch definiert sein. Bei Signatur-Updates wäre eine Wartezeit von 7 Tagen eher fatal:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Alle für die Ablehnung vorgemerkten Updates können noch einmal kontrolliert werden. Die Blockwords sind im Text mal teilweise farbig dargestellt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Das Script kennt einen Admin- und einen Task-Modus. Im Admin-Modus muss die Genehmigung und die Ablehnung manuell bestätigt werden. Im Task-Modus wird automatisch gearbeitet. Im Admin-Modus kann ich also die vielen abzulehnenden Updates noch einmal validieren. Ich will ja nicht zu viel löschen. Jeder Scriptlauf erstellt eine Logdatei. Diese nutze ich nun für eine Anpassung der Konfiguration. Hier finde ich z.B. Updates für Windows 10 v2004:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Diese Betriebssystemversion verwende ich nicht. Daher werde ich sie in die Blockwords aufnehmen. Zusätzlich interessieren mich weitere Patterns nicht. Meine Konfigurationsdatei wird daher erweitert:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Ich beende das Script ohne eine Genehmigung oder Ablehnung und starte es mit der aktualisierten Konfiguration erneut. Von den 535 Updates sind jetzt nur noch 289 über. Und das nur durch die Ausblendung einer Windows 10 Version und den beiden Architekturen (ARM64 und x86). Nicht schlecht, oder?

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Jeder Lauf schlägt mir potentielle neue KeyWords für die Blocklist vor. Beim „ersten“ Lauf kommt da natürlich einiges zusammen. Danach starte ich die Ablehnung der nicht erforderlichen Updates:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Funktionsupdates habe ich in meinem Script ausgeschlossen. Dies entferne ich in der Management-Konsole:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Ebenso sind etliche Exchange Updates enthalten, die ich durch meinen CU-Stand nicht mehr benötige. Auch diese lösche ich manuell:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Nach diesen manuellen Bereinigungen starte ich mein Script erneut:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

So sieht das schon viel angenehmer aus. Für einen ersten Lauf des WSUS deaktiviere ich in der Konfiguration des Scriptes das Delay:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Mit einem neuen Scriptlauf werden die 270 Updates für die primäre Genehmigung erkannt. Primär bedeutet dabei, dass die Updates noch nie genehmigt und daher auch noch nicht heruntergeladen wurden. Die Genehmigung wird auf den WSUS-Containern vorgenommen, die „heute“ an der Reihe sind. Nach einer primären Genehmigung wird an jedem Folgetag eine Genehmigung auf ausstehenden Containern ermittelt und durchgeführt, bis alle Container und damit alle Computer versorgt werden:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Ich bestätige mit Enter die Genehmigung. Heute ist Mittwoch. Daher werden die Updates für diesen Container und den Container „sofort“ freigeschaltet:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Diese Updates sind bei mir in der Infrastruktur schon installiert. Daher hole ich die Genehmigung mit meinem Script für alle anderen Container jetzt nach. Dafür ändere ich einfach in der Konfiguration den weekday:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Der nächste Scriptlauf erkennt, dass „heute“ alle Container an der Reihe sind:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Dann wird die Genehmigung durchgeführt:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Ich teste das Ergebnis mit der WSUS-Konsole. Dieses Update ist auf allen erforderlichen Containern aktiv:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Alle Updates für Windows 10 20H2 werden derzeit noch durch das Script ignoriert. Das kann ich in der Konsole ebenfalls bestätigen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Jetzt schaue ich mir noch die Updates an, die nicht genehmigt und nicht abgelehnt wurden. Die 20H2er sind irrelevant. Aber die Signatur-Updates brauchen noch eine Starthilfe (diese werden von meinem Script ignoriert und sollen über eine Default-Genehmigung vom WSUS bereitgestellt werden. Diese läuft aber erst beim nächsten Sync.). Also genehmige ich manuell:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Nach einer Genehmigung wird der WSUS die Updates von den Microsoft Servern herunterladen. Das kann einen Moment dauern:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Danach passe ich meine Script-Konfiguration wieder auf die einzelnen Wochentage an und aktiviere das Delay von 7 Tagen.

Cleanup

Der alte Server wird nun nicht mehr benötigt und kann gelöscht werden:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Die Festplattendateien werden dabei nicht vergessen:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Ebenso wird das alte Computerkonto im Active Directory nicht mehr benötigt und kann gelöscht werden:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

TroubleShooting Performance

Durch die vielen Scriptläufe und den Download der vielen Updates kommt es zu einem Problem in der WSUS-Konsole. Die Ursache ist mir durchaus bekannt und kann auf zu wenig System-Ressourcen zurückgeführt werden:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Der WSUS stellt seine Anwendung im IIS bereit. Dabei genügen die Standardeinstellungen für den Application-Pool sehr selten. Ich passe die Werte entsprechend an:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Nach den beiden Modifikationen starte ich den IIS einmal durch:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Danach funktioniert die Verbindung zwischen WSUS und Konsole wieder.

Zusammenfassung

Eine Verbesserung

Meine Clients und Server haben sich mittlerweile alle beim WSUS gemeldet und wurden in ihre neuen Container eingruppiert. Auch die Updates sind alle geladen. So konnten meine Computer ihr Patchlevel an den WSUS melden. Und in der WSUS-Console kann ich das Ergebnis überprüfen. Man erkennt viel Grün. Ebenso kann man sehen, dass ich meine Systeme auf die 7 Wochentage aufgeteilt habe:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Mein Script „WSUS-RealUpdateState“ hat mir auch schon die erste Mail zukommen lassen. Darin werden die Computer mit ihrem echten Update-Level gezeigt (Updates, die nicht genehmigt wurden, werden nicht gewertet). Auch hier ist alles Grün. Zusätzlich kann man jetzt recht gut erkennen, wofür ich die „Ansichten“-Container verwende:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Durch die gezielte Auswahl der erforderlichen Updates habe ich auf meinem Datenträger E: enorm viel Speicherplatz einsparen können:

Serie „Migration auf Windows Server 2019“ – Migration eines WSUS-Servers (WS-WSUS)

Insgesamt ist der Server besser als vorher aufgestellt. Die Migration kann damit als abgeschlossen betrachtet werden.

Den Artikel gibt es wie gewohnt hier als PDF zum downloaden. Einige meiner PowerShell-Scripte können ganz unten auf der Übersichtsseite gefunden werden.

Kommentar hinterlassen