none
Error when trying to connect to WSUS server - Event ID 7053

    Question

  • When trying to connect to the Update Services console via MMC the Snap-in fails to load. I'm running Windows Server 2012 Standard on a Hyper-V guest. I installed the WSUS role two plus months ago and after what seemed to be an initial GP issue -moved server into and IIS+SQL GP- everything -updates, synchronizations, reporting, groups, etc.- was working well. Just a few days ago (7/9/13), things went awry. The VM was performing poorly -non-responsive to clicks- so I had to force a hard shutdown and cold start. Since then, I've been unable to connect to the WSUS server. Nothing changed to the server configuration that would be an obvious cause to this issue. I did try the instructions in the below error message with no success. I'm using WID and I'm installing Windows updates as we speak.

    The WSUS administration console has encountered an unexpected error. This may be a transient error; try restarting the administration console. If this error persists,

    Try removing the persisted preferences for the console by deleting the wsus file under %appdata%\Microsoft\MMC\.


    System.Net.Sockets.SocketException -- No such host is known

    Source
    System

    Stack Trace:
       at System.Net.Dns.InternalGetHostByName(String hostName, Boolean includeIPv6)
       at System.Net.Dns.GetHostEntry(String hostNameOrAddress)
       at Microsoft.UpdateServices.Internal.SetupInfo.IsServerRemote(String serverName)
       at Microsoft.UpdateServices.UI.SnapIn.Scope.RootScopeNode.ApplyPersistedSettings(PersistedSnapInSettings persistedSettings)
       at Microsoft.UpdateServices.UI.SnapIn.Common.SnapInManager.OnLoadCustomData(AsyncStatus status, Byte[] persistenceData)






    Friday, July 12, 2013 7:49 PM

Answers

  • Somehow, unbeknownst to me, the account password for the Windows Internal Database (WID) had changed disallowing the database to start. I changed the Log on account to Local System, started the database, and all is well. Whew!

    Thanks,

    --Chauncey

    • Proposed as answer by antwesor Wednesday, July 17, 2013 2:59 PM
    • Marked as answer by Chauncey G Smith Jr Wednesday, July 17, 2013 3:01 PM
    Wednesday, July 17, 2013 2:20 PM

All replies

  • System.Net.Sockets.SocketException -- No such host is known

    Nothing changed to the server configuration that would be an obvious cause to this issue.

    While I certainly understand your perception that nothing has changed... a server that was working, and now is not, and provides this very clear and to-the-point error message, suggests otherwise.

    Whatever hostname you're using to connect the console is not being recognized by the machine running that console.

    Questions:

    • Can the machine resolve the hostname of the WSUS server using nslookup?
    • Can you connect to the WSUS server from another console?

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, July 12, 2013 11:23 PM
    Moderator
  • Whatever hostname you're using to connect the console is not being recognized by the machine running that console.

    I'm attempting to connect from the same server running the WSUS console. So, from the WSUS VM Server, Server Manager launches and then from the Tools menu, I simply click on the Windows Server Updates Services command and wait for the console to launch. No explicit specification of a hostname is made on my part.

    • Can the machine resolve the hostname of the WSUS server using nslookup?

    Yes.

    • Can you connect to the WSUS server from another console?

    Although I would like to do this, I have not attempted it as I'm afraid with the way our GP is set up, we may not allow this. I say this because I've attempted to manage other servers via Server Manager on this particular server and communication errors have resulted.


    Saturday, July 13, 2013 2:21 PM
  • Can you connect to the WSUS server from another console?

    Although I would like to do this, I have not attempted it as I'm afraid with the way our GP is set up, we may not allow this.

    There is absolutely no known reason (to me, in eight years) why Group Policy would have any impact on the ability to use a Remote Console to manage a WSUS server, or why RSAT installed on a Win7/Win8 system would be unable to do so (provided the correct firewall configurations are in place), nor even a standalone WSUS console on WinXP/Win7.

    Furthermore, using remote consoles (rather than connecting direct to the server console) is the correct way to manage a server environment.

    I say this because I've attempted to manage other servers via Server Manager on this particular server and communication errors have resulted.

    Well, that's certainly interesting. If the Server Manager on that system is broken, then its broken. Whether it can or cannot connect to remote systems is certainly one consideration; but if the same Server Manager also cannot connect to a local service (assuming the service is actually installed and operating correctly), then I'd say you have an even more critical issue.

    I do not think this is a WSUS issue.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Sunday, July 14, 2013 4:53 PM
    Moderator
  • Somehow, unbeknownst to me, the account password for the Windows Internal Database (WID) had changed disallowing the database to start. I changed the Log on account to Local System, started the database, and all is well. Whew!

    Thanks,

    --Chauncey

    • Proposed as answer by antwesor Wednesday, July 17, 2013 2:59 PM
    • Marked as answer by Chauncey G Smith Jr Wednesday, July 17, 2013 3:01 PM
    Wednesday, July 17, 2013 2:20 PM
  • Somehow, unbeknownst to me, the account password for the Windows Internal Database (WID) had changed disallowing the database to start.

    :-)
    I changed the Log on account to Local System, started the database, and all is well.
    One note of significance: The Windows Internal Database should be running in the context of the Network Service account. The Local System account has elevated rights that the database engine should not have by default.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, July 17, 2013 3:35 PM
    Moderator
  • One note of significance: The Windows Internal Database should be running in the context of the Network Service account. The Local System account has elevated rights that the database engine should not have by default.

    Thanks for the tip, I've changed it.

    One little caveat when I attempted to change the Logon as account to Network Service. I was prompted for a password which I didn't know inherently, so I guessed, entering the Local Administrator account password. It worked, no I'm wondering if this is normal or safe?

    Thanks!

    --Chauncey

    Wednesday, July 17, 2013 4:39 PM
  • One little caveat when I attempted to change the Logon as account to Network Service. I was prompted for a password which I didn't know inherently, so I guessed, entering the Local Administrator account password. It worked, no I'm wondering if this is normal or safe?

    I don't think it's normal. I'm pretty sure the Local System, Local Service, and Network Service account passwords are randomly generated at installation.

    However, given that you've already noted that somebody creatively changed the service account that the WID was executing under ... is it also possible that the same person(s) creatively 'updated' the System and Service account passwords?

    In fact, presuming that was what was done, it's likely that's when the WID got broke, and perhaps whatever other account (assuming it wasn't originally Network Service, which it should have been) got put there was an attempt to 'fix' it all.


    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2013)
    My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
    http://www.solarwinds.com/gotmicrosoft
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Wednesday, July 17, 2013 7:40 PM
    Moderator