Das hier wird nicht nur irgendeine Anleitung um WSUS (Windows Server Update Services) auf einem Windows 2019 Server zu installieren. Wie das Word „komplett“ bereits verraten mag, werde ich das auf meine Testumgebung vom Anfang bis hin zum Ende durchziehen und euch eine vollständige Anleitung von der Installation über Konfiguration und Verteilen der Einstellungen per GPO bereitstellen.
Kurzes Vorwort: Wem hier aufgefallen ist, dass ich in den letzten Tagen sehr viele Artikel zu den Grundlagenkonfigurationen von WSUS und Gruppenrichtlinien geschrieben habe, soll wissen dass ich mein Testsystem im Rahmen einer spezifischen Arbeits-Aufgabe aufsetze und Teilbereiche endlich auskonfigurieren. Im Arbeitsalltag nimmt man sich nicht die Zeit um einzelne Einstellungen zu hinterfragen, zu testen oder ob es auch ohne den zusätzlichen Haken geht. Die Zeit ist aktuell da und muss genutzt werden. Die Erkenntnisse und Ergebnisse halte ich über meine Seite fest und stelle sie den Interessierten IT’s zur Verfügung. Nur durch das Teilen des Wissens können wir für Fortschritt sorgen!
Kurz zu mir: WSUS (Windows Server Update Services) administriere ich in verschiedenen Umfängen und Anforderungen seit 2004 und Windows Server 2003. Von einzelnen WSUS-Server bishin zu größeren WSUS-Replizierungsinfrastrukturen (Upstreamservern) ist alles dabei gewesen.
Eigentlich sollte man für den WSUS einen dedizierten Server nehmen, da der mit der Zeit sehr Ressourcenhungrig wird. In meinem Fall installiere die WSUS Rollen auf meinen bestehenden virtuellen DC01 aus Platzgründen.
Ziele:
- WSUS stellt Windows Updates bereit. Updates ziehen die Clients direkt von Microsoft und nicht direkt vom lokalen WSUS aus Platzgründen
- Windows Clients werden automatisch der WSUS Target Group „clients_level4“ zugeordnet
- Windows Clients können über eine AD-Gruppe WSUS Target Group „clients_level3“ zugeordnet werden
- Windows Server werden automatisch der WSUS Target Group „server_level3“ zugeordnet
- Windows Server können über eine AD-Gruppe WSUS Target Group „server_level4“ zugeordnet werden
Die Idee hinter der Konfiguration
Neben den ganzen Basics die ich auf meiner Seite zu den Themen bereitstelle, findet ihr auch etwas ausgefeiltes und im Business anwendbare Konzepte. Wie auch dieses hier. In den meisten Windows Netzwerken wird es Clients und Server geben, die auch automatisierte geupdatet und neugestartet werden können. Im Einzelnen sollte man das Prüfen und Testen! Sicherlich bietet das automatisch Updaten und Neustarten auch seine Risiken, doch in der Summer läuft es meistens glatt und wenn nicht, hat man zumindest für die Server ein funktionierendes Backup mit Veeam oder Backup Exec.
Außerdem würde ich empfehlen die Updates nicht gleich am Patchdienstag im WSUS freizugeben, sondern 1-2 Wochen zu warten, je nachdem was eure Richtlinien hergeben.
Zu den Modies von Windows Update
- Mode 3= Download Updates, Installation der Updates manuell
- Mode 4= Download Updates und Installation nach Zeitplan mit Reboot
Grundsätzlich soll jeder Windows Client meiner Active-Directory standardmäßig automatisch geupdatet werden. Dazu bekommen alle Clients per GPO die Standardeinstellung für Windows Update Mode 4. Die wenigen Clients, die nur unter Aufsicht neugestartet werden dürfen, werden manuell per AD-Gruppe „wsus_clients_level3“ mit den Mode 3 Setting per GPO versorgt.
Bei den Servern ist es umgedreht und standardmäßig soll jeder Server die Einstellungen per GPO für Windows Update Mode 3 erhalten. Die Server, die ohne Aufsicht automatisch neustarten dürfen, werden der AD-Gruppe „wsus_server_level4“ zu gewiesen und erhalten per GPO die entsprechenden Settings.
Die Bezeichnung der AD-Gruppen und WSUS Target Gruppen mit dem Mode empfinde ich als nützlich. Natürlich könnte man auch anstellen von „Mode 3“ manuell schreiben und anstelle von „Mode 4″ ,“automatisch“.
Kandidaten für Windows Update Mode 4 – automatisch installieren und reboot
- Remote Desktop Server
- Dateiserver (möglich)
- Server die ohne angemeldeten Nutzer ihre Dienste bereitstellen
- WSUS
- Active Directory Domain Controller wenn mindesten zwei vorhanden sind die abwechselnd neu gestartet werden
- DNS-Server wenn mindesten zwei vorhanden sind
- Datenbankserver und Mailserver sollte man abwägen
1. WSUS Installieren
Die Installation vom WSUS ist kein Geheimnis und ziemlich einfach. Im Server Manager > Manage > Add Roles wählen wir die WSUS Rolle aus und bestätigen das anschließend angezeigt Fenster mit einem Klick auf „Add“ Features.
Die weiteren Fenster können wir mit dem Klick auf „Next“ übergehen bis wir an den Punkt kommen, der Speicherplatz auszuwählen. Diese Stelle ist wichtig und spätestens jetzt sollte, jeder der immer alles auf eine Parition installiert, eine weitere Partition erstellen / virtuelle Festplatten anhängen und die WSUS Daten auf der extra Partition auslagern. Ansonsten kann es schnell sein, dass euer Server steht, weil die Partition voll ist.
2. WSUS Posttasks – Konfiguration
Die Installation der Dienste innerhalb weniger Minuten erledigt, was toll ist. Doch nun beginnt der Spaß mit der Konfiguration. Im Servermanager klicken wir auf das Ausrufezeichen und dann auf „Launch Post-Installation tasks“. Der Start dieser Aufgaben dauert gefühlt länger als die Installation. Nach 5 Minuten des Wartens kann man die WSUS Console manuell starten. Das muss wohl ein Bug sein…
Den Einrichtungsassistenten klickern wir durch und starten den ersten Sync, damit der WSUS gleich die neusten Produkt-Kataloge zur Auswahl hat.
Anschließend könnt ihr die Sprachen einstellen. Wenn ihr nur deutsche und englische Versionen von Windows im Einsatz habt, hakt nur English und German an.
Danach könnt ihr auswählen, welche Update Kategorien ihr bereitstellen wollt und wann und wie oft der WSUS sich Updates ziehen soll. In meinem Fall täglich 2.22 am.
Damit der WSUS wirklich keine Updates herunterlädt, müsst ihr in der WSUS Konsole > Optionen > Update Files and Languages einen Haken bei „Don’t store updates local“ … setzen.
Eben muss noch in der WSUS Konsole > Optionen > Computers „User Group Policy or registry settings on computers“ aktiviert werden. Andernfalls müsst ihr die Computer manuell der Targetgroup zu ordnen was wir nicht wollen.
WSUS – Windows Update Einstellungen per GPO verteilen
Bei der Konfiguration der GPO fasse ich gerne die Einstellungen zusammen, die immer gleich sind. So auch hier. Bei wenigen Standorten macht es weniger Sinn. Bei mehreren Standorten lassen sich so die generischen GPO’s besser updaten. In meinem Beispiel lege ich eine GPO mit standort spezifischen Informationen an: „Config WSUS location specific“ und hänge die oben ans Root (mj.local). Jeder Client oder Server in der Domäne wird die Einstellungen nun bekommen!
| GPO Name | Location | GPO-Sicherheitsfilter | Einstellungen | |
| Config WSUS location specific | mj.local (root) | authenticated users (Standard) | Standortspezifische Einstellungen – Adresse zum WSUS und Reportingserver | |
| Config WSUS clients level 3 | MJ > testlab > clients | AD-Group „wsus_clients_level3“ (force/erzwingen) | u.a. Einstellungen für Windows Update Mode Level 3 | |
| Config WSUS clients level 4 | MJ > testlab > clients | Domain Computers | u.a. Einstellungen für Windows Update Mode Level 4 | |
| Config WSUS server level 3 | MJ > domain controllers MJ > testlab > server | Domain Computers Domain Controllers | u.a. Einstellungen für Windows Update Mode Level 3 | |
| Config WSUS server level 4 | MJ > domain controllers MJ > testlab > server | AD-Group „wsus_server_level4“ (force/erzwingen) | u.a. Einstellungen für Windows Update Mode Level 4 |
Wir legen GPO „Config WSUS location specific“ und hängen die wie in der Tabelle angedeutet, direkt ganz oben ins Root „mj.local“. Dadurch bekommt jeder Windows Client der Active Directory die Einstellungen um sich mit dem WSUS zu verbinden.
Alle weiteren GPO’s legen wir auch an und hängen die der Tabelle entsprechend an die OU’s.
Die Sicherheitseinstellungen und GPO-Settings könnt ihr den Screenshots entnehmen.
Hinweis: Es gibt auch hier keinen goldenen Weg. Ich mache es so, dass die an die AD-Gruppen „wsus_clients_level3“ und „wsus_server_level4“ hängenden GPO’s über „force“ erzwungen werden und die Standard WSUS GPO’s „wsus_clients_level4“ und „wsus_server_level3“ überschreiben, wenn der Windows Client der AD-Gruppe zugehörig ist.
WSUS mit SSL absichern
Der WSUS läuft und die Windows Clients verbinden sich zum WSUS über die GPO verteilen Einstellungen. Aktuell läuft die Kommunikation noch im Klartext. Damit sich das ändert, stellen wir zumindesten das Reporting vom WSUS auf SSL.
WSUS Tuning
Wie ihr eurem WSUS bzw. im speziellen dem IIS Beine macht und auch noch die lästigen Abstürze der WSUS Konsole beseitigt, könnt ihr in meinem Artikel WSUS Tuning, Konsolen Timeout beseitigen erfahren.
WSUS Troubleshooting
Wie wir alle schon bemerkt haben, ist der WSUS nicht so liebevoll und rund entwickelt wie andere Produkte von Microsoft. Viele Tücken der WSUS Console bekommt man weg, in dem der IIS etwas aufgebohrt wird, vorausgesetzt der Server hat genügend CPU und RAM. In der Regel laufen meine WSUS-Server dediziert mit 4 CPU’s und 8 GB Ram.
Selbst auf meinem Test-WSUS den wir eingerichtet haben, stürzt die Console schon bei zwei Clients ab…
Wie ihr Fehler im WSUS-Client behebt und Verbindungsprobleme analysiert, könnt ihr natürlich auch hier lesen.
Schreibe einen Kommentar
Du musst angemeldet sein, um einen Kommentar abzugeben.