WSUS Server auf Server 2016 – der lange Weg zum Update
Kürzlich habe ich ein schon überfälliges Update eines WSUS-Servers von Server 2012 auf 2016 gemacht.
Alles neu macht er Mai, dachte ich, also keine Migration, sondern Neuinstallation.
Mal „Kurz“ ein OS-Template hochziehen und die WSUS-Rolle drauf – Dachte ich zumindest.
Ein Windows Server 2016 Image war schnell Deployed auch die WSUS-Rolle ließ sich schnell installieren.
Die „Nachinstallationsarbeiten“ zogen sich extrem, was unter anderem auch daran liegt und lag, dass der Initiale Sync (der sich ja nicht vermeiden lässt) über eine halbe Stunde gebraucht hat. Mit der Internet-Anbindung hat das nichts zu tun, eher hat sich das System gelangweilt, ein Timeout von irgendetwas hat mich dann schließlich erlöst.
Interessant wird es dann, wenn die Clients (ca 600 Stück in verschiedenen Standorten) sich über Port 80 an den WSUS melden. GPOs umziehen bzw. Registryeinträge umbauen ist in diesem Fall keine Option gewesen. Somit WSUS auf Port 80.
Hmm… „WSUSutil usecustomwebsite false“ kennt man ja noch von Früher, IIS sieht danach auch noch „OK“ aus, Bindings sind korrekt umgebaut.
Wie erwartet melden sich die Clients auch am WSUS, nur will kein Stratusupdate klappen.
Auf den Windows 10 Clients, wo manuell nach Updates gesucht wurde, kommt die Fehlermeldung
„Fehler bei der Suche nach Updates: 0x8024401F.“
Die Suchmaschinen sind voll davon, nur leider nichts brauchbares…
Nach langem suchen und Probieren (Ich war schon fast verzweifelt), konnte aber ein Fehler bei unserem Netzwerk ausgeschlossen werden.
Irgendwie schein es, dass der IIS hier nicht mitspielt.. 🙁 Aber die Einstellungen waren korrekt…
Interessanterweise hat die ganze Geschichte super funktioniert, solange ich den WSUS und somit auch den IIS auf Port 8530 belassen habe, die Test-Clients meldeten sich ohne Probleme und haben auch ihren Statusreport abgegeben (Juhuu!!)
-> Irgendwie scheint es, Microsoft unterbindet das WSUS-Publishing auf Port 80, hat aber die Funktion in WSUSutil.exe nicht gelöscht/deaktiviert, sodass das Tool munter die Ports umbiegt, aber nur halt leider nicht alles.
OK, was tun? als Versuch habe ich das Binding der „WSUS Administration“ im IIS um den Port 80 erweitert und Voila! Clients melden sich (Happy)
Leider noch nicht genug, bei 600 Clients, die seit 3 Tagen hungrig auf Updates warten und auf den neuen WSUS einprügeln kommt doch einiges an traffic und Load auf den IIS und die Datenbank. Jetzt stürzte regelmäßig die „WSUSPool“-Applikation im IIS ab. Kurzer check der Eventlogs half auch nicht unbedingt weiter
„Application pool ‚WsusPool‘ is being automatically disabled due to a series of failures in the process(es) serving that application pool.“
-> Na Super, wusste ich ja auch schon 😉 ein „IISreset“ half nur bedingt, hielt nicht unbedingt lange, dann stand der ganze IIS schon wieder.
Bei genauerem Hinsehen in den „Advanced Settings“ der App im IIS fiel mir der Schalter „Private Memory Limit (KB)“ auf, der auf ‚1843200‘ stand.
OK, bisschen „wenig“, dachte ich mir. Kurzerhand auf ‚4000000‘ eingestellt, IIS neu gestartet und gewartet… Nichts passiert, alles läuft, nichts hängt, Clients happy, ich happy!! 🙂
-> Auch hier könnte Microsoft ein bisschen an der Schraube drehen und die Default-Werte etwas nach oben korrigieren. Das abschmieren des App-Pools kommt sicherlich auch bei weitaus kleineren Installationen vor, und wir müssen in der heutigen Zeit bestimmt nicht mehr um jedes MB an Arbeitsspeicher kämpfen.
Grüße!
Jörg Strobel