none
All WSUS Clients Stopped Reporting in on 2/18/2013

    Question

  • 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
    mercredi 6 mars 2013 14:21

Réponses

  • 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:

    1. Set a fresh password on the IUSR_machineName account in Local Users and Groups.
    2. 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.

    jeudi 7 mars 2013 03:54
  • One user said "Just Delete the IUSER_MachineName and Restart IIS by using the command iisreset."

    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.)

    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.

    jeudi 7 mars 2013 03:49

Toutes les réponses

  • 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

    mercredi 6 mars 2013 22:08
  • One user said "Just Delete the IUSER_MachineName and Restart IIS by using the command iisreset."

    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.)

    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.

    jeudi 7 mars 2013 03:49
  • 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:

    1. Set a fresh password on the IUSR_machineName account in Local Users and Groups.
    2. 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.

    jeudi 7 mars 2013 03: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 19 mars 2013 14:54
  • 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

    mardi 2 avril 2013 20:51