WSUS Problem mit Server 2016 und Windows 10

[kosta88 2]

Hallo,

die Updates auf den Win10 Rechnern bleiben bei 0% download hängen.

 

Nach einiger Recherche, sehe ich dass das mit 2016 und 10 bekannt sein soll, und einiges empfohlen wird, aber bei mir wirkt ja gar nichts.

1) es ist kein Proxy in Verwendung

2) die kumulativen Updates sind drauf: 2018-01, sowohl Server wie auch Client (damit auch soll das Problem mit Windows Update Agent erledigt sein)

3) Windows Firewall Domain/Private ist aus, Public ist an, Dienst ist gestartet

4) Die Methode net stop/start wuauserv/bits, und SoftwareDistribution zu löschen, habe ich gemacht

 

Wie soll mein weiteres Troubleshooting fortlaufen?

 

Danke

[Sunny61 809]

Welche Build hat dein WSUS? WSUS FAQ No. 44 hilft dabei: https://wsus.de/de/FAQ

 

Sind die Updates denn auch auf dem WSUS gedownloadet? Das siehst Du auf der Startseite vom WSUS, Downloadstatus. Welche Updates werden vom Client nicht gedownloadet? Oder sind es Upgrades?

[kosta88 2]

WSUS Build: 10.0.14393.1914

 

Update Status: "Ready for installation"

 

Es handelt sich hier spezifisch um MS SQL Server 2014 SP2 CU KB3178925.

 

Aber es hängt auch zB. Silverlight, dort wo kein SQL vorhanden ist. Derzeit sind nur 4 Updates in WSUS, ist ja ganz frisch sozusagen...

bearbeitet 4. Februar 2018 von kosta88

[Sunny61 809]

Das CU1 für SQL 2014 SP2: Cumulative Update, CU) 1 KB3178925

 

Und wenn Du in den Updates nach diesem Update suchst, findest Du es dort? Falls ja, wie ist der Dateistatus?

 

Lass dir auf dem Client die WindowsUpdate.log mit PS erzeugen und schau nach Fehlermeldungen durch. Nicht hier ungefragt posten.

[kosta88 2]

Das Update, wie auch jeder andere der hängt, sind alle im WSUS zu finden, und sind bereits heruntergeladen ("Ready for Installation" Status).

Weitere Updates die hängen sind Silverlight KB4023307 und 2018-01 Win10 Update KB4074608.

Es ist aber egal welcher Rechner, alle die irgendein Update ziehen wollen, hängen bei Downloading 0%.

 

Ich poste nicht den ganzen Log, das ist wohl klar, aber eine Zeile fällt mir auf:

Dynamic download data fetcher for ServiceId 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 does not exist.

[Sunny61 809]

vor 55 Minuten schrieb kosta88:

Das Update, wie auch jeder andere der hängt, sind alle im WSUS zu finden, und sind bereits heruntergeladen ("Ready for Installation" Status).

Weitere Updates die hängen sind Silverlight KB4023307 und 2018-01 Win10 Update KB4074608.

Es ist aber egal welcher Rechner, alle die irgendein Update ziehen wollen, hängen bei Downloading 0%.

 

Ich poste nicht den ganzen Log, das ist wohl klar, aber eine Zeile fällt mir auf:

Dynamic download data fetcher for ServiceId 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 does not exist.

 

Ich fragte nicht nach dem Status des WSUS, sondern nach dem Dateistatus. Den siehst Du im WSUS in den Updates wenn Du dir die entsprechende Spalte einblenden lässt.

 

[kosta88 2]

Ja, das meine ich ja! Die Spalte habe ich eingeblendet und wenn man darüber schwebt, steht ja zuerst dass heruntergeladen wird, mein Netzwerk ruddert mit ein paar MBit, und nach paar Minuten ist Ruhe, und dann ist das Symbol anders und wenn man darüber schwebt steht "Ready for installation".

 

Ich hoffe ich habe es nicht zum 2. Mal missverstanden...

[Sunny61 809]

OK, dann mach doch mal einen Rechtsklick auf das Update, Dateiinformationen und schau nach, ob es das Update auch im Dateisystem gibt.

 

Findest du Fehlermeldungen im SoftwareDistribution.log? Die Datei liegt im Programmverzeichnis vom WSUS.

[kosta88 2]

Dort gibt es einige Einträge.

 

Als Beispiel Silverlight Update:

Viele txt-Datei Referenzen und dann zwei mal Silverlight.exe und einmal Siliverlight_x64.exe. Die .exe Dateien sind im File-System vorhanden.

 

Ich sehe allerdings WSUS zeigt mir den HTTP Link. Damit fange ich irgendwie nichts an... jedoch schaue ich auf meiner Freigabe auf dem anderen Server (WSUS-Content Ordner), dann finde ich diese Dateien dort.

 

Wenn ich mal überlege, früher habe ich die Konfiguration immer mit iSCSI Laufwerken auf der NAS gemacht. Ist ja doch gar nicht verkehrt den WSUS-Contant auf einem Share (UNC-Pfad) zu hinterlegen?

[NorbertFe 2.089]

vor 14 Minuten schrieb kosta88:

Ist ja doch gar nicht verkehrt den WSUS-Contant auf einem Share (UNC-Pfad) zu hinterlegen?

Ist das jetzt eine Frage? Falls ja, doch ist "verkehrt", weil es nicht supportet ist. Ja es funktioniert, aber das ändert ja nix.

[kosta88 2]

Danke. Werde ich ändern (wieder via iSCSI) und wieder reporten.

[kosta88 2]

Das Problem ist gelöst - lag offensichtlich an dem UNC Pfad. Auf Spiceworks habe ich die Antwort bekommen dass es manche mit dem FQDN gelöst haben. Ich hatte nicht gewusst dass UNC Pfade nicht supportet sind - vielen vielen Dank, das hat einige Nerven gekostet...

[kosta88 2]

Eine Frage dazu, wenn schon zum Thema Pfad:

Bei einem Replica-WSUS, werde ich nach dem selben Eintrag bei der Installation und bei der Einrichtung gefragt. Bei der Einrichtung weiß ich dass ich den Häckchen entfernen muss, jedoch bei der Installation, was gebe ich dort ein?

 

Danke

[Sunny61 809]

vor 8 Minuten schrieb kosta88:

Eine Frage dazu, wenn schon zum Thema Pfad:

Bei einem Replica-WSUS, werde ich nach dem selben Eintrag bei der Installation und bei der Einrichtung gefragt. Bei der Einrichtung weiß ich dass ich den Häckchen entfernen muss, jedoch bei der Installation, was gebe ich dort ein?

Welche Pfad/Eintrag meinst Du?

[kosta88 2]

Wenn man im Server-Manager WSUS installiert, man wählt die Rolle aus, und dann kommt Eintrag für den Content Ordner ("Content Location Selection").

Kommt natürlich nicht, wenn ich mit Powershell installiere, somit hinterfrage ich ob das das gleiche ist, was beim ersten Aufruf vom WSUS aufpoppt, vonwegen Content (die normale Ersteinrichtung).

bearbeitet 6. Februar 2018 von kosta88