WSUS clients rapporteren niet allemaal

[Aschtra]

Mijn vraag
In mijn WSUS server staan op dit moment 402 werkplekken. Dit is een combinatie van Windows 7, 8.1 en Windows 10. Daarvan rapporteren er 23 langer dan 30 dagen niet en een stuk of 15 hebben überhaupt nog niet gerapporteerd. Wat kan ik hieraan doen?

Relevante software en hardware die ik gebruik
Windows Server 2012R2, WSUS versie 6.3.9800.18288

Wat ik al gevonden of geprobeerd heb

Toen ik op 30 januari WSUS in mijn beheer nam stonden er 140 laptops die langer dan 30 dagen niet rapporteerden. Ik heb veel gezocht op Google en waar ik uiteindelijk uit kwam is dat veel van mijn clients hetzelfde SUID hebben. Middels het volgende script die ik heb uitgevoerd op alle werkplekken heb ik ze een reset kunnen geven waardoor ze weer rapporteren naar de server. Op dit moment zijn er 23 die langer dan 30 dagen niet rapporteren. En een stuk of 15 die nog nooit gerapporteerd hebben.

REG Delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientId /f
REG Delete HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate /v SusClientIdValidation /f
REG Add HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUServer /t REG_SZ /d http://*wsusserver*:8530 /F
REG Add HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate /v WUStatusServer /t REG_SZ /d http://*wsusserver*:8530 /F
echo n | gpupdate /force /wait:0
net stop wuauserv /y
net stop BITS /y
rd C:\WINDOWS\SoftwareDistribution /s /Q
del "c:\windows\windowsupdate.log"
regsvr32 WUAPI.DLL /s
regsvr32 WUAUENG.DLL /s
regsvr32 WUAUENG1.DLL /s
regsvr32 ATL.DLL /s
regsvr32 WUCLTUI.DLL /s
regsvr32 WUPS.DLL /s
regsvr32 WUPS2.DLL /s
regsvr32 WUWEB.DLL /s
regsvr32 msxml3.dll /s
net start wuauserv /y
wuauclt.exe /resetauthorization

Echter 23 willen niet werken. Ik heb de windowsupdatelog bekeken van enkele werkplekken en wat ik daar regelmatig terug zie keren is het volgende:

2017-02-24 10:32:14.9726436 1100 6240 WebServices WS error: Er is een fout opgetreden bij het communiceren met het eindpunt op http://WSUS01-01:8530/ClientWebService/client.asmx.
2017-02-24 10:32:14.9726469 1100 6240 WebServices WS error: Er is een fout opgetreden bij het ontvangen van het HTTP-antwoord.
2017-02-24 10:32:14.9726486 1100 6240 WebServices WS error: De bewerking is niet binnen de toegewezen tijd voltooid.
2017-02-24 10:32:14.9726519 1100 6240 WebServices WS error: Er is een fout opgetreden bij het communiceren met het eindpunt op http://WSUS01-01:8530/ClientWebService/client.asmx.
2017-02-24 10:32:14.9726535 1100 6240 WebServices WS error: Er is een fout opgetreden bij het ontvangen van het HTTP-antwoord.
2017-02-24 10:32:14.9726555 1100 6240 WebServices WS error: De bewerking is niet binnen de toegewezen tijd voltooid.
2017-02-24 10:32:14.9726617 1100 6240 WebServices WS error: Er is een fout opgetreden bij het communiceren met het eindpunt op http://WSUS01-01:8530/ClientWebService/client.asmx.
2017-02-24 10:32:14.9726642 1100 6240 WebServices WS error: Er is een fout opgetreden bij het ontvangen van het HTTP-antwoord.
2017-02-24 10:32:14.9726666 1100 6240 WebServices WS error: De bewerking is niet binnen de toegewezen tijd voltooid.
2017-02-24 10:32:14.9726679 1100 6240 WebServices WS error: Er heeft een time-out van de bewerking plaatsgevonden.
2017-02-24 10:32:14.9726711 1100 6240 WebServices Web service call failed with hr = 8024401c.

Echter als ik die laatste foutmelding door Google heen haal dan kom ik op weinig uit.

Nog wat aanvullende informatie:

- Online zoeken naar Windows Updates werkt wel.
- Bij 'normaal' zoeken naar updates komt een 0x8024401c foutmelding.
- Werkplekken worden via WDS uitgerold --> Hierdoor waarschijnlijke dubbele SUID's
- Ze komen wel in WSUS te staan.
- Ze contacteren de server wel maar rapporteren niet
- Grootste deel van de andere werkplekken werken dus wel
- Group Policy wordt juist ingelezen
- Computers komen in de juiste WSUS Group a.d.h.v. Group Policy.
- Geduld heb ik gehad, script voer ik meestal op maandag uit en gedurende week gaan er steeds meer rapporteren. Echter sommige dus totaal niet

Iemand een idee?

[Aschtra]

Niemand een idee?

[Verwijderd]

Als je een gpresult doet, geven ze dan wel de juiste server aan?
Staat BITS netjes aan?

[Aschtra]

Verwijderd schreef op dinsdag 28 februari 2017 @ 19:15:
Als je een gpresult doet, geven ze dan wel de juiste server aan?
Staat BITS netjes aan?

BITS staat aan. Wat moet een GPresult qua server laten zien? Hij haalt de GPO van de juiste server ja.

[MdBruin]

Hebben ze ook problemen in het domein?
Zit er aan te denken dat misschien toen de image (wds) gemaakt is er van te voren geen sysprep gedraaid is.

Mogelijk heb je nog een spare op de plank liggen, laat daar eens de image op installeren en kijk of je het probleem daar ook op hebt. Draai daar eens sysprep op en configureer (laatste stappen ik weet niet of je dit normaal ook moet doen) de computer en probeer opnieuw.

[Aschtra]

Sysprep is op alle images uitgevoerd. Al zou dat niet uit mogen maken want als ik het script afvoer krijgt de werkplek weer een nieuw uniek suid.

Jouw advies heb ik geprobeerd en ook daar speelt het probleem

[MrTre]

-Om welke OS versies gaat het die (nu) niet of nog niet rapporteren?
-Welke instelling heb je in je GPO staan in de setting "Specify intranet Microsoft update service location" Bijvoorbeeld: http://[servernaam]:8530 (=standaard poortnummer)
-heb je in je GPO de setting "Allow signed updates from an intranet Microsoft update service location " op enabled staan?

[ Voor 7% gewijzigd door MrTre op 01-03-2017 10:11 . Reden: 2e gpo setting niet goed gecopy/pasted ]

[Aschtra]

MrTre schreef op woensdag 1 maart 2017 @ 10:06:
-Om welke OS versies gaat het die (nu) niet of nog niet rapporteren?
-Welke instelling heb je in je GPO staan in de setting "Specify intranet Microsoft update service location" Bijvoorbeeld: http://[servernaam]:8530 (=standaard poortnummer)
-heb je in je GPO de setting "Allow signed updates from an intranet Microsoft update service location " op enabled staan?

- Windows 7, 8.1 en 10.
- Set the intranet update service for detecting updates: http://*servernaam*:8530
Set the intranet statistics server: http:/*servernaam*:8530

- Deze is niet ingesteld. Ik ga deze op enabled zetten en met mijn testlaptop kijken wat er gebeurt.

edit:

Die policy zou niet nodig moeten zijn. Die geeft de mogelijkheid om updates op te halen van derde partijen.
Ook werken andere (nieuwe) werkplekken wel zonder die optie.

Het is nou ook weer niet zo dat alle nieuwe werkplekken het wel doen. Zowel oude en nieuwe doen het niet. Dat gedeelte maakt verder niet uit

En het geeft dezelfde melding

[ Voor 18% gewijzigd door Aschtra op 01-03-2017 12:20 ]

[Aschtra]

Toch nog een bumpje want dit speelt nog steeds.
Ben benieuwd of iemand nog ideeën heeft

[So_Surreal]

Aschtra schreef op maandag 20 maart 2017 @ 17:40:
Toch nog een bumpje want dit speelt nog steeds.
Ben benieuwd of iemand nog ideeën heeft

Ik ben op mijn werk toevallig een tijd terug begonnen met WSUS, dus wellicht kan ik je op weg helpen
Toen ik je probleem las dacht ik inderdaad aan geclonede machines, ik had ook een collega die de VM's niet gesysprepped had voor het clonen
Ik heb mijn WSUS registry clean script vergeleken met die van jou en die komt grotendeels wel overeen.

Komen de PC's die niet reporten wel in het overzicht te staan bij Update Services > *Server-naam* > Computers > *Computer-Group-naam* ?

Probeer anders PSEXEC op C:\psexec te zetten en maak dan eens een BAT-bestand aan, en laat deze eens lopen met de volgende regel:

^{C:\psexec\psexec.exe \\FQDNvancomputer -d C:\windows\system32\wuauclt.exe /resetauthorization /reportnow
pause}

(Ik weet niet hoe je hier code quote op dit forum )

Let op: pas de FQDN van je computer nog aan naar een van de computers die niet reporten !

[Aschtra]

Zoals in de startpost te zien is staan ze dus wel gewoon in de WSUS console in de juiste groep. Ze nemen ook iedere dag meerdere keren per dag contact op met de server maar rapporteren dus niet in de meeste gevallen.

PSEXEC is geblokkeerd bij ons, ik gebruik PDQ Deploy om scripts af te trappen.

wuauclt.exe /resetauthorization opdracht staat ook in het script.

Rare is dat het script bij 120 werkplekken wel gewerkt heeft. Maar bij 20 nog niet. Nou moet ik wel zeggen dat die 20 die op dit moment nog niet rapporteren wel extreem lang niet meer gerapporteerd hebben. Die 20 liggen tussen de 50 en 170 dagen van not reported.

Ook nog de volgende aanpassingen gedaan op de WSUS server:

IIS:

- ClientWebService: Execution Timeout verlengd naar 2 uur ipv 1 minuut 50 seconden. MaxRequestlength aangepast naar 204800
- ReportingWebService: Execution Timeout verlengd naar 2 uur ipv 1 minuut 50 seconden. MaxRequestlength aangepast naar 204800
- WSUSPOOL: CPU Throttle naar 35% om te voorkomen dat de server gehele tijd op 100% loopt.

Server 4GB RAM extra gegeven. Totaal nu 8GB RAM.

WSUS Script uitgevoerd op werkplekken die niet binnen 30 dagen rapporteren. Op dit moment zijn dat 18 werkplekken

Dus wel iets minder nu. Voor het eerst onder de 20 not reported. Sinds gisteren (na de aanpassingen) zijn het er 5 minder.

[ Voor 35% gewijzigd door Aschtra op 21-03-2017 11:34 ]