Rybski.be

Zoals met ieder degelijk softwarepakket kan er ook met WSUS (Windows Server Update Service) een variëteit aan problemen opduiken. Dit artikel beschrijft een paar mogelijke problemen die kunnen optreden wanneer werkstations proberen een verbinding te maken met de WSUS-server.

Windows Server Update Service oftewel WSUS is een gratis product van Microsoft om computer- en serverparken up-to-date te houden met patches, hotfixes en andere updates voor Windows, Internet Explorer, Office, SQL Server en Exchange Server. De WSUS-pagina bij Microsoft vind je op
http://www.microsoft.com/belux/nl/windowsserversystem/updateservices/default.mspx

Na de installatie en configuratie van een WSUS-server (de uitleg hiervan valt buiten het bereik van dit artikel) registreren de werkstations en servers zich automatisch bij WSUS. Na verloop van tijd toont de WSUS-interface een lijst van alle servers en werkstations met een overzicht van de updates die geïnstalleerd of nog benodigd zijn. Mooi in theorie, maar de praktijk durft al eens tegenvallen. De kans is groot dat een relatief klein percentage computers niet verschijnt in WSUS. Daarnaast kunnen er een handvol computers zijn die wel te zien zijn in WSUS maar geen status rapporteren aan de server.

Het oplossen van dergelijke problemen begint altijd met het uitpluizen van de logbestanden. Op iedere client wordt er een log bijgehouden van de updateactiviteit. Dit bestand is te vinden in de Windows-directory met als naam “windowsupdate.log”, bijvoorbeeld c:\windows\windowsupdate.log. Even opletten met de naam want er bestaat ook een “windows update.log” (dus met een spatie in de naam) maar het is wel degelijk het bestand zonder de spatie dat we nodig hebben.

Windowsupdate.log bevat heel wat informatie (de meest recente gebeurtenissen staan onderin) en is niet bepaald aangename avondlectuur. Niettemin bevat dit bestand meestal heel goede hints over de oorzaak van allerlei problemen.

Voorbeeldprobleem 1:

WARNING: Send failed with hr = 80072f78.
WARNING: SendRequest failed with hr = 80072f78. Proxy List used: <https://SERVERA;http://SERVERA> Bypass List used : <<local>> Auth Schemes used : <>
WARNING: WinHttp: SendRequestUsingProxy failed for <http://download.windowsupdate.com/v6/windowsupdate/redir/wuredir.cab>. error 0x80072f78
WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x80072f78
WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x80072f78
WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x80072f78

In het voorbeeld hierboven kan de client de WSUS-server niet bereiken en worden er fouten 0x80072f78 in de logging gegenereerd. In bovenstaand geval was het probleem dat er een proxy-server opgegeven is terwijl er voor intranetverbinding helemaal geen proxy nodig is (zie lijn 2 van het voorbeeld “Proxy List used”). Verder onderzoek wees uit dat er in de internetinstellingen van het probleemtoestel geen proxy geconfigureerd was terwijl de WSUS-logging toch duidelijk toont dat de client probeert er een te gebruiken. Het bekijken, wijzigen en eventueel verwijderen van de proxy-instellingen kan via het het commando:

proxycfg

Indien de output van dit commando een foutieve instelling toont kan deze gewist worden met:

proxycfg -d

Daarna moet de “Automatische Updates”-service herstart worden.

Sommige websites vermelden dat het toevoegen van de url van de WSUS-server aan de lijst van vertrouwde sites in de internetinstellingen kan helpen. Persoonlijk heb ik nog geen geluk gehad met deze methode, maar voor hopeloze gevallen kan het altijd geprobeerd worden.

Een ander probleem:

WARNING: SyncUpdates failure, error = 0x8024400A, soap client error = 10, soap error code = 0, HTTP status code = 200
WARNING: Sync of Updates: 0x8024400a
* WARNING: Failed to synchronize, error = 0x8024400A
* WARNING: Exit code = 0x8024400A

Zoals gewoonlijk bevat de log een duidelijke melding van de fout, met name 0x8024400A, maar ook niet meer dan dat. Deze fout kan opgelost worden door het opnieuw registreren van een aantal dll’s op de client. Het registereren van dll’s gebeurt met regsvr32:

net stop wuauserv
regsvr32 /s wuapi.dll
regsvr32 /s wups.dll
regsvr32 /s wuaueng.dll
regsvr32 /s wuaueng1.dll
regsvr32 /s wucltui.dll
regsvr32 /s wuweb.dll
regsvr32 /s jscript.dll
regsvr32 /s atl.dll
regsvr32 /s softpub.dll
regsvr32 /s msxml3.dll
net start wuauserv

Het eerste en het laatste commando is het stoppen en starten van de “Automatische Updates”-service. Daar tussenin gebeurt het registeren van de dll’s. In de meeste gevallen ligt het probleem bij de msxml3.dll en is het voldoende enkel die te registreren. Er is echter geen direct nadeel wanneer men ze allemaal in een keer doet in plaats van één voor één.

Bovenstaande commando’s kunnen gekopieerd en geplakt worden in een bestand, bijvoorbeeld “registerwsus.cmd”, dat dan op het probleemtoestel uitgevoerd kan worden (dat bespaart wat typwerk). Zorg er wel voor dat regsvr32.exe te vinden is vanuit de locatie waar de commando's uitgevoerd worden of plaats %WINDIR%\SYSTEM32\ voor iedere regsvr32-lijn in het cmd-bestand.

Na het starten van de service is het beter even te wachten, een tiental seconden, totdat alles netjes opgestart is. Daarna kan het connecteren naar de WSUS-server geforceerd worden met de volgende instructie:

wuauclt /detectnow

Indien windowsupdate.log nog altijd dezelfde fout vertoont, 0x8024400A, is het aan te raden de procedure die net beschreven werd nogmaals uit te voeren. Ik heb situaties gezien waarbij de verbinding pas werkte na de derde keer registreren van de dll’s.

Nog een laatste probleem:

Failed to get session from datastore: 80004002
Failed to Unserialize from data store: 80004002
InitAUComponents Failed, will restart AU in 30 mins: 80004002
AU Restart required....

In combinatie met:

Trying to make out of proc datastore active
Out of proc datastore is now active
Failed to get session from datastore: 80004002
Failed to Unserialize from data store: 80004002
AU Restart required....
Out of proc datastore is shutting down
Out of proc datastore is now inactive

Tot dan toe was dit het meest hardnekkige probleem waarbij ook het opnieuw registreren van de dll’s niet werkte. De oplossing was echter heel eenvoudig. Om de een of andere reden kon dit toestel geen nieuwe cliëntbestanden van de WSUS-server downloaden. Echter, bij het surfen naar http://windowsupdate.microsoft.com werden ze wel gedownload waardoor de connectie terug tot leven kwam.

Het eerste wat er gebeurt bij het surfen naar windowsupdate.microsoft.com is dat de site via ActiveX controleert of de betreffende computer de meest recente Windows update-software gebruikt. Als dit niet het geval is wordt de nieuwe versie automatisch geïnstalleerd. Daarna kan er online gezocht worden op updates. Dat laatste hoeft niet uitgevoerd te worden om ons WSUS-probleem op te lossen. Uiteindelijk willen we niet updaten via de site van Microsoft maar wel via onze interne server. Wanneer op de windowsupdate-site de keuze verschijnt tussen snel of aangepast updates uitvoeren zijn we ver genoeg op de site geweest en zou de windowsupdate.log al andere meldingen moeten vertonen in plaats van de fouten.

Het kan gebeuren dat na het oplossen van dit probleem, 80004002, er een ander probleem optreedt namelijk onze bekende 0x8024400A. Vanaf dan kan de oplossing met het opnieuw registreren van de dll’s geprobeerd worden.

Voor WSUS geldt nog een belangrijke regel: een beetje (veel) geduld. Wanneer bijvoorbeeld een connectie geforceerd wordt met wuauclt /detectnow wil dit niet zeggen dat er binnen de halve seconde resultaat is. Het kan een tijdje duren eer een toestel verschijnt in WSUS of een statusrapport aflevert. Dat geldt ook voor het detecteren en downloaden van updates.

---

Add this page to your favorite Social Bookmarking websites