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.

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.

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.

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:

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:

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:

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

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

Dann kopiere ich die Scriptverzeichnisse auf mein AdminShare:

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

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:

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:

Sonst ist auf dem Server aber nichts weiter zu finden.

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:

Bei den Clients sieht es nicht viel besser aus:

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:

In den Optionen sammle ich noch einige Screen-Shots:

Das soll dann aber auch genügen.

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:

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

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

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:

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

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.

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

Diese Einstellung hatte ich nicht verändert:

Bei dem neuen WSUS werde ich einige Anpassungen vornehmen.

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

Dann erstelle ich eine neue VM:

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

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

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:

Dann passe ich die Boot-Reihenfolge an:

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:

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.

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:

Jetzt fahre ich den alten Server einfach herunter.

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

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:

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:

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:

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

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:

Und dann kann der Domain Join starten:

Das wäre dann auch erledigt:

Jetzt kommt noch die Aktivierung:

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

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:

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:

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

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

Das dauert nur wenige Sekunden:

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

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

Dafür ist keine Proxy-Konfiguration erforderlich:

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

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

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:

Die Klassifizierungsauswahl hat sich bewährt:

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

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

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:

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:

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

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:

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:

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:

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:

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

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:

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

Danach kann der Report Viewer installiert werden:

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

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:

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

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

Das Feintuning nehme ich später vor.

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:

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:

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:

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

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:

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:

Den alten Servernamen passe ich einfach an:

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

Damit sollte die nächste Sicherung fein durchlaufen.

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:

Den zweiten Sensor kann ich einfach durch eine Namensanpassung modifizieren:

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

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

Einige Eingaben später ist der Sensor eingerichtet:

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

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:

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

Denn ich habe die Standard-Genehmigungsregel NICHT aktiviert:

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

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:

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:

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:

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

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

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

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:

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:

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?

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:

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

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

Nach diesen manuellen Bereinigungen starte ich mein Script erneut:

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

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:

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

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:

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

Dann wird die Genehmigung durchgeführt:

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

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

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:

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

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

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

Die Festplattendateien werden dabei nicht vergessen:

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

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:

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:

Nach den beiden Modifikationen starte ich den IIS einmal durch:

Danach funktioniert die Verbindung zwischen WSUS und Konsole wieder.

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:

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:

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

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.