Anforderung: Wir brauchen einen neuen WSUS
Vorhandenes Material: Hardware, VMware und Datacenter-Lizenz Windows Server 2012 R2
Fazit: Kein Problem – schnell gemacht
Schritt 1: Neue Maschine im vcenter anlegen
Schritt 2: Betriebssystem vom ISO installieren, das auf der SAN bereitliegt
Schritt 3: Konfigurieren, fertig … soweit die Theorie …
Das erste große Problem taucht auf, beim Versuch die Lizenz zu aktivieren. Das System meldet, dass der Lizenzkey nicht zur Installation passt. Toll – und nu? Ich denke, Datacenter heißt „Server all you can eat“ …
Nach Recherche im Netz die Erkenntnis, dass über das ISO nur eine Testlizenz installiert wird, die per Kommando in eine echte Lizenz umgewandelt werden muss, damit der Key wieder passt:
DISM /online /Set-Edition:ServerDatacenter /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula
Das nächste Problem meldet sich beim Hinzufügen der WSUS-Rolle. Das System gibt bekannt, dass die Installation fehlgeschlagen ist, weil der Server neugestartet werden muss. Ja – verdammt – dann starte doch neu! Das Häkchen „bei Bedarf neu starten“ ist doch eh gesetzt.
Neustarten bringt – man ahnt es schon – auch beim wiederholten Installationsversuch wirklich rein gar nichts.
Langer Rede/langer Recherche kurzer Sinn: beim Installieren der internen Datenbank WID fehlen Rechte, die man in der GPO definieren muss, die für diesen Server zuständig ist (z.B. also die DefaultDomainPolicy). „Anmelden als Dienst“ in der lokalen Sicherheitsrichtlinie für „NT SERVICE\ALL SERVICES“ zuweisen (kleiner Trick: den Benutzer kann man nicht auswählen, sondern man muss den Text in das Suchfeld hineinschreiben) und schon klappt die Installation der WSUS-Rolle und aller weiteren zugehörigen Rollen/Features reibungslos.
Nächstes Problem taucht auf bei der sogenannten Nachkonfiguration des neuen WSUS. Das System meldet mit wortreichen Einträgen im Logfile, dass diverse „Fehler bei der Anforderung mit http-Status 503“ stattfinden und die WSUS-Dienste deshalb nicht gestartet und konfiguriert werden können.
Gute Güte – was denn noch alles, denkt man sich ….früher war wirklich alles einfacher!
Die Lösung für dieses Problem verbirgt sich im IIS: man muss die Site „WSUS-Verwaltung“ löschen und anschließend die Nachkonfiguration erneut starten. Die Site wird automatisch neu angelegt und alles funktioniert reibungslos. Nach meiner Theorie wurde die Site bereits beim ersten – fehlgeschlagenen – Installationsversuch angelegt und passt dann später irgendwie nicht mehr zu der dann erfolgreichen Installation.
Jetzt muss man nur noch die Partition für den WSUS in hinreichender Größe anlegen (für Exchange 2016, SQL 2016, Server2012R2 und Windows 10 braucht man schon nach kurzer Zeit flockige 450 GB) und schon ganz es losgehen!