Es ist mal wieder soweit, ein Ei aus Redmond ist gelegt. Ein ziemlich dickes sogar. Mit Verlaub, es nervt, Microsoft. Anrufe und Mails hatte ich zuletzt unisolo, Inhalte wie folgt: „WSUS geht nicht mehr“. Ich war aber nicht da. Ich hatte Urlaub. Muss auch mal sein. Deswegen kommt meine Auflösung ein wenig später. Zu spät für viele von Euch. Und ja, nicht alle lesen die Begleitpapiere. Ist da ein Update, spielt Ihr es auch ein und ich werde einen Teufel tun, Euch deswegen einen Vorwurf zu machen. Und das Update kam nicht optional sondern recommended. Unerwartet für viele. Die Postinstallation, welche zum „fachgerechten“ Zerlegen der SUSDB führt, haben die meisten von Euch gottseidank nicht durchgeführt. Solltet Ihr W10-Clients haben, ist’s jedoch notwendig. Microsoft hat’s verbockt. Mal wieder. Und zwar gründlich.
Update vom 16.05., bzw. weiterer Hinweis: Die Variante SSL/TLS (Technet-Bezug, verlinkt weiter unten) funktioniert für die meisten nicht, bei mir jedoch schon. Deswegen kann ich es nicht nachstellen. Hinweise und Tipps werden dankbar angenommen. Einige meiner Kunden kommen über den Fehler 80244007 auf Clientseite nicht hinaus. Der Workaround (Löschen von Softwaredistribution) läuft nicht. Die originale Web.config sollte wenigstens gesichert werden. Ungerne, weil riskant, rate ich entweder dazu, auf TLS zu verzichten oder auf Windows 10, zu letzterem Produkt kennt Ihr meine Meinung hinreichend.
Update 2 vom 17.05., ich habe noch einmal Informationen hinzugefügt, in jenem das versehentlich installierte GWX-App von Microsoft wieder entfernt werden kann, sofern Ihr manuell Updates direkt von Microsoft heruntergeladen habt.
Ich lasse den Hinweis auf den Technet-Artikel stehen, habe jedoch keine Lösung.
Ein beispielhaftes Nagios einer Kundenumgebung sah wie folgt aus:
Ziemlich nervig. Kein Update kommt mehr durch, die Informationen sind für den Kundenadministrator schwer zu finden. Hierzu gab es leider fehlerhafte Informationen von Microsoft, jene – sofern angewendet – Deinen WSUS mit KB3148812 komplett zerlegten.
Teil 1: Kaputtes KB3148812 entfernen
Solltet Ihr KB3148812 drauf haben, gibt es folgende Entscheidungsroutine:
Habt Ihr die Servicing-Postinstallationsroutine wie von Microsoft angefordert bereits durchgeführt, könnt Ihr den WSUS killen, sofern ihr keine Backups von der Hütte habt. Er ist nicht mehr zu gebrauchen. Damit endet der Artikel. Sorry.
Habt Ihr die Servicing Postinstallationsroutine nicht durchgeführt, so entfernt mit einer administrativen Dosbox zunächst KB3148812:
wusa /uninstall /kb:3148812
Danach kann es mit Teil 2 weiter gehen:
Teil 2: Ersetzendes KB3159706 anwenden, Postinstallationsroutine umsetzen
Ich habe für 3159706 kein manuelles Update gefunden. Musst Du über Microsoft Update Online anwenden, findest Du in „Optionale Updates“. Das Ding ist wohl für Windows 10 da. Es führt kein Weg drumherum. Außerdem braucht es WCF Bestandteile von .Net 4.5. Die Beschreibung ist äußerst suboptimal, die Deutsche solltet Ihr links liegen lassen, sie ist fehlerhaft. Solltet Ihr kein SSL anbieten, so reicht nachfolgendes Tutorial aus:
2.1 Zunächst müsstet Ihr die Postinstallationsroutine in einem administrativen Dosprompt starten:
"C:\Program Files\Update Services\Tools\wsusutil.exe" postinstall /servicing
Das schaut wie folgt aus:
Weiterhin solltet Ihr das Feature „Http-Aktivierung“ für .Net FX 4.5 WCF Dienste bereitstellen:
Anschließend pustet Ihr die Hütte einmal durch und WSUS sollte wieder laufen.
2.2 Sollte Euer WSUS auf TLS/SSL hören, so müsst Ihr zwingend die Hinweise zu TLS/SSL auf diesem englischsprachigen Dokument anwenden: Link.
Hinweis: Was in diesem Artikel leider auch nicht steht: Es macht im übrigen eher Sinn, W3SVC und den Windows Update-Dienst vor Anwendung des Artikels zu beenden. Den Windows Editor solltet ihr mit administrativen Rechten starten.
GWX aus Versehen bereitgestellt
Einige hatten manuell Windows Update durchgeführt und damit auch das absolut nervende, bandbreitenverschlingende GWX-Werbe-Tool von Microsoft für Windows 10 wieder auf der Hütte. Heise hat dazu ein ziemlich cooles PS-Script erstellt, mit jenem Ihr die GWX-App loswerdet und die Registryeinstellungen, jene Ihr auch per Policy (Link) hättet machen können, am lokalen Client automatisch definieren könnt.
Das PS-Script von Heise gibt es hier: Link
Anschließend startet Ihr die Powershell mit administrativen Rechten. Damit Ihr das Script ausführen könnt, müsst Ihr das in der Powershell zunächst erlauben:
Set-ExecutionPolicy Unrestricted
Ggf. ist es notwendig, das Script in der Sicherheit zuzulassen, dazu müsst Ihr mit einem Rechtsklick auf das PS-Script klicken, anschließend auf Zulassen klicken.
Das Tool könnt Ihr starten mit
.\Block-GWXUpdate.ps1
Anschließend müsst Ihr die Execution-Policy wieder auf Restricted setzen:
Set-ExecutionPolicy Restricted
Es dauert ein wenig, klappt aber ganz gut. Das war’s soweit von mir.