3
W7 und W10 Clients reporten sporadisch nicht an den WSUS Server
Hallo,
ungefähr 10% der Clients (egal ob W7 oder W10) reporten nicht regelmäßig an unseren WSUS Server. Ich habe auf zwei der betroffenen W10 (1709) Clients dann mal mittels Power Shell Command Get-WindowsUpdateLog eine Log erstellt. Die sieht in etwa so aus (hier nur das relevante):
2018.02.08 14:30:15.4900435 1900 9928 WebServices Auto proxy settings for this web service call.
2018.02.08 14:30:16.1351900 1900 9928 WebServices WS error: Der Text der empfangenen Nachricht enthielt einen Fehler.
2018.02.08 14:30:16.1351995 1900 9928 WebServices WS error: Der Text der empfangenen Nachricht enthielt einen Fehler.
2018.02.08 14:30:16.1352060 1900 9928 WebServices WS error: Der Text der empfangenen Nachricht enthielt einen Fehler.
2018.02.08 14:30:16.1352691 1900 9928 WebServices WS error: Der Text der empfangenen Nachricht enthielt einen Fehler.
2018.02.08 14:30:16.1352761 1900 9928 WebServices WS error: Der Text der empfangenen Nachricht enthielt einen Fehler.
2018.02.08 14:30:16.1355251 1900 9928 WebServices WS error: Server was unable to process request. ---> Object reference not set to an instance of an object.
2018.02.08 14:30:16.1355339 1900 9928 WebServices WS Error code: Server
2018.02.08 14:30:16.1355944 1900 9928 WebServices WS error: <detail/>
2018.02.08 14:30:16.1370702 1900 9928 IdleTimer WU operation (CLegacyEventUploader::HandleEvents, operation # 29475) stopped; does use network; is at background priority
2018.02.08 14:33:02.6681540 8344 564 ComApi * START * Federated Search ClientId = TrustedInstaller FOD Enumerate (cV: IDMXBs2pKUyYU5gt.1.1.0)
2018.02.08 14:33:02.6689694 1900 11108 IdleTimer WU operation (SR.TrustedInstaller FOD Enumerate ID 3615) started; operation # 29481; does use network; is not at background priority
2018.02.08 14:33:02.6761833 1900 9552 IdleTimer WU operation (SR.TrustedInstaller FOD Enumerate ID 3615, operation # 29481) stopped; does use network; is not at background priority
2018.02.08 14:33:02.6783695 8344 5488 ComApi Federated Search: Starting search against 1 service(s) (cV = IDMXBs2pKUyYU5gt.1.1.0)
2018.02.08 14:33:02.6784530 8344 5488 ComApi * START * Search ClientId = TrustedInstaller FOD Enumerate, ServiceId = 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 (cV =
2018.02.08 14:33:02.6791871 1900 11108 IdleTimer WU operation (CSearchCall::Init ID 3616) started; operation # 29484; does use network; is not at background priority
2018.02.08 14:33:02.7100154 1900 11108 Agent * START * Queueing Finding updates [CallerId = TrustedInstaller FOD Enumerate Id = 3616]
2018.02.08 14:33:02.7100190 1900 11108 Agent Removing service 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 from sequential scan list
2018.02.08 14:33:02.7100227 1900 11108 Agent Service 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 is not in sequential scan list
2018.02.08 14:33:02.7100260 1900 11108 Agent Added service 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 to sequential scan list
2018.02.08 14:33:02.7101747 1900 4008 Agent Service 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 is in sequential scan list
2018.02.08 14:33:02.7218515 1900 8420 Agent * END * Queueing Finding updates [CallerId = TrustedInstaller FOD Enumerate Id = 3616]
2018.02.08 14:33:02.7331432 1900 8420 Agent * START * Finding updates CallerId = TrustedInstaller FOD Enumerate Id = 3616
2018.02.08 14:33:02.7331454 1900 8420 Agent Online = Yes; Interactive = Yes; AllowCachedResults = No; Ignore download priority = No
2018.02.08 14:33:02.7331465 1900 8420 Agent Criteria = (Product='Client.OS.rs2.amd64' and CurrentVersionOnly=1)""
Dieser WS error kommt immer wieder und wieder.... Aber nur auf den Clients die nich reporten. Ich denke das der Client hier reporten will, aber es nicht funktioniert.
Auf einem funktionalen Client sieht es in etwa so aus:
2018.01.30 11:27:22.3784868 1748 2708 WebServices Auto proxy settings for this web service call.
2018.01.30 11:27:22.8800821 1748 2708 WebServices Auto proxy settings for this web service call.
2018.01.30 11:27:23.3689630 1748 2708 ProtocolTalker PTInfo: Server requested registration
2018.01.30 11:27:24.3491157 1748 2708 ProtocolTalker PTInfo: syncing with server using normal query
2018.01.30 11:27:24.8105438 1748 2708 ProtocolTalker SyncUpdates round trips: 2
2018.01.30 11:27:26.1012693 1748 2708 Agent Found 0 updates and 94 categories in search; evaluated appl. rules of 1330 out of 2612 deployed entities
2018.01.30 11:27:26.1089706 1748 2708 Agent * END * Finding updates CallerId = UpdateOrchestrator Id = 1
2018.01.30 11:27:26.1183146 1748 3700 ComApi *RESUMED* Search ClientId = UpdateOrchestrator
2018.01.30 11:27:26.1193427 1748 3700 ComApi Updates found = 0
2018.01.30 11:27:26.1193436 1748 3700 ComApi * END * Search ClientId = UpdateOrchestrator
Es scheinen auch immer die selben Clients zu sein die nicht reporten oder in sehr unregemäßigen Abständen. Trotz vieler und langer Googlelei bin ich nicht auf die Ursache gekommen. Laut unseres WSUS Administrators (der bin ich nicht) sei am Server selbst alles 100% in Ordnung.
Hat jemand schon mal das PRoblem gehabt? Lösungsvorschläge?
vielen dank!
ungefähr 10% der Clients (egal ob W7 oder W10) reporten nicht regelmäßig an unseren WSUS Server. Ich habe auf zwei der betroffenen W10 (1709) Clients dann mal mittels Power Shell Command Get-WindowsUpdateLog eine Log erstellt. Die sieht in etwa so aus (hier nur das relevante):
2018.02.08 14:30:15.4900435 1900 9928 WebServices Auto proxy settings for this web service call.
2018.02.08 14:30:16.1351900 1900 9928 WebServices WS error: Der Text der empfangenen Nachricht enthielt einen Fehler.
2018.02.08 14:30:16.1351995 1900 9928 WebServices WS error: Der Text der empfangenen Nachricht enthielt einen Fehler.
2018.02.08 14:30:16.1352060 1900 9928 WebServices WS error: Der Text der empfangenen Nachricht enthielt einen Fehler.
2018.02.08 14:30:16.1352691 1900 9928 WebServices WS error: Der Text der empfangenen Nachricht enthielt einen Fehler.
2018.02.08 14:30:16.1352761 1900 9928 WebServices WS error: Der Text der empfangenen Nachricht enthielt einen Fehler.
2018.02.08 14:30:16.1355251 1900 9928 WebServices WS error: Server was unable to process request. ---> Object reference not set to an instance of an object.
2018.02.08 14:30:16.1355339 1900 9928 WebServices WS Error code: Server
2018.02.08 14:30:16.1355944 1900 9928 WebServices WS error: <detail/>
2018.02.08 14:30:16.1370702 1900 9928 IdleTimer WU operation (CLegacyEventUploader::HandleEvents, operation # 29475) stopped; does use network; is at background priority
2018.02.08 14:33:02.6681540 8344 564 ComApi * START * Federated Search ClientId = TrustedInstaller FOD Enumerate (cV: IDMXBs2pKUyYU5gt.1.1.0)
2018.02.08 14:33:02.6689694 1900 11108 IdleTimer WU operation (SR.TrustedInstaller FOD Enumerate ID 3615) started; operation # 29481; does use network; is not at background priority
2018.02.08 14:33:02.6761833 1900 9552 IdleTimer WU operation (SR.TrustedInstaller FOD Enumerate ID 3615, operation # 29481) stopped; does use network; is not at background priority
2018.02.08 14:33:02.6783695 8344 5488 ComApi Federated Search: Starting search against 1 service(s) (cV = IDMXBs2pKUyYU5gt.1.1.0)
2018.02.08 14:33:02.6784530 8344 5488 ComApi * START * Search ClientId = TrustedInstaller FOD Enumerate, ServiceId = 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 (cV =
2018.02.08 14:33:02.6791871 1900 11108 IdleTimer WU operation (CSearchCall::Init ID 3616) started; operation # 29484; does use network; is not at background priority
2018.02.08 14:33:02.7100154 1900 11108 Agent * START * Queueing Finding updates [CallerId = TrustedInstaller FOD Enumerate Id = 3616]
2018.02.08 14:33:02.7100190 1900 11108 Agent Removing service 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 from sequential scan list
2018.02.08 14:33:02.7100227 1900 11108 Agent Service 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 is not in sequential scan list
2018.02.08 14:33:02.7100260 1900 11108 Agent Added service 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 to sequential scan list
2018.02.08 14:33:02.7101747 1900 4008 Agent Service 3DA21691-E39D-4DA6-8A4B-B43877BCB1B7 is in sequential scan list
2018.02.08 14:33:02.7218515 1900 8420 Agent * END * Queueing Finding updates [CallerId = TrustedInstaller FOD Enumerate Id = 3616]
2018.02.08 14:33:02.7331432 1900 8420 Agent * START * Finding updates CallerId = TrustedInstaller FOD Enumerate Id = 3616
2018.02.08 14:33:02.7331454 1900 8420 Agent Online = Yes; Interactive = Yes; AllowCachedResults = No; Ignore download priority = No
2018.02.08 14:33:02.7331465 1900 8420 Agent Criteria = (Product='Client.OS.rs2.amd64' and CurrentVersionOnly=1)""
Dieser WS error kommt immer wieder und wieder.... Aber nur auf den Clients die nich reporten. Ich denke das der Client hier reporten will, aber es nicht funktioniert.
Auf einem funktionalen Client sieht es in etwa so aus:
2018.01.30 11:27:22.3784868 1748 2708 WebServices Auto proxy settings for this web service call.
2018.01.30 11:27:22.8800821 1748 2708 WebServices Auto proxy settings for this web service call.
2018.01.30 11:27:23.3689630 1748 2708 ProtocolTalker PTInfo: Server requested registration
2018.01.30 11:27:24.3491157 1748 2708 ProtocolTalker PTInfo: syncing with server using normal query
2018.01.30 11:27:24.8105438 1748 2708 ProtocolTalker SyncUpdates round trips: 2
2018.01.30 11:27:26.1012693 1748 2708 Agent Found 0 updates and 94 categories in search; evaluated appl. rules of 1330 out of 2612 deployed entities
2018.01.30 11:27:26.1089706 1748 2708 Agent * END * Finding updates CallerId = UpdateOrchestrator Id = 1
2018.01.30 11:27:26.1183146 1748 3700 ComApi *RESUMED* Search ClientId = UpdateOrchestrator
2018.01.30 11:27:26.1193427 1748 3700 ComApi Updates found = 0
2018.01.30 11:27:26.1193436 1748 3700 ComApi * END * Search ClientId = UpdateOrchestrator
Es scheinen auch immer die selben Clients zu sein die nicht reporten oder in sehr unregemäßigen Abständen. Trotz vieler und langer Googlelei bin ich nicht auf die Ursache gekommen. Laut unseres WSUS Administrators (der bin ich nicht) sei am Server selbst alles 100% in Ordnung.
Hat jemand schon mal das PRoblem gehabt? Lösungsvorschläge?
vielen dank!
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 364503
Url: https://administrator.de/contentid/364503
Ausgedruckt am: 22.11.2024 um 12:11 Uhr
3 Kommentare
Neuester Kommentar
mehr Infos jetzt erhalten:
WSUS Server: 6.3.9600. 18694 auf 2012 R2 Windows Server samt SQL Server 2016
Firewall Setting auf Client temporär auf "alles erlaubt"
Client hat die richtigen Settings erhalten, d.h. WSUS Server Adresse und alles ist da.
WSUS Server: 6.3.9600. 18694 auf 2012 R2 Windows Server samt SQL Server 2016
Firewall Setting auf Client temporär auf "alles erlaubt"
Client hat die richtigen Settings erhalten, d.h. WSUS Server Adresse und alles ist da.
Wie schaut es denn aus mit dem aufräumen des WSUS? Wir benutzen dafür ein Script was beim WSUS Server läuft.
Grund bei uns ist das Problem gewesen das wir mit unserem Server 2008 R2 keine Updates mehr an die Windows 10 Maschienen verteilen konnte. Nach dem wir das Script nun jeden Tag am laufen haben flutscht es auch bei den Windows 10 Systemen wieder wie es soll.
http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus
PS: Halt nicht genau dein Problem, aber evtl. hilft es Dir ja auch.
Grund bei uns ist das Problem gewesen das wir mit unserem Server 2008 R2 keine Updates mehr an die Windows 10 Maschienen verteilen konnte. Nach dem wir das Script nun jeden Tag am laufen haben flutscht es auch bei den Windows 10 Systemen wieder wie es soll.
http://community.spiceworks.com/scripts/show/2998-adamj-clean-wsus
PS: Halt nicht genau dein Problem, aber evtl. hilft es Dir ja auch.
Hallo,
danke für den Tipp. Das "Aufräumen" macht de WSUS Admin 1x im Monat (kurz bevor gepatcht wird). Es trifft auch nicht ganz genau meine Problemstellung wie schon von dir gesagt.
Die Updates werden ja auch korrekt verteilt & installiert, nur reportet wird nicht immer fleißig zurück. Ich werde das Script mal weiterleiten, aber denke das ist hier noch nicht die Lösung.
danke für den Tipp. Das "Aufräumen" macht de WSUS Admin 1x im Monat (kurz bevor gepatcht wird). Es trifft auch nicht ganz genau meine Problemstellung wie schon von dir gesagt.
Die Updates werden ja auch korrekt verteilt & installiert, nur reportet wird nicht immer fleißig zurück. Ich werde das Script mal weiterleiten, aber denke das ist hier noch nicht die Lösung.
