none
Fehler 0x800705b4 bei jedem Windows Server Update

    Frage

  • Hallo allerseits,

    ich hab mittlerweile bei mehreren Server 2016 Systemen das Problem, dass die Installation der kumulativen Updates mit der Fehlermeldung 0x800705b4 fehlschlägt, wenn diese vom WSUS oder auch von WU gezogen werden. Bisher waren es einige Systeme in der Testumgebung, mittlerweile hab ich es auch schon bei produktiven Systemen gesehen. 

    Eine manuelle Installation des über den Update Catalog heruntergeladenen Updates funktioniert. Ist aber halt kein Dauerzustand, Updates immer manuell zu installieren. 

    Das Problem taucht sowohl bei physischen als auch bei virtuellen Maschinen auf, gerne allerdings wohl bei Systemen, die nicht so massig Performance haben

    Beispielsystem 1: Intel NUC5CPYH, 8 GB Ram (6 GB frei), Intel SSD. Wird als reiner DC ohne jegliche weitere Software im Testnetz betrieben. Server 2016 Standard, kein Virenscanner, keine sonstigen Installationen. Als Rollen nur der DC installiert.

    Beispielsystem 2: HP Microserver Gen8, Xeon CPU, 32 GB, ESXi 6.0, darauf zwei VMs mit Server 2016 Standard, verschiedene Rollen installiert, die VMs werden als DC und Fileserver in kleinen Außenstandorten genutzt. 

    Was bereits erfolglos versucht wurde:

    - Neustart vor der Installation
    - Zurücksetzen der Windows Update Funktion und Löschen von CatRoot2 und Softwaredistribution
    - der integrierte Windows Defender wurde deaktiviert

    Im Netz finden sich mehrere Berichte, wo als Lösung immer nur "manuell installieren" kam. Das ist leider keine Lösung. Hat jemand eine tatsächliche Lösung?

    Danke und Grüße, 

    Ingo


    cu, Ingo

    Mittwoch, 14. Februar 2018 20:46

Alle Antworten

  • Am 14.02.2018 schrieb Ingo Böttcher [MVP]:

    ich hab mittlerweile bei mehreren Server 2016 Systemen das Problem, dass die Installation der kumulativen Updates mit der Fehlermeldung 0x800705b4 fehlschlägt, wenn diese vom WSUS oder auch von WU gezogen werden. Bisher waren es einige Systeme in der Testumgebung, mittlerweile hab ich es auch schon bei produktiven Systemen gesehen. 

    Ist es wirklich die Installation oder der Download? Wie viele Einträge
    vom WSUS hat dein Server? Zwei oder drei? Es sollten drei sein. AFAIR
    hatten wir am Anfang auch diese Fehler, den dritten Eintrag via GPO
    setzen, booten, schon hatte alles geklappt.

    HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate
    UpdateServiceUrlAlternate
    http://DeinWSUS:8530 eintragen.

    Servus
    Winfried


    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Donnerstag, 15. Februar 2018 05:52
  • Danke für den Tipp. Ich habe es grad mal kontrolliert: es sind momentan zwei Einträge für den WSUS im Test-Netz in der GPO. Ich werde den dritten Eintrag mal dazu packen. Im Produktiv-Netz sind allerdings eh schon alle drei Einträge gesetzt. 

    Allerdings gibt es ja auch genauso in beiden Umgebungen Server, die mit den aktuellen Einstellungen problemlos updaten können. Sollte sich der Eintrag nicht auf alle 2016er Server gleich auswirken? 


    cu, Ingo

    Donnerstag, 15. Februar 2018 18:29
  • Am 15.02.2018 schrieb Ingo Böttcher [MVP]:

    Danke für den Tipp. Ich habe es grad mal kontrolliert: es sind momentan zwei Einträge für den WSUS im Test-Netz in der GPO. Ich werde den dritten Eintrag mal dazu packen. Im Produktiv-Netz sind allerdings eh schon alle drei Einträge gesetzt. 

    Sind die produktiven Server alle auf der gleichen Build?

    Allerdings gibt es ja auch genauso in beiden Umgebungen Server, die mit den aktuellen Einstellungen problemlos updaten können. Sollte sich der Eintrag nicht auf alle 2016er Server gleich auswirken?

    Sollte ja, prüf doch mal die Build der Server.

    Servus
    Winfried


    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Donnerstag, 15. Februar 2018 21:38
  • Ja. Die produktiven Server sind alle auf dem Stand des Januar 2018 Updates. Die Testserver waren es bis gestern auch. Von fünf Maschinen im Testnetz haben diesmal drei das Update problemlos eingespielt, zwei liefen in die genannte Fehlermeldung.

    Das Problem an sich taucht aber schon länger auf. Ich habe halt im Testnetz in den letzten Monaten die Updates immer auf den betroffenen Maschinen manuell installiert und gehofft, dass es nur ein Problem mit dem jeweiligen Update wäre. Ist es aber demnach wohl nicht. 

    Edit: eine der Maschinen (VM unter Hyper-V) wurde testweise vor etwa zwei Monaten neu installiert. Änderte an der Sache wenig. 


    cu, Ingo


    Donnerstag, 15. Februar 2018 21:43
  • Am 15.02.2018 schrieb Ingo Böttcher [MVP]:

    Edit: eine der Maschinen (VM unter Hyper-V) wurde testweise vor etwa zwei Monaten neu installiert. Änderte an der Sache wenig.

    Kannst Du die komplette Server GPO Einstellungen hier posten? Ich kann
    sie dann mit unseren vergleichen, evtl. findet man etwas.

    Servus
    Winfried


    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Freitag, 16. Februar 2018 05:57
  • Ich glaube zwar, dass wir da auf dem falschen Weg sind, aber klar, kann ich gerne machen. Wie gesagt, ich würde bei einer falschen Einstellung erwarten, das Problem auf allen Systemen zu sehen. Es ist aber nur auf den langsameren Systemen vorhanden.

    WSUS

    Daten ermittelt am: 16.02.2018 21:11:50
    Alle ausblenden
    AllgemeinAusblenden
    DetailsAusblenden
    Domäne example.com
    Besitzer EXAMPLE\Domänen-Admins
    Erstellt 01.02.2008 22:52:08
    Geändert 15.02.2018 19:26:08
    Benutzerrevisionen 0 (AD), 0 (SYSVOL)
    Computerrevisionen 17 (AD), 17 (SYSVOL)
    Eindeutige ID {4881E15A-3B87-4076-A60E-B0FEDE8769FF}
    GPO-Status Benutzereinstellungen deaktiviert
    VerknüpfungenAusblenden
    Standort Erzwungen Verknüpfungsstatus Pfad
    Alle Computer Nein Aktiviert example.com/Alle Computer
    Domain Controllers Nein Aktiviert example.com/Domain Controllers
    Server Nein Aktiviert example.com/Server

    Die Liste enthält Verknüpfungen zur Domäne des Gruppenrichtlinienobjekts.
    SicherheitsfilterungAusblenden
    Die Einstellungen dieses Gruppenrichtlinienobjekts können nur auf folgenden Gruppen, Benutzer und Computer angewendet werden:
    Name
    NT-AUTORITÄT\Authentifizierte Benutzer
    DelegierungAusblenden
    Folgende Gruppen und Benutzer haben die angegebene Berechtigung für das Gruppenrichtlinienobjekt
    Name Zulässige Berechtigungen Geerbt
    NETPARTY\Domänen-Admins Einstellungen bearbeiten, löschen, Sicherheit ändern Nein
    NETPARTY\Organisations-Admins Einstellungen bearbeiten, löschen, Sicherheit ändern Nein
    NT-AUTORITÄT\Authentifizierte Benutzer Lesen (durch Sicherheitsfilterung) Nein
    NT-AUTORITÄT\DOMÄNENCONTROLLER DER ORGANISATION Lesen Nein
    NT-AUTORITÄT\SYSTEM Einstellungen bearbeiten, löschen, Sicherheit ändern Nein
    Computerkonfiguration (Aktiviert)Ausblenden
    RichtlinienAusblenden
    Administrative VorlagenAusblenden
    Richtliniendefinitionen (ADMX-Dateien) wurden aus dem zentralen Speicher abgerufen.
    Windows-Komponenten/ÜbermittlungsoptimierungAusblenden
    Richtlinie Einstellung Kommentar
    Downloadmodus Aktiviert
    Downloadmodus: Gruppe (2)
    Windows-Komponenten/Windows UpdateAusblenden
    Richtlinie Einstellung Kommentar
    Automatische Updates konfigurieren Aktiviert
    Automatische Updates konfigurieren: 4 - Autom. Herunterladen und laut Zeitplan installieren
    Die folgenden Einstellungen sind nur erforderlich und anwendbar, wenn die Option 4 ausgewählt wurde.
    Während automatischer Wartung installieren Aktiviert
    Geplanter Installationstag: 0 - Täglich
    Geplante Installationszeit: 03:00
    Wenn Sie für den geplanten Installationstag "4 - Autom. herunterladen und laut Zeitplan installieren" ausgewählt und einen Zeitplan angegeben haben, können Sie mithilfe der folgenden Optionen Updates auch einmal pro Woche, alle zwei Wochen oder einmal pro Monat suchen lassen:
    Jede Woche  
    Erste Woche des Monats  
    Zweite Woche des Monats  
    Dritte Woche des Monats  
    Vierte Woche des Monats  
    Updates für andere Microsoft-Produkte installieren Aktiviert
    Richtlinie Einstellung Kommentar
    Automatische Updates sofort installieren Aktiviert
    Empfohlene Updates über automatische Updates aktivieren Aktiviert
    Erneut zu einem Neustart für geplante Installationen auffordern Deaktiviert
    Internen Pfad für den Microsoft Updatedienst angeben Aktiviert
    Interner Updatedienst zum Ermitteln von Updates: https://srvapp1.example.com:8531
    Intranetserver für die Statistik: https://srvapp1.example.com:8531
    Alternativen Downloadserver festlegen: https://srvapp1.example.com:8531
    (Beispiel: http://IntranetUpd01)
    Dateien ohne URL in den Metadaten herunterladen, wenn ein alternativer Downloadserver festgelegt ist Deaktiviert
    Richtlinie Einstellung Kommentar
    Keinen automatischen Neustart für geplante Installationen automatischer Updates durchführen, wenn Benutzer angemeldet sind Aktiviert
    Signierte Updates aus einem Intranetspeicherort für Microsoft-Updatedienste zulassen Aktiviert
    Softwarebenachrichtigungen aktivieren Aktiviert
    Suchhäufigkeit für automatische Updates Aktiviert
    In folgenden Abständen (Stunden)
    nach Updates suchen: 1

    cu, Ingo

    Freitag, 16. Februar 2018 20:15
  • Am 16.02.2018 schrieb Ingo Böttcher [MVP]:

    Ich glaube zwar, dass wir da auf dem falschen Weg sind, aber klar, kann ich gerne machen. Wie gesagt, ich würde bei einer falschen Einstellung erwarten, das Problem auf allen Systemen zu sehen. Es ist aber nur auf den langsameren Systemen vorhanden.

    So ganz glaub ich nicht, dass wir auf dem falschen Weg sind. Der
    Unterschied ist, wir benutzen den BITS komplett von den
    Clients/Servern von/zum WSUS.

    http://gpsearch.azurewebsites.net/#11083
    Das wäre dann die Option 100 bei dir. Du kannst das ja für ein paar
    Testserver umstellen und beobachten, wie es sich verhält. Wobei ich
    nach der Umstellung und nachdem der Client/Server sich das GPO so
    gezogen hat, erneut Softwaredistribution leeren würde.

    Zusätzlich wird in diesem Thread auf einen sauberen Neustart
    verwiesen, anschauen kann sicherlich nicht schaden.
    https://partnersupport.microsoft.com/en-us/par_servplat/forum/par_winserv/server-2016-std-windows-update-0x800705b4/28df8b5a-7d6d-4bbb-abb8-da3f1556a2dd?auth=1

    Servus
    Winfried


    WSUS Package Publisher: http://wsuspackagepublisher.codeplex.com/
    HowTos zum WSUS Package Publisher http://www.wsus.de/wpp
    GPO's: http://www.gruppenrichtlinien.de
    NNTP-Bridge für MS-Foren: http://communitybridge.codeplex.com/

    Samstag, 17. Februar 2018 09:15
  • hast du den RegKey für QualityCom drinnen?

    https://support.microsoft.com/eu-es/help/4072699/january-3-2018-windows-security-updates-and-antivirus-software

    ansonsten installiere bitte das letzte Update 2018-02 einmal manuell.  


    Chris

    Sonntag, 18. Februar 2018 13:48
  • Ja, habe ich. Wird per GPO verteilt. 

    Ich installiere die letzten Monate schon immer manuell. Langsam sollte es mal wieder automatisch gehen. ;-) 


    cu, Ingo

    Sonntag, 18. Februar 2018 13:53
  • windows update und BITS Service stoppen, c:windows Softwaredistribution umbenennen, Dienste wieder starten

    Chris

    Sonntag, 18. Februar 2018 15:48
  • Hatte ich bereits gemacht, wie bereits im Ausgangsposting geschrieben. 

    cu, Ingo

    Sonntag, 18. Februar 2018 15:49
  • Hallo Ingo,

    ich bin Admin für 2 Domänen(Standorte). An beiden Standorten werden Windows Server 2012R2 und Windows Server 2016 als phys. Hyper-V Hosts und auch als virtuelle Maschinen betrieben.

    Der gegenwärtige Ist-Zustand: Auf allen(!) phys.(!) Windows 2016 Servern mit der Hyper-V-Rolle an beiden Standorten funktionieren die kumulativen Updates nicht. Die Defender-Updates aber schon.

    Anders gesagt: Auf allen(phys. + virt.) Windows 2012R2 Servern und allen virtuellen Windows 2016 Servern funktionieren alle Windows-Updates.

    Ein phys. Windows 2016 Server läuft als Datacenter ohne die Hyper-V-Rolle - auch hier funktionieren die Windows-Updates.

    Fazit: Mein Verdacht ist die Hyper-V-Rolle, ev. ein Netzwerk-Kommunikationsproblem (virtuelle Switches)

    Ich lade die Updates seit ca. 6 Monaten vom Update-Katalog runter und installiere sie manuell.

    Das kostet Zeit und Geld und die Hoffnung stirbt zuletzt, dass Microsoft das in den Griff bekommt.

    Bg, Mathias

    Mittwoch, 21. März 2018 08:38
  • Danke für die Rückmeldung, aber die Beobachtung kann ich nicht teilen.

    Der Timeout-Fehler tritt hier auf (langsameren) physischen und virtuellen Servern auf, die kein Hyper-V-Host sind.

    Auf dem Hyper-V-Host selber taucht er hingegen nicht auf. Zumindest ich sehe hier keinen Zusammenhang zu Hyper-V.


    cu, Ingo

    Mittwoch, 21. März 2018 23:07
  • Hallo Ingo,

    die von Dir beschriebenen Fehler beim Updateservice für Windows Server 2016 Systeme scheint es sich um keinen Einzelfall zu handeln. Auch wir sind hier betroffen, und zwar ebenfalls mit mehreren Server 2016 Maschinen die unter VMware virtualisiert sind. Die Updates werden herunter geladen, aber deren Installation schlägt schließlich fehl. Dabei handelt es sich bei den Servern teilweise um Domänencontroller und/oder Domänenmitglieder, aber auch Server die nicht Mitglied in einer Domäne sind, sind gleichermaßen davon betroffen.

    Über die PowerShell konnten die Windows Updates auch installiert werden. Ebenso konnten über den Windows Updatekatalog heruntergeladene Updates installiert werden. Nur die automatische Windows Updateroutine scheitert. Es werden aber nur kommulative Monatsupdates nicht installiert. Andere Updates können installiert werden.

    Als Schutzmodul wird auf allen Rechnern nur Defender von Microsoft eingesetzt.

    Wir haben einen Fall beim Support von Microsoft dazu eröffnet. Aber auch dort hat man wohl keine Lösung. Wenn ich neue Erkenntnisse habe melde ich mich wieder.

    Andreas

    Freitag, 18. Mai 2018 04:53
  • Danke, ich bin gespannt. Das Problem ist hier zumindest auch weiterhin vorhanden.

    cu, Ingo

    Freitag, 18. Mai 2018 20:15
  • ohja, und wir seit heute auch. Gibt es schon Neuigkeiten?
    Mittwoch, 13. Juni 2018 14:43
  • Gleiches Problem hier, seit mehreren Monaten. Bin mal gespannt...
    Mittwoch, 27. Juni 2018 20:23