Skip to content

Saga of WSUS

I think there are not many organizations which have more than ten Windows-based computers and at least one server and do not use Windows Software Update Services. A brilliant piece of software, really. But every brilliance can be somehow spoiled sometimes. In case you are on the systems administration side, this “flaw” means that someone must begin investigation, find a solution, step into the next problem, resolve it just to run into other and so on.

Of course my tale is all about one investigation in my experience. All began when I decided to build a downstream WSUS server synchronizing approvals with un upstream one. Quite a simple procedure, actually (especially on Windows 2008 R2), which I was able to perform without any problems and the first synchronization was a success. But when I tried to synchronize servers once more… Well, it failed. The event log stated:

SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParse

Moreover, the WSUS console began to glitch:

image

This message was shown here and there in the console from time to time with the same error in the event log and one more error:

    The WSUS administration console was unable to connect to the WSUS Server via the remote API.
   
    Verify that the Update Services service, IIS and SQL are running on the server. If the problem persists,try restarting IIS,SQL, and the Update Services Service.
   
    System.Net.WebException — The operation has timed out
   
    Source
    System.Web.Services 
        Stack Trace:
       at System.Web.Services.Protocols.WebClientProtocol.GetWebResponse(WebRequest request)
       at System.Web.Services.Protocols.HttpWebClientProtocol.GetWebResponse(WebRequest request)
       at Microsoft.UpdateServices.Internal.DatabaseAccess.ApiRemotingCompressionProxy.GetWebResponse(WebRequest webRequest)
       at System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String methodName, Object[] parameters)
       at Microsoft.UpdateServices.Internal.ApiRemoting.ExecuteSPGetUpdateServerStatus(Int32 updateSources, Boolean includeDownstreamComputers, String updateScopeXml, String computerTargetScopeXml, String preferredCulture, Int32 publicationState, Int32 propertiesToGet)
       at Microsoft.UpdateServices.Internal.DatabaseAccess.AdminDataAccessProxy.ExecuteSPGetUpdateServerStatus(UpdateSources updateSources, Boolean includeDownstreamComputers, String updateScopeXml, String computerTargetScopeXml, String preferredCulture, ExtendedPublicationState publicationState, UpdateServerStatusPropertiesToGet propertiesToGet)
       at Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetStatus(UpdateSources updateSources, Boolean includeDownstreamComputers, UpdateScope updatesToInclude, ComputerTargetScope computersToInclude, UpdateServerStatusPropertiesToGet propertiesToGet)
       at Microsoft.UpdateServices.Internal.BaseApi.UpdateServer.GetReplicaStatus(UpdateSources updateSources)
       at Microsoft.UpdateServices.UI.SnapIn.Common.CachedUpdateServerStatus.GetFreshObjectForCache()
       at Microsoft.UpdateServices.UI.AdminApiAccess.CachedObject.GetFromCache()

   at Microsoft.UpdateServices.UI.SnapIn.Pages.ServerSummaryPage.backgroundWorker_DoWork(Object sender, DoWorkEventArgs e)

(I know you won’t read this section but may be someone will google it)

Ok, SQL or network timeout on quite a piece of hardware and in a relatively fast network for just a WSUS? Awful! A little time and googling around later I sought I found a solution: “just download some scripts and run them on your box”. Unfortunately, WSUS installation program doesn’t install locally anything to connect to the SQL (yes, I know it is not an MS SQL server, but let us name it so) server instance, therefore I needed to find some solution. Giving a SQL a network exposure where it is not absolutely necessary has never been my idea of sound systems administration and I don’t like to use command line where it is possible to use GUI (yeah, I am a lazy sonofagun, though my IT start was all-in-FreeBSD/Linux), so I decided to download MS SQL Server Management Studio Express. What I like in MS products: they usually are install in the “nextnextnext” fashion and the installation fails quite rarely. But that was not the case – I started the wizard, went through options, answered yes to request for privilege elevation and…

image

Well, I decided that “never give up” was my slogan that day and tried to solve the mystery. The workaround was easy: just run cmd in elevated mode and run the installer from it:

image

Now, having the SQL Management Studio installed I could, finally, to run the scripts I had downloaded. But how to connect to the DB engine? It was not actually generic SQL server – it was Windows Server internal database, so I had to look for a connection string and I found it:

.pipeMSSQL$MICROSOFT##SSEEsqlquery

From now on all was simple enough: copy the script, paste it into the GUI windows and press “Execute”. The script had been working some time and finished successfully. Do you think all my problems were solved? No way: I still was receiving the error messages, though it happened somewhat less often.

To cut a long story short, the reason for such a behavior was the fact that I hadn’t had the WSUS DB cleaned for a while. After I had gone through Server Cleanup Wizard on both upstream and downstream servers the problem was solved. But that was a long way to victory Winking smile