Interesting - I have some PC's doing the same thing - sometimes I see "Cached PID" in the windowsupdate.log and restarting the Automatic Updates services fixes it, but not always, I'll try this too!
Would it work via PSEXEC? I'm guessing no... From: Bob Fronk [mailto:[email protected]] Sent: Friday, January 16, 2009 11:39 AM To: NT System Admin Issues Subject: RE: handful of PCs not reporting to WSUS Thanks.. will give it a try. From: RM [mailto:[email protected]] Sent: Friday, January 16, 2009 2:18 PM To: NT System Admin Issues Subject: Re: handful of PCs not reporting to WSUS Here's my WSUS fixer script. I've been using this as-is for about two years now to remediate clients that won't "talk" to WSUS. Run it on the client as an admin: sc sdset wuauserv "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)" sc sdset bits "D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)" net stop bits net stop wuauserv SET WU_KEY=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate reg delete %WU_KEY% /v SusClientID /f reg delete %WU_KEY% /v AccountDomainSid /f reg delete %WU_KEY% /v PingID /f reg delete %WU_KEY% /v SusClientIdValidation /f SET WU_KEY= rd /s /q %windir%\Softwaredistribution rd /s /q "%allusersprofile%\Application Data\Microsoft\Network\Downloader" rd /s /q %windir%\SYSWOW64\Softwaredistribution %windir%\system32\regsvr32.exe /s iuengine.dll %windir%\system32\regsvr32.exe /s wuapi.dll %windir%\system32\regsvr32.exe /s wuaueng1.dll %windir%\system32\regsvr32.exe /s wuauserv.dll %windir%\system32\regsvr32.exe /s wuaueng.dll %windir%\system32\regsvr32.exe /s wucltui.dll %windir%\system32\regsvr32.exe /s wups.dll %windir%\system32\regsvr32.exe /s wuweb.dll %windir%\system32\regsvr32.exe /s wups2.dll %windir%\system32\regsvr32.exe /s cdm.dll %windir%\system32\regsvr32.exe /s dispex.dll %windir%\system32\regsvr32.exe /s vbscript.dll %windir%\system32\regsvr32.exe /s scrrun.dll %windir%\system32\regsvr32.exe /s msscript.ocx %windir%\system32\regsvr32.exe /s msxml2r.dll %windir%\system32\regsvr32.exe /s msxml3r.dll %windir%\system32\regsvr32.exe /s msxml.dll %windir%\system32\regsvr32.exe /s msxml3.dll %windir%\system32\regsvr32.exe /s msxmlr.dll %windir%\system32\regsvr32.exe /s msxml2.dll %windir%\system32\regsvr32.exe /s qmgr.dll %windir%\system32\regsvr32.exe /s qmgrprxy.dll cd /d %windir%\system32\wbem for %%i in (*.dll) do RegSvr32 -s %%i net start wuauserv net start bits wuauclt /resetauthorization /detectnow On Fri, 16 Jan 2009 13:53:40 -0500, "Bob Fronk" <[email protected]> said: While confirming install of 08-067 today (approved in October, but just double checking today), I have found a very small number of notebooks that WSUS does not have in the computer listing. Just as though they never reported. However, upon checking a couple of them, they are receiving all updates and the Automatic update is "grayed out" and has the GPO settings. (As they should). So they must be getting updates from WSUS because users cannot connect to Windows Update due to GPO. I have stopped and started the service on the PC and run wuauclt /detectnow but they do not report to WSUS. It appears the common factor is they are all notebooks that connect frequently via VPN. Anyone ever had a similar problem? ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
