Kleinere #WSUS Unfälle in 04 und 05/2016 mit #KB3148812 #KB3159706 auf #Server2012 + Fehler 80244007, 803d000d, 80244019

Menu:/Kleinere #WSUS Unfälle in 04 und 05/2016 mit #KB3148812 #KB3159706 auf #Server2012 + Fehler 80244007, 803d000d, 80244019

Kleinere #WSUS Unfälle in 04 und 05/2016 mit #KB3148812 #KB3159706 auf #Server2012 + Fehler 80244007, 803d000d, 80244019

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:

Bildschirmfoto 2016-05-15 um 23.38.44

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:

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:

Das schaut wie folgt aus:
Bildschirmfoto 2016-05-15 um 22.53.08

Weiterhin solltet Ihr das Feature „Http-Aktivierung“ für .Net FX 4.5 WCF Dienste bereitstellen:Bildschirmfoto 2016-05-15 um 23.28.37

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:

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

Anschließend müsst Ihr die Execution-Policy wieder auf Restricted setzen:

Bildschirmfoto 2016-05-17 um 14.27.20

Es dauert ein wenig, klappt aber ganz gut. Das war’s soweit von mir.

By | 2016-05-17T14:29:01+00:00 15.05.2016|Allgemein|Kommentare deaktiviert für Kleinere #WSUS Unfälle in 04 und 05/2016 mit #KB3148812 #KB3159706 auf #Server2012 + Fehler 80244007, 803d000d, 80244019

About the Author:

John Lose
John Lose ist Informationstechnologe und Datenreisender. Manche mögen ihn als "Aluhut-Träger" bezeichnen, denn er mag nur kleine Rechenzentren, die er selbst kennt. Public Clouds kommen für Ihn höchstens für Webseiten in Frage. John ist Katzenliebhaber, hat aber keine Katze, fährt gerne nach Südfrankreich und hört Tech-House. Mehr über John Lose erfährst Du in seiner Vita.  Wenn Dir dieser Beitrag gefallen hat, so kannst Du auch Danke sagen, wenn Du möchtest:  >> Dankeschön <<.