WSUS Client (Server or Workstation) Reset Settings/Cookie Script

Imaging the server or workstation clients in VMware or by othe means leaves the WSUS client session cookie in the registry.  Once the new imaged server/workstation is then connected back to WSUS the session cookie points the orginal computer object.  This will only update one system in WSUS and the name will flip flop as each system tries to update itself in WSUS which leaves you wondering "It was there just a moment ago??"

The following script resolves this be resetting client WSUS settings outside of GPO enforced WSUS location:

REM stop the Automatic Updates service
net stop wuauserv
 
REM Delete SusClientID and AccountDomainSid registry keys
SET WU_KEY=HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate
reg delete %WU_KEY% /v SusClientID /f
reg delete %WU_KEY% /v  AccountDomainSid /f
 
REM Delete registry keys may contain old SUS info
reg delete “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update” /f
 
REM Start the Automatic Updates service
net start wuauserv
 
REM Roll the WU Client…
wuauclt /resetauthorization /detectnow

Windows Update suddenly failing with error 0x80244019? (Windows 7 and Server 2008 R2)

Since installing updates yesterday, some of our Windows 7 and 2008 R2 servers refuse to connect to our WSUS again and, instead, reports the unknown error 0x80244019.The problem happens only with our local WSUS. The Windows support website on the error suggests: If you receive one of these errors while downloading updates, the most common cause is a computer virus that has turned off Windows Update, or another service on your computer that is needed by Windows Update. I'm gonna vote No on that one. My WindowsUpdate.log shows the following: 2012-09-13 13:00:52:738 892 5c0 PT +++++++++++ PT: Synchronizing server updates +++++++++++ 2012-09-13 13:00:52:738 892 5c0 PT + ServiceId = {3DA21691-E39D-4DA6- 8A4B-B43877BCB1B7}, Server URL = http://SRV-PDC/ClientWebService/client.asmx 2012-09-13 13:00:52:769 892 5c0 PT WARNING: Cached cookie has expired or new PID is available 2012-09-13 13:00:52:769 892 5c0 PT Initializing simple targeting cookie, clientId = a6c96caf-d9ca-4f31-a003-827e7089ff64, target group = Server, DNS name = srv-exchange.porta.haseke.de 2012-09-13 13:00:52:769 892 5c0 PT Server URL = http://SRV-PDC/ SimpleAuthWebService/SimpleAuth.asmx 2012-09-13 13:00:52:957 892 5c0 PT WARNING: GetAuthorizationCookie failure, error = 0x80244019, soap client error = 10, soap error code = 0, HTTP status code = 404 2012-09-13 13:00:52:957 892 5c0 PT WARNING: Failed to initialize Simple Targeting Cookie: 0x80244019 2012-09-13 13:00:52:957 892 5c0 PT WARNING: PopulateAuthCookies failed: 0x80244019 2012-09-13 13:00:52:957 892 5c0 PT WARNING: RefreshCookie failed: 0x80244019 2012-09-13 13:00:52:957 892 5c0 PT WARNING: RefreshPTState failed: 0x80244019 2012-09-13 13:00:52:957 892 5c0 PT WARNING: Sync of Updates: 0x80244019 2012-09-13 13:00:52:957 892 5c0 PT WARNING: SyncServerUpdatesInternal failed: 0x80244019 2012-09-13 13:00:52:957 892 5c0 Agent * WARNING: Failed to synchronize, error = 0x80244019 2012-09-13 13:00:52:957 892 5c0 Agent * WARNING: Exit code = 0x80244019 And, actually, another support article caught my eye: You cannot download updates when you access the Windows Update Web site from a Windows XP-based computer that is behind a firewall or a proxy server That article refers to XP, but I had to recently tweak the WinHTTP settings on our servers and clients in order to resolve a CAC (Common Access Card) Authentication issue with our Virtual VMs to resolve yet another issue. I fixed that access problem by running: netsh winhttp set proxy proxy-server="http=www-proxy:8080" bypass-list= "domain.example.com" So, I'm assuming Windows Update uses WinHTTP as well, and my changes prevent it from working properly. But even after adjusting my bypass-list to "*.domain.example.com;<local>", Windows Update refuses to function.

Answer

Seems like a reboot was all that was needed after adjusting the bypass-list, which must contain <local> so the WinHTTP proxy is bypassed for your local WSUS installation: netsh winhttp set proxy proxy-server="http=www-proxy:8080" bypass-list= "domain.example.com;<local>" Alternatively, if you're already setting the correct proxy in IE (through group policy, for example), you can simply import those settings into WinHTTP: netsh winhttp import proxy source=ie To inspect your own current WinHTTP proxy settings, run netsh winhttp show proxy.