Dienstag, 3. September 2013

Windows Update: Fehler "0x80072ee2" unter Windows 8 - Dienst reagiert nicht mehr

In Windows 8 gibt es ein Verhalten, dass den Windows Update Dienst (wuauserv) zum Absturz bringen kann.

Für den wuauserv lässt sich ein Proxy-Server konfigurieren.
Standardmäßig ist jedoch kein Proxy für den Dienst gesetzt.

Die wuauserv Proxy-Einstellung:
Die Konfiguration kann mit diesem Befehl angezeigt werden:
 

netsh winhttp show proxy

Im Normalfall erscheint dann diese Config:


 Current WinHTTP proxy settings:

    Direct access (no proxy server).


Sucht ihr online nach Updates, werden die Proxy-Einstellungen des Internet Explorers verwendet.



Wenn ihr einen WSUS-Server konfiguriert habt, wird jedoch die Einstellung die
mittels "netsh winhttp ..." angezeigt wird, verwendet.

Fehler unter Windows 8:
Ist kein Proxy konfiguriert unter Windows 8 und man besitzt jedoch keine direkte Internetverbindung, so kann es passieren, dass die Suche nach Windows Updates nicht abgeschlossen werden kann:

Im Logfile "C:\Windows\WindowsUpdate.log" erscheinen diese Einträge:

2013-09-03    07:58:21:157     900    e30    Misc    WARNING: Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <None>
2013-09-03    07:58:21:157     900    e30    Misc    WARNING: Send request failed, hr:0x80072ee2
2013-09-03    07:58:21:157     900    e30    Misc    WARNING: WinHttp: SendRequestUsingProxy failed for <http://ds.download.windowsupdate.com/w8/2/windowsupdate/redir/wuredir.cab>. error 0x80072ee2
2013-09-03    07:58:21:157     900    e30    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072ee2
2013-09-03    07:58:21:157     900    e30    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072ee2
2013-09-03    07:58:21:157     900    e30    Misc    WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072ee2
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: Send failed with hr = 80072ee2.
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <None>
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: Send request failed, hr:0x80072ee2
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: WinHttp: SendRequestUsingProxy failed for <http://ds.download.windowsupdate.com/w8/2/windowsupdate/redir/wuredir.cab>. error 0x80072ee2
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072ee2
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072ee2
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072ee2
2013-09-03    07:59:03:198     900    e30    Misc    WARNING: DownloadFileInternal failed for http://ds.download.windowsupdate.com/w8/2/windowsupdate/redir/wuredir.cab: error 0x80072ee2
2013-09-03    07:59:24:558     900    e30    Misc    WARNING: Send failed with hr = 80072ee2.


Bei der angegebenen Datei (http://ds.download.windowsupdate.com/w8/2/windowsupdate/redir/wuredir.cab) handelt es sich um ein File, dass für den Windows-Store benötigt wird.

By design:

Nach ca. 8 Wochen Kontakt mit dem Microsoft Support lautet die finale Aussage:
By Design. D.h. "das ist einfach so".
Die Case Nummer hierzu lautet: 113070910573485

Workaround?
Mit der Fehlermeldung im Logfile könnte man sicherlich leben.
Dass jedoch sich teilweise der Windows Update Dienst verabschiedet, ist sehr unschön (und zumdem ein Sicherheitsrisiko).

Um die Funktion des Dienstes zu gewährleisten, gibt es also zwei sinnvolle Lösungen:
  1. Einen Proxy-Server mittels "netsh winhttp" konfigurieren und den Download ermöglichen + Eine Proxyausname für den WSUS-Server definieren.
  2. Einen Proxy-Server mittels "netsh winhttp" konfigurieren und den Download am Proxy-Server sperren + Eine Proxyausname für den WSUS-Server definieren.
Gesetzt werden kann dieser Proxy mit diesen Befehlen:

netsh winhttp set proxy myproxy:80 "*.domain.intern"
(es kann natürlich auch nur explizit der WSUS-Server ausgeschlossen werden) 
oder
netsh winhttp import proxy source =ie  

 Geht das nicht eleganter?
Wir sind ja hier im GPO-Blog. Deshalb lautet die Antwort: Ja :-)

Diese Einstellung wird in einem Registry-Binary gespeichert.
Dieser befindet sich unter HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections und nennt sich "WinHttpSettings".

Ihr könnt also Group Policy Preferences Registry benutzen um diesen Schlüssel zu setzen:



Jetzt noch eine Zielgruppenadressierung setzen und fertig:



Kommentare:

  1. Auch ich habe den selben Fehler in meiner Umgebung festgestellt - Da ich das Problem jedoch eher auf meiner Seite vermutet habe, habe ich fast alles erdenklich unternommen (manche Foreneinträge raten zur WSUS-Neuinstallatoin: hat nicht geholfen; einspielen von Patches: ebenfalls kein Erfolg, Clientneuinstallation: erfolglos, Zertifikate anpassen: kein Erfolg, ...) - So habe ich mich zwei Nächte um die Ohren geschlagen und dann letzte Woche bei Microsoft ein Ticket eröffnet.

    Heute kam die Antwort: ein Bug, der (hoffentlich) demnächst behoben wird. - Also warten wir mal ab.
    Danke jedenfalls für die Workarroundempfehlungen.

    AntwortenLöschen
  2. Hallo Daniel,

    mir ging es änlich. Irgendwann sollte ich dann unseren WSUS, an dem ca. 2000 Clients erfolgreich Updates ziehen, neuinstallieren. Das ging mir dann zuweit. Es gibt zwar schon ein paar Situationen bei denen der Windows Update Client dann als Notlösung trotzdem online nach Updates sucht, aber das erschien mir in diesem Falle etwas abwegig.
    Der Gag ist, schaut man sich einmal die .CAB Datei an, die er herunterladen will, dann steht dort drin:



    Für den genannten Registryschlüssel gibt es auch eine Policy (die zunächst einmal genau passend klingt). Funktioniert aber auch nicht.

    http://gpsearch.azurewebsites.net/#8215

    bzw. (von der Beschreibung her auch ggf. passend)

    http://gpsearch.azurewebsites.net/#8217

    AntwortenLöschen
  3. Leider fehl oben das XML Coding.
    Deshalb hier ein Ausschnitt:

    NotRegValueDwordDetect SubKey="Software\Policies\Microsoft\WindowsStore" Value="RemoveWindowsStore"

    AntwortenLöschen
  4. Hallo Matthias,

    ja, die Hürde der Neuinstallation des WSUS-Servers bin ich noch gegangen, da ich die Befürchtung hatte, dass die Paket-Checksummen, bedingt durch anfangs fehlende Windows/WSUS-Patche (u. a. KB2734608) teilweise falsch wären und wir den WSUS-Server auch noch von einem anderen repliziert hatten.

    Den Inhalt der wuredir.cab habe ich mir auch mal angesehen. Dennoch jeglichen Gedanken dahingehend bei Seite gelegt, da der Windows Update Agent ja das File durch den fehlenden Internetconnect gar nicht bekommt und ihm somit gar nicht bekannt ist, was darin steht.

    Wenn ich den Inhalt richtig interpretiere, geht es hier um die Updatesuche für den Windows Store, die nur durchgeführt wird, wenn dieser auch enabled ist.
    Der Windows Update Agent lädt sich somit immer die wuredir.cab herunter (kann das jedoch in unserem Fall nicht) und prüft die darin enthaltene Bedingung, ist diese wahr, wird die Prüf-URL des WUA umgeleitet und weiter geprüft. (Da das 'Bedingungsfile' jedoch schon gar nicht herunter geladen werden kann, hilft der Registry-Key meines Erachtens auch nicht.) - So zumindest erkläre ich mir das Verhalten ;-)

    Da der Windows Store noch nicht ohne Online-Anbindung funktionier, hat vermutlich auch niemand an die Windows Update Abhängigkeiten gedacht.

    Ich hoffe du hast deinen Microsoft-Case ohne Kosten archivieren lassen können?! - Wenn nein, lass es mich wissen, dann schicke ich dir meine Case-ID.

    Grüße
    Daniel

    AntwortenLöschen
  5. Hallo Daniel,

    deine Erklärung klingt schlüssig. Dennoch, ich habe aufgehört mir über solche Sachen Gedanken zu machen, wenn das MS nicht tut, dann muss ich das auch nicht :-)

    Ja, der Case wurde archiviert.
    Kostenlos war er ohnehin, da wir überhaupt keinen Supportvertrag mit MS haben.

    Den Support habe ich auf relativ früh auf den Windows-Store hingewiesen, zu diesem Zeitpunkt hieß es aber "Nein, dass kann nicht sein". Von wegen.

    AntwortenLöschen
  6. PS:
    Schauen wir mal, wie das in Windows 8.1 so ist...

    AntwortenLöschen
  7. Hallo Matthias, hallo zusammen,

    auf deine letzte Frage hin, wie das in mit der neuesten Windowsgeneration aussieht, kann ich positives berichten. In meiner Umgebung, in der einige Windows Server 2012 R2 laufen, tritt das Phänomen nicht mehr auf. Auch die Windows 8.1 Clients zeigen kein derartiges Verhalten mehr. Microsoft hat das Thema somit wohl im Griff.
    Ob und wann es jedoch bei W8 / W2K12 gefixt wird? - Mal sehen.

    Grüße
    Daniel

    AntwortenLöschen
  8. Endlich mal gute Nachrichten.
    Danke für die Info!

    AntwortenLöschen
  9. hallo, ich habe dasselbe Problem, auch mit win 8.1, vorhin habe ich ein update gemacht und neugestartet und jetzt läuft es wieder nicht....deine lösung habe ich auch probiert, aber wenn ich dieses winhttpsettings öffne kommt nur irgendwas in binärsprache....

    AntwortenLöschen
  10. Hallo,

    der Wert wird binär gespeichert, dass ist korrekt.
    Was passiert wenn du den Proxy mittels netsh winhttp set proxy myproxy:80 "*.domain.intern" setzt?
    Was steht in deinem WindowsUpdate.log (C:\Windows\)

    AntwortenLöschen
  11. also bei mir tritt der exakte Fehler auch bei Win7x64 SP1 auf, das ist also wohl kein spezielles W8 Problem. Wundert mich dass andere damit keine Problem haben.? Gruss, SR

    AntwortenLöschen