All WSUS Clients Stopped Reporting in on 2/18/2013
-
mercredi 6 mars 2013 14:21
Hello,
We have ~600 computers in our WSUS setup. All of the systems have stopped reporting in as of 2/18/2013. I'm not entirely sure what has changed because I'm only allowed to remote into the server for WSUS administration. The people who do manage the servers say that they haven't changed anything, but obviously something has changed.
The clients are all getting an error code of 800710DD (screenshot):
Here's a copy of the update log from a client as well.
2013-03-06 09:17:34:110 900 4c4 AU Triggering AU detection through DetectNow API
2013-03-06 09:17:34:126 900 4c4 AU Triggering Online detection (interactive)
2013-03-06 09:17:34:126 900 998 AU #############
2013-03-06 09:17:34:126 900 998 AU ## START ## AU: Search for updates
2013-03-06 09:17:34:126 900 998 AU #########
2013-03-06 09:17:34:141 900 998 AU <<## SUBMITTED ## AU: Search for updates [CallId = {FB824AA9-83D9-427F-92FD-69A4C30E9CBF}]
2013-03-06 09:17:34:141 900 874 Agent *************
2013-03-06 09:17:34:141 900 874 Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates]
2013-03-06 09:17:34:141 900 874 Agent *********
2013-03-06 09:17:34:141 900 874 Agent * Online = Yes; Ignore download priority = No
2013-03-06 09:17:34:141 900 874 Agent * Criteria = "IsInstalled=0 and DeploymentAction='Installation' or IsPresent=1 and DeploymentAction='Uninstallation' or IsInstalled=1 and DeploymentAction='Installation' and RebootRequired=1 or IsInstalled=0 and DeploymentAction='Uninstallation' and RebootRequired=1"
2013-03-06 09:17:34:141 900 874 Agent * ServiceID = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7} Managed
2013-03-06 09:17:34:141 900 874 Agent * Search Scope = {Machine}
2013-03-06 09:17:34:141 900 874 Setup Checking for agent SelfUpdate
2013-03-06 09:17:34:141 900 874 Setup Client version: Core: 7.6.7600.256 Aux: 7.6.7600.256
2013-03-06 09:17:34:141 900 874 Misc Validating signature for C:\Windows\SoftwareDistribution\SelfUpdate\wuident.cab:
2013-03-06 09:17:34:157 900 874 Misc Microsoft signed: Yes
2013-03-06 09:17:34:204 900 874 Misc WARNING: SendRequest failed with hr = 800710dd. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
2013-03-06 09:17:34:204 900 874 Misc WARNING: WinHttp: SendRequestUsingProxy failed for <http://rnumvpr022.nala.roche.com/selfupdate/wuident.cab>. error 0x800710dd
2013-03-06 09:17:34:204 900 874 Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x800710dd
2013-03-06 09:17:34:204 900 874 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x800710dd
2013-03-06 09:17:34:204 900 874 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x800710dd
2013-03-06 09:17:34:219 900 874 Misc WARNING: SendRequest failed with hr = 800710dd. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
2013-03-06 09:17:34:219 900 874 Misc WARNING: WinHttp: SendRequestUsingProxy failed for <http://rnumvpr022.nala.roche.com/selfupdate/wuident.cab>. error 0x800710dd
2013-03-06 09:17:34:219 900 874 Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x800710dd
2013-03-06 09:17:34:219 900 874 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x800710dd
2013-03-06 09:17:34:219 900 874 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x800710dd
2013-03-06 09:17:34:235 900 874 Misc WARNING: SendRequest failed with hr = 800710dd. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
2013-03-06 09:17:34:235 900 874 Misc WARNING: WinHttp: SendRequestUsingProxy failed for <http://rnumvpr022.nala.roche.com/selfupdate/wuident.cab>. error 0x800710dd
2013-03-06 09:17:34:235 900 874 Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x800710dd
2013-03-06 09:17:34:235 900 874 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x800710dd
2013-03-06 09:17:34:235 900 874 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x800710dd
2013-03-06 09:17:34:266 900 874 Misc WARNING: SendRequest failed with hr = 800710dd. Proxy List used: <(null)> Bypass List used : <(null)> Auth Schemes used : <>
2013-03-06 09:17:34:266 900 874 Misc WARNING: WinHttp: SendRequestUsingProxy failed for <http://rnumvpr022.nala.roche.com/selfupdate/wuident.cab>. error 0x800710dd
2013-03-06 09:17:34:266 900 874 Misc WARNING: WinHttp: SendRequestToServerForFileInformation MakeRequest failed. error 0x800710dd
2013-03-06 09:17:34:266 900 874 Misc WARNING: WinHttp: SendRequestToServerForFileInformation failed with 0x800710dd
2013-03-06 09:17:34:266 900 874 Misc WARNING: WinHttp: ShouldFileBeDownloaded failed with 0x800710dd
2013-03-06 09:17:34:266 900 874 Misc WARNING: DownloadFileInternal failed for http://rnumvpr022.nala.roche.com/selfupdate/wuident.cab: error 0x800710dd
2013-03-06 09:17:34:266 900 874 Setup WARNING: SelfUpdate check failed to download package information, error = 0x800710DD
2013-03-06 09:17:34:266 900 874 Setup FATAL: SelfUpdate check failed, err = 0x800710DD
2013-03-06 09:17:34:266 900 874 Agent * WARNING: Skipping scan, self-update check returned 0x800710DD
2013-03-06 09:17:34:282 900 874 Agent * WARNING: Exit code = 0x800710DD
2013-03-06 09:17:34:282 900 874 Agent *********
2013-03-06 09:17:34:282 900 874 Agent ** END ** Agent: Finding updates [CallerId = AutomaticUpdates]
2013-03-06 09:17:34:282 900 874 Agent *************
2013-03-06 09:17:34:282 900 874 Agent WARNING: WU client failed Searching for update with error 0x800710dd
2013-03-06 09:17:34:282 900 4ec AU >>## RESUMED ## AU: Search for updates [CallId = {FB824AA9-83D9-427F-92FD-69A4C30E9CBF}]
2013-03-06 09:17:34:282 900 4ec AU # WARNING: Search callback failed, result = 0x800710DD
2013-03-06 09:17:34:282 900 4ec AU # WARNING: Failed to find updates with error code 800710DD
2013-03-06 09:17:34:282 900 4ec AU #########
2013-03-06 09:17:34:282 900 4ec AU ## END ## AU: Search for updates [CallId = {FB824AA9-83D9-427F-92FD-69A4C30E9CBF}]
2013-03-06 09:17:34:282 900 4ec AU #############
2013-03-06 09:17:34:282 900 4ec AU Successfully wrote event for AU health state:0
2013-03-06 09:17:34:282 900 4ec AU AU setting next detection timeout to 2013-03-06 19:17:34
2013-03-06 09:17:34:282 900 4ec AU Successfully wrote event for AU health state:0
2013-03-06 09:17:34:282 900 4ec AU Successfully wrote event for AU health state:0
2013-03-06 09:17:39:266 900 874 Report REPORT EVENT: {73C09357-5AF3-41BB-9D50-C322B3ED98E8} 2013-03-06 09:17:34:266-0500 1 148 101 {D67661EB-2423-451D-BF5D-13199E37DF28} 1 800710dd SelfUpdate Failure Software Synchronization Windows Update Client failed to detect with error 0x800710dd.
2013-03-06 09:17:39:313 900 874 Report CWERReporter::HandleEvents - WER report upload completed with status 0x8
2013-03-06 09:17:39:313 900 874 Report WER Report sent: 7.6.7600.256 0x800710dd D67661EB-2423-451D-BF5D-13199E37DF28 Scan 101 Managed
2013-03-06 09:17:39:313 900 874 Report CWERReporter finishing event handling. (00000000)
The server event logs don't show anything unusual on that particular day.
Any advice on what to look for? I'm 75% sure SCCM isn't on the server because I don't think we even use that at my company. Is IIS corrupt somehow?
Thanks,
James
- Modifié zeroSPace mercredi 6 mars 2013 14:23 typo
Toutes les réponses
-
mercredi 6 mars 2013 22:08
Hi James,
there's a thread here http://social.technet.microsoft.com/Forums/en-US/winserverwsus/thread/82672a1d-0b8c-4ec2-8019-c3433ee043b7/ which describes the problem you are seeing.
One user said "Just Delete the IUSER_MachineName and Restart IIS by using the command iisreset."
Ian Broadbent
-
jeudi 7 mars 2013 03:49Modérateur
Sadly, though, that is exceptionally BAD advice as deleting the IUSR_machineName account will break all anonymous access (which is exactly what the clients need), and running iisreset will not fix the break caused by deleting that account. Furthermore, this will then require the recreation of the account, setting of the password, and re-initializing every instance of a v-root on that IIS installation that requires anonymous access. (There are several in WSUS alone.)One user said "Just Delete the IUSER_MachineName and Restart IIS by using the command iisreset."
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
SolarWinds Head Geek
Microsoft MVP - Software Distribution (2005-2013)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.- Marqué comme réponse Clarence ZhangModerator mercredi 27 mars 2013 09:40
-
jeudi 7 mars 2013 03:54Modérateur
Any advice on what to look for? I'm 75% sure SCCM isn't on the server because I don't think we even use that at my company. Is IIS corrupt somehow?
When 600 clients all start failing on the same day at approximately the same time, the server is, undoubtely the culprit no matter what may or may not appear in the logs.
As for the 0x800710DD error, that's an Access Denied error, which hasn't occurred much of late, but when it occurs due to a server side fault it is almost always caused because somebody has performed 'security tweaks' on the WSUS server, specifically one of two causes:
- removing the NT AUTHORITY\Authenticated Users group from the BUILTIN\Users group, or
- having changed the IUSR_machineName password.
The first is easily remediable and easy to check, so verify that Authenticated Users is still a member of the Users group.
If it is, then the latter is impossible to check, and somewhat tedious to remediate:
- Set a fresh password on the IUSR_machineName account in Local Users and Groups.
- Update the instance of the IUSR_machineName password on every v-dir in IIS that requires anonymous access. (On a WSUS v-root it's every v-dir except APIRemoting30.)
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
SolarWinds Head Geek
Microsoft MVP - Software Distribution (2005-2013)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.- Marqué comme réponse Clarence ZhangModerator mercredi 27 mars 2013 09:40
-
mardi 19 mars 2013 14:54
Thanks for the tips. I've looked into the matter further and I have discovered that the server hasn't been patched since July of 2011!!!
We've put in a request with our datacenter to have it patched. I'm assuming that there could be a mismatch between the level of patching for the WSUS and the server.
I'll let you know how it goes once the patches come down.
James -
mardi 2 avril 2013 20:51
The patching of the server didn't help. We're going to open a case with Microsoft. I'll try to keep updating here in case it helps anyone else.
James
.png)
