locked
SQLServr.exe / wsusutil reset RRS feed

  • Question


  • Hello All,

    First of all, let me begin by saying that I know I committed an oops.  Unfortunately, my attempts to remedy the situation by relying on previous forums, etc., hasn't had a desired effect.  So allow me to explain my situation.

    We have a WSUS Server with about a hundred clients.  Our WSUS Content folder is approximately 9GB.  A few weeks ago, we noticed that MS updates across the board were failing with a 80244019 error; it appeared that WSUS was no longer communicating with our clients.  Following the recommendation from geeks hangout, (I can't post the URL)  I ran a wsusutil /reset. 

    Big mistake. 

    This caused sqlservr.exe to hit the server at about 95-100% for over two weeks.  Eventually, I gave up on any forward progress on the wsusutil reset and terminated the process.  While our CPU usage had returned to normal, I couldn't get any life out of our WSUS service.  It continued to report a database error, and clients were unable to pull updates from it.  Eventually, I figured out that the original problem was a corruption in our .NET 4 updates on the WSUS server.  After repairing them and downloading new .NET 4 updates to the server, clients finally started to pull updates again.

    Unfortunately, sqlservr.exe is still poking its head around and refuses to give in.  After leaving it alone for the weekend, hoping it would finish up and go away, I found today that it's still running.  Thankfully, our clients are at least able to pull updates from the server, but I would like end the sqlservr.exe process since it's taking up a lot of the CPU. 

    Any suggestions?

     

    Tuesday, March 18, 2014 12:26 PM

Answers

  • A few weeks ago, we noticed that MS updates across the board were failing with a 80244019 error; it appeared that WSUS was no longer communicating with our clients.

    Well, strictly speaking, WSUS does not communicate with clients, but rather the clients communicate with WSUS. The 0x80244019 error is an HTTP 404 error, but it can be caused by one of two scenarios.

    • Either the URL for the WSUS server is incorrect, in which nothing is working,
    • or a specific file to be downloaded is missing (in which case the correct remediation is exactly what you did: run WSUSUTIL RESET).

    I ran a wsusutil /reset.

    This caused sqlservr.exe to hit the server at about 95-100% for over two weeks.

    Unfortunately, the RESET command does take exceptionally long to run. This is likely a result of this code having been written back in the days of WSUS v2 (2005) and not being optimized for an update collection that is now close to 10x what it was ten years ago.

    Eventually, I gave up on any forward progress on the wsusutil reset and terminated the process.

    Except, you can't do this. I've tried. The process is self-re-generating. :(

    Eventually, I figured out that the original problem was a corruption in our .NET 4 updates on the WSUS server.

    Ouch.

    Unfortunately, sqlservr.exe is still poking its head around and refuses to give in.  After leaving it alone for the weekend, hoping it would finish up and go away, I found today that it's still running.

    Yes, until that 'reset' fully completes, this will be an unfortunate side effect.

    Any suggestions?

    Begging your forgiveness for using you as a "case study", but this is an excellent example of why it's so critical to properly diagnose an issue and verify the actual cause before throwing a "solution" at the problem.

    In this case, the solution implemented was a solution to one possible cause, but alas, not the actual cause. And, a very "expensive solution" it was.

    Btw, the WSUS product team is aware of this particular utilities deficiencies, along with the Server Cleanup Wizard's "Delete unneeded updates" functionality. Likely both issues stem from similar programmatic or architectural challenges. I have faith that both will be fixed in the not-too-distant future. :-)


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

    • Marked as answer by Alex Lv Monday, March 31, 2014 1:57 AM
    Friday, March 21, 2014 9:26 PM

All replies

  • Addition.  The WSUS experiences a Connection Error every time I try to open it. 

    Here is the error reported:

    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)

    Tuesday, March 18, 2014 3:10 PM
  • A few weeks ago, we noticed that MS updates across the board were failing with a 80244019 error; it appeared that WSUS was no longer communicating with our clients.

    Well, strictly speaking, WSUS does not communicate with clients, but rather the clients communicate with WSUS. The 0x80244019 error is an HTTP 404 error, but it can be caused by one of two scenarios.

    • Either the URL for the WSUS server is incorrect, in which nothing is working,
    • or a specific file to be downloaded is missing (in which case the correct remediation is exactly what you did: run WSUSUTIL RESET).

    I ran a wsusutil /reset.

    This caused sqlservr.exe to hit the server at about 95-100% for over two weeks.

    Unfortunately, the RESET command does take exceptionally long to run. This is likely a result of this code having been written back in the days of WSUS v2 (2005) and not being optimized for an update collection that is now close to 10x what it was ten years ago.

    Eventually, I gave up on any forward progress on the wsusutil reset and terminated the process.

    Except, you can't do this. I've tried. The process is self-re-generating. :(

    Eventually, I figured out that the original problem was a corruption in our .NET 4 updates on the WSUS server.

    Ouch.

    Unfortunately, sqlservr.exe is still poking its head around and refuses to give in.  After leaving it alone for the weekend, hoping it would finish up and go away, I found today that it's still running.

    Yes, until that 'reset' fully completes, this will be an unfortunate side effect.

    Any suggestions?

    Begging your forgiveness for using you as a "case study", but this is an excellent example of why it's so critical to properly diagnose an issue and verify the actual cause before throwing a "solution" at the problem.

    In this case, the solution implemented was a solution to one possible cause, but alas, not the actual cause. And, a very "expensive solution" it was.

    Btw, the WSUS product team is aware of this particular utilities deficiencies, along with the Server Cleanup Wizard's "Delete unneeded updates" functionality. Likely both issues stem from similar programmatic or architectural challenges. I have faith that both will be fixed in the not-too-distant future. :-)


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

    • Marked as answer by Alex Lv Monday, March 31, 2014 1:57 AM
    Friday, March 21, 2014 9:26 PM

  • Hello All,

    First of all, let me begin by saying that I know I committed an oops.  Unfortunately, my attempts to remedy the situation by relying on previous forums, etc., hasn't had a desired effect.  So allow me to explain my situation.

    We have a WSUS Server with about a hundred clients.  Our WSUS Content folder is approximately 9GB.  A few weeks ago, we noticed that MS updates across the board were failing with a 80244019 error; it appeared that WSUS was no longer communicating with our clients.  Following the recommendation from geeks hangout, (I can't post the URL)  I ran a wsusutil /reset. 

    Big mistake. 

    This caused sqlservr.exe to hit the server at about 95-100% for over two weeks.  Eventually, I gave up on any forward progress on the wsusutil reset and terminated the process.  While our CPU usage had returned to normal, I couldn't get any life out of our WSUS service.  It continued to report a database error, and clients were unable to pull updates from it.  Eventually, I figured out that the original problem was a corruption in our .NET 4 updates on the WSUS server.  After repairing them and downloading new .NET 4 updates to the server, clients finally started to pull updates again.

    Unfortunately, sqlservr.exe is still poking its head around and refuses to give in.  After leaving it alone for the weekend, hoping it would finish up and go away, I found today that it's still running.  Thankfully, our clients are at least able to pull updates from the server, but I would like end the sqlservr.exe process since it's taking up a lot of the CPU. 

    Any suggestions?

     


    How to Reset / Stop the  wsusutil.exe  reset   command.

    We had run the Reset command to clear up missing downloads to our update (WSUSContent) files.  The Reset process never did finish after 6-weeks and 2 reboots to attempt to stop it.  The Reset command likely completed its work much earlier, but failed to update the WSUS Configuration Database that it is done.

    This procedure works in terminating the hung process in a Windows 2012 R2 environment, and it may work in others as you are simply changing one table field in the WSUS Configuration Database.  Use at your own risk, but the backout plan is as simple as changing the SUSDB Table entry back to where it was.  Please remember to commit your change to the database and reboot the server to complete the Kill process.

    Use SQL Server Management Studio to open your database.  It works for both WID and SQL.

    -          Instance name for WID 2012:    \\.\pipe\MICROSOFT##WID\tsql\query

    -          Your Instance Name will depend upon your version of Windows/WSUS

    In your database tables for SUSDB, look for the table called: dbo.tbSingletonData.  Right-click this entry and select “edit top 200 rows.”  In the Field “ResetStateMachineNeeded” change the value from “True” to “False.”  Make sure to commit this change – save the database.  Now, close all open windows and reboot your host. 

    Once the host comes back up, check your CPU usage which should now be normalized as the WSUS Reset should now be stopped.  Normal operation should resume which will probably be indicated by files now downloading from Microsoft, or you may force the synchronization to start in the main page of the WSUS Console.

    Brian Kunick

    CISM.HCISPP.ISSMP.CISSP.MCSE.MCSA.Security+


    Tuesday, March 21, 2017 8:58 PM