6
Clients (Win10 1607) holen Updats vom Internet statt WSUS
Guten Morgen
Wir haben seit einiger Zeit das Problem, dass rund die Hälfte unserer Clients die Updates vom Internet holen will, statt von unserem WSUS-Server.
Diese melden sich zwar beim WSUS-Server, jedoch mit dem Status 100%.
Unsere Installation:
WSUS = Server 2008 R2
Clients = Windows 10 Pro 1607
Die Clients haben folgende Build-Versionen:
10.0.14393.479
10.0.14393.594
10.0.14393.953
10.0.14393.1066
10.0.14393.1198
Auf der Firewall habe ich die Adressen zu Windows Update blockiert. Auf den Problem-Clients erscheint dann: "Wir konnten keine Verbindung mit dem Updatedienst herstellen. Wir versuchen es später erneut."
Das Problem scheint bekannt zu sein, nur die Lösung habe ich nicht gefunden.
- Eine gefundene Lösung ist angeblich das deaktivieren von "Featureupdates zurückstellen". Dies ist bei uns jedoch gar nicht aktiviert.
- Ein zweiter Lösungsansatz: in der GPO bei Übermittlungsoptimierung auf "Umgehen" einstellen (bei uns auf "nur HTTP") , was zur folgen hat, dass sich die Clients nicht mehr bei unserem WSUS melden, oder...
- ..."Keine Verbindung mit Windows Update-Internetadressen herstellen" aktivieren, was dann bei meinem funktionierenden Client die Fehlermeldung "0x8024500c" anzeigt.
Da die Clients im WSUS nun verschiedene Build-Versionen anzeigen, kann ich auch nicht auf ein Fehlerhaftes Update eingrenzen.
Womöglich geht der Fehler auch vom WSUS-Server aus...
Ich komme der Ursache einfach nicht auf die Schliche...
Hat von euch noch jemand einen Lösungsansatz?
Beste Grüsse
Swisstom
Wir haben seit einiger Zeit das Problem, dass rund die Hälfte unserer Clients die Updates vom Internet holen will, statt von unserem WSUS-Server.
Diese melden sich zwar beim WSUS-Server, jedoch mit dem Status 100%.
Unsere Installation:
WSUS = Server 2008 R2
Clients = Windows 10 Pro 1607
Die Clients haben folgende Build-Versionen:
10.0.14393.479
10.0.14393.594
10.0.14393.953
10.0.14393.1066
10.0.14393.1198
Auf der Firewall habe ich die Adressen zu Windows Update blockiert. Auf den Problem-Clients erscheint dann: "Wir konnten keine Verbindung mit dem Updatedienst herstellen. Wir versuchen es später erneut."
Das Problem scheint bekannt zu sein, nur die Lösung habe ich nicht gefunden.
- Eine gefundene Lösung ist angeblich das deaktivieren von "Featureupdates zurückstellen". Dies ist bei uns jedoch gar nicht aktiviert.
- Ein zweiter Lösungsansatz: in der GPO bei Übermittlungsoptimierung auf "Umgehen" einstellen (bei uns auf "nur HTTP") , was zur folgen hat, dass sich die Clients nicht mehr bei unserem WSUS melden, oder...
- ..."Keine Verbindung mit Windows Update-Internetadressen herstellen" aktivieren, was dann bei meinem funktionierenden Client die Fehlermeldung "0x8024500c" anzeigt.
Da die Clients im WSUS nun verschiedene Build-Versionen anzeigen, kann ich auch nicht auf ein Fehlerhaftes Update eingrenzen.
Womöglich geht der Fehler auch vom WSUS-Server aus...
Ich komme der Ursache einfach nicht auf die Schliche...
Hat von euch noch jemand einen Lösungsansatz?
Beste Grüsse
Swisstom
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 338314
Url: https://administrator.de/contentid/338314
Printed on: April 20, 2024 at 03:04 o'clock
6 Comments
Latest comment
Moin,
die aktuellen Templates (ADMX) für 1607 hast du in installiert? Es gibt unter Computerkonfiguration -> ADMV -> Windows-Komponenten->Windows Update die Regel:
Keine Verbindung mit Windows Update-Internetadressen herstellen
Dazu muss der Interne Pfad für den Updatedienst angeben sein.
Gruß, V
die aktuellen Templates (ADMX) für 1607 hast du in installiert? Es gibt unter Computerkonfiguration -> ADMV -> Windows-Komponenten->Windows Update die Regel:
Keine Verbindung mit Windows Update-Internetadressen herstellen
Dazu muss der Interne Pfad für den Updatedienst angeben sein.
Gruß, V
Hallo Voiper
Die habe ich installiert (bzw. aktualisiert) und zwar aus dem Grund, weil es neu die Möglichkeit gibt für den internen Pfad des Updatedienstes einen alternativen (WSUS-)Server anzugeben. Wenn dort der Eintrag fehlt, geht der Client angeblich im Internet nach Updates suchen.
Wie auch immer, bei uns hat dies auch nicht zum Erfolg geführt.
Und bei der hälfte der Clients (insgesamt ca. 140) haben wir auch kein Problem...
Die habe ich installiert (bzw. aktualisiert) und zwar aus dem Grund, weil es neu die Möglichkeit gibt für den internen Pfad des Updatedienstes einen alternativen (WSUS-)Server anzugeben. Wenn dort der Eintrag fehlt, geht der Client angeblich im Internet nach Updates suchen.
Wie auch immer, bei uns hat dies auch nicht zum Erfolg geführt.
Und bei der hälfte der Clients (insgesamt ca. 140) haben wir auch kein Problem...
N'Abend.
Wird die GPO korrekt gezogen auf den Clients?
Schau mal bei so nem "Problembären" in die Registry:
HKLM\Software\Policies\Microsoft\Windows\Windows Update - stehen da die korrekten Werte drin?
Können diese Clients den Namen des WSUS-Servers korrekt auflösen/können diese Clients deinen WSUS anpingen?
Wenn nicht: DNS-Settings kontrollieren, HOSTS-Datei kontrollieren.
Cheers,
jsysde
Wird die GPO korrekt gezogen auf den Clients?
Schau mal bei so nem "Problembären" in die Registry:
HKLM\Software\Policies\Microsoft\Windows\Windows Update - stehen da die korrekten Werte drin?
Können diese Clients den Namen des WSUS-Servers korrekt auflösen/können diese Clients deinen WSUS anpingen?
Wenn nicht: DNS-Settings kontrollieren, HOSTS-Datei kontrollieren.
Cheers,
jsysde
1
Hallo jsysde
Die GPOs werden korrekt gezogen.
DNS funktioniert, die Clients melden ja auch den Status beim WSUS.
Mit Windows 10 1511 war das Problem definitiv nicht vorhanden...
MfG
Swisstom
Die GPOs werden korrekt gezogen.
DNS funktioniert, die Clients melden ja auch den Status beim WSUS.
Mit Windows 10 1511 war das Problem definitiv nicht vorhanden...
MfG
Swisstom
Moin.
Ich hab das Problem mit keinem Windows 10 Build, hier laufen 1507/1511/1607/1703 brav mit den identischen Einstellungen.
Ne Idee, was deine Problem-Clients da machen, hab ich ad hoc aber auch nicht; ggf. kannste ja mal (Ich weiß, Handarbeit) die Reg-Einstellung von jeweils einem "guten" und einem "bösen" Client miteinander vergleichen?
Zum Analysieren der WSUS-Settings helfen ggf. auch Tools wie der WSUS ClientManager:
https://wsusworkgroup.codeplex.com/
Cheers,
jsysde
Ich hab das Problem mit keinem Windows 10 Build, hier laufen 1507/1511/1607/1703 brav mit den identischen Einstellungen.
Ne Idee, was deine Problem-Clients da machen, hab ich ad hoc aber auch nicht; ggf. kannste ja mal (Ich weiß, Handarbeit) die Reg-Einstellung von jeweils einem "guten" und einem "bösen" Client miteinander vergleichen?
Zum Analysieren der WSUS-Settings helfen ggf. auch Tools wie der WSUS ClientManager:
https://wsusworkgroup.codeplex.com/
Cheers,
jsysde
Zitat von @jsysde:
Ich hab das Problem mit keinem Windows 10 Build, hier laufen 1507/1511/1607/1703 brav mit den identischen Einstellungen.
Ich hab das Problem mit keinem Windows 10 Build, hier laufen 1507/1511/1607/1703 brav mit den identischen Einstellungen.
Hallo jsysde
Ich habe die Lösung offenbar gefunden.
Wir hatten folgende Richtlinie aktiviert: "Keine Treiber in Windows-Updates einschliessen"
Jetzt habe ich diese auf "Nicht konfiguriert" gesetzt, dafür die Regel "Keine Verbindungen mit Windows-Update-Internetadressen herstellen" aktiviert.
Nun melden die Clients wieder den korrekten Status an und nehmen sich die Updates wieder vom WSUS
Beste Grüsse
Swisstom
