locked
WSUS Connection Error - Event 7053 and Large SUSDB.mdf (13Gb) RRS feed

  • Question

  • When I load the WSUS admin console I get the error:

    Error:Connection Error

    An Error Occurred trying to connect to the WSUS server.  The error can happen for a number of reasons.  Check connectivity with the server.

    There is a corresponding error log in the event viewer with event ID 7053.

    Some background: WSUS is running on a Windows SBS 2008 server, with 25 machines connected, 8Gb RAM, xeon 2.5GHz processor. A week ago I noticed the server was running slowly, on investigation found error logs for WSUS and Sharepoint. Further investigation revealed the SQL db's and related log files had grown massively (Sharepoint log file was 30Gb and we don't even use sharepoint) and SUSDB was 15Gb. Slow server, big database files, low on space on C drive so decided I should clean up these issues first. Sharepoint files have been reduced to <1Gb and Sharepoint errors have now stopped. Server is also running faster. I tried to run server cleanup wizard in WSUS console, but would always crash out before completion with a connection error. Once ran for 12 hours with only a few percent of the progress bar complete. So then I tried to Shrink the database from SQL Server Management Express which knocked off a few Gb but still no joy from WSUS Server cleanup wizard (always fails on the last stage of 'removing uneeded files'). So then tried chainging some of the WSUS settings to minimise the updates that it would attempt to synchronise, in the hope that this might clear some of the un-needed items from the database. But the console crashed while the changes were being made. Now the WSUS console will not connect at all and constantly gives the error as per above. So far I've tried:

    1) Deleting the WSUS configuration file (C:\Users\**\AppData\Roaming\Microsoft\MMC\WSUS). Tried this many times with various combinations of re-staring WSUS services and complete server reboot

    2) Detaching and re-attaching the SUSDB

    3) Detaching and re-attaching the WSUSdb

    4) Running from a remote console

    5) Checking .net framework settings in IIS Isapi Filters

    6) Running the database cleanup script (https://gallery.technet.microsoft.com/scriptcenter/6f8cde49-5c52-4abd-9820-f1d270ddea61)

    7) Restarting all relevant services and resetting IIS

    8) nslookup - returns the correct address

    9) Checked the connection settings (port 8530 configured in IIS)

    10) Disconnected and reconnected from the console snapin

    11) Used the WSUSUTIL command line tool.

    - checkhealth

    revealed a new error in the event viewer with event id 12032

    'The server synchronisation web server is not working'

    - listfrontendservers revelaed

    'Server: xx.xx.local, IsActive:False, IsMaster:True

    I've been at this a while, learnt a lot, but not enough to fix the problem. I feel that it could just be a timeout issue, the connection tries for a few minutes and then fails, due to the size of the db, and perhaps shortage of resournces. When I first started out with these issues it would sometime fail to connect, and sometime connect OK, but now it never connects. I can't be 100% certain but the change point seemed to be after the console crashed during the settings change. Can anyone give me any more suggestions? The full error from event viewer is:

    '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.NullReferenceException -- Object reference not set to an instance of an object. Source Microsoft.UpdateServices.UI.SnapIn Stack Trace: at Microsoft.UpdateServices.UI.SnapIn.Pages.ServerSummaryPage.backgroundWorker_RunWorkerCompleted(Object sender, RunWorkerCompletedEventArgs e)'

    Wednesday, November 26, 2014 12:16 AM

Answers

  • My mistake, I should have written:  In SQL server management express I detached and re-attached to the SUSDB database and also to the WSUS content folder.

    Uh... okay... but I'm still confused. There's no detach/attach to the content folder.

    'Ouch!' doesn't sound good.  Sounds like I may have made a bad situation worse.  What's my next course of action?

    Make sure the database service and the WSUSService are running, and let the RESET task run its course. You can monitor the CPU utilization on the sqlservr.exe process. When it goes back idle, that would be a likely indication that the RESET has completed. (The absence of files in ~\WSUSContent will be a good clue too.)

    At the moment none of the clients are configured to use WSUS, client automatic updates are disabled in group policy.  So my main concern is to clean this whole mess up so it isn't interfering with the operation and resources of the server for it's main function, which is as a file, print and exchange server.

    Well, if the WSUS services are not currently needed for production, then you may find it more expeditious to simply uninstall the role and delete the database. (Which will, of necessity, also terminate the RESET task running inside the database engine.)

    At a minimum, as a short term solution, you might also consider this approach:

    • Disable the WSUSService.
    • Detach the SUSDB (because you still need the SQL instance for SharePoint).
    • Put a Big Red Tag on the machine noting that WSUS is still installed, but dysfunctional, and needs to be repaired/cleaned-up.

    Your biggest challenge, of course, is that this is an SBS box. :-)


    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.

    Wednesday, November 26, 2014 10:19 PM
  • My mistake again, the folder was actually called WSS_Content which I mistook for WSUS_Content.

    The sqlservr process is running at about 13%, but this is now 3 or 4 days since this event occurred and I have shut down and restarted a few times since then, can it still be running?  The WSUS_Content folder hasn't changed size in the last 24 hours.

    Anyway I have uninstalled the role and deleted the database.  Thanks for all your help.


    • Edited by LevDev Thursday, November 27, 2014 1:26 AM
    • Marked as answer by Steven_Lee0510 Sunday, December 7, 2014 1:28 PM
    Thursday, November 27, 2014 1:18 AM

All replies

  • I cannot speak to the SharePoint question, but almost certainly the WSUS 15GB SUSDB.mdb (plus the unimagineable size of the ~\WSUSContent folder) is a natural manifestation of how the SBS2008 product group (unfortunately) tried to automate the existence of WSUS for that environment.

    As a result, there are years and years of legacy approved updates in the database that cannot be deleted by the Server Cleanup Wizard because of the existence of approvals.

    I would suggest starting with my blog post Removing unneeded update approvals, followed by another execution of the Server Cleanup Wizard (which may actually require *many* successive executions), and then following up with the additional articles regarding filesystem defragmentation and database reindexing.


    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.

    Wednesday, November 26, 2014 3:48 AM
  • 

    Thank you for your reply.

    The problem is I can't use the WSUS administration console as it wont connect to the server (as described above).  So I don't currently have the facility to remove the uneeded update approvals, or run the server cleanup wizard.  The problem I need to resolve is how to get the admin console connected to the server and database so I can start to clean things up.

    Wednesday, November 26, 2014 8:52 AM
  • The problem is I can't use the WSUS administration console as it wont connect to the server (as described above).
    My misunderstanding.

    I tried to run server cleanup wizard in WSUS console, but would always crash out before completion with a connection error. Once ran for 12 hours with only a few percent of the progress bar complete.

    These are the standard ASP.NET Timeout Issues discussed in my blog series.

    So then tried chainging some of the WSUS settings to minimise the updates that it would attempt to synchronise, in the hope that this might clear some of the un-needed items from the database. But the console crashed while the changes were being made.

    Any chance you recall what it was you changed, or were changing, when it crashed?

    3) Detaching and re-attaching the WSUSdb

    What is this? SUSDB (which you noted in #2) is the WSUS database. I don't know what you're referring to here.

    4) Running from a remote console

    Does a remote console connect?

    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.

    Wednesday, November 26, 2014 3:22 PM
  •  

    Any chance you recall what it was you changed, or were changing, when it crashed?

    I think I was changing the 'Update Files and Languages' settings to 'Do not store update files locally; computers instal from Microsoft update'

    When I clicked ok, the program hung and eventually I had to force it to shutdown.

    What is this? SUSDB (which you noted in #2) is the WSUS database. I don't know what you're referring to here

    The WSUS content is saved in location: D:\WSUS\WsusContentThe WSUS database is saved in C:\WSUS\SUSDB\UpdateServicesDbFiles\SUSDB.mdf (with the corresponding log file SUSDB_log.ldf).  The SUSDB.mdf file is currently 13Gb, the log file is 0.6Gb and the WSUSContent folder is 6Gb

    Does a remote console connect?

    No

    Wednesday, November 26, 2014 4:18 PM
  •  

    Any chance you recall what it was you changed, or were changing, when it crashed?

    I think I was changing the 'Update Files and Languages' settings to 'Do not store update files locally; computers instal from Microsoft update'

    Ouch!

    When I clicked ok, the program hung and eventually I had to force it to shutdown.

    No, actually, when you clicked OK you forced the execution of a WSUSUTIL RESET, which there's no way to terminate, and may take days to complete, and once it's completed, it will likely have deleted your entire ~\WSUSContent folder tree ... from which you'll then have to recover.

    What is this? SUSDB (which you noted in #2) is the WSUS database. I don't know what you're referring to here

    The WSUS content is saved in location: D:\WSUS\WsusContentThe WSUS database is saved in C:\WSUS\SUSDB\UpdateServicesDbFiles\SUSDB.mdf (with the corresponding log file SUSDB_log.ldf).  The SUSDB.mdf file is currently 13Gb, the log file is 0.6Gb and the WSUSContent folder is 6Gb

    Okay let me try this a different way....

    2) Detaching and re-attaching the SUSDB

    3) Detaching and re-attaching the WSUSdb

    What's the difference between these two statements?


    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.

    Wednesday, November 26, 2014 8:24 PM
  • 
    

    My mistake, I should have written:  In SQL server management express I detached and re-attached to the SUSDB database and also to the WSUS content folder.

    'Ouch!' doesn't sound good.  Sounds like I may have made a bad situation worse.  What's my next course of action? 

    At the moment none of the clients are configured to use WSUS, client automatic updates are disabled in group policy.  So my main concern is to clean this whole mess up so it isn't interfering with the operation and resources of the server for it's main function, which is as a file, print and exchange server.

    By the way I read your blog, it's very useful and informative, shame I didn't come across it before.  I must have reviewed a few hundred webpages about WSUS issues and I never came across it.

    Wednesday, November 26, 2014 9:54 PM
  • My mistake, I should have written:  In SQL server management express I detached and re-attached to the SUSDB database and also to the WSUS content folder.

    Uh... okay... but I'm still confused. There's no detach/attach to the content folder.

    'Ouch!' doesn't sound good.  Sounds like I may have made a bad situation worse.  What's my next course of action?

    Make sure the database service and the WSUSService are running, and let the RESET task run its course. You can monitor the CPU utilization on the sqlservr.exe process. When it goes back idle, that would be a likely indication that the RESET has completed. (The absence of files in ~\WSUSContent will be a good clue too.)

    At the moment none of the clients are configured to use WSUS, client automatic updates are disabled in group policy.  So my main concern is to clean this whole mess up so it isn't interfering with the operation and resources of the server for it's main function, which is as a file, print and exchange server.

    Well, if the WSUS services are not currently needed for production, then you may find it more expeditious to simply uninstall the role and delete the database. (Which will, of necessity, also terminate the RESET task running inside the database engine.)

    At a minimum, as a short term solution, you might also consider this approach:

    • Disable the WSUSService.
    • Detach the SUSDB (because you still need the SQL instance for SharePoint).
    • Put a Big Red Tag on the machine noting that WSUS is still installed, but dysfunctional, and needs to be repaired/cleaned-up.

    Your biggest challenge, of course, is that this is an SBS box. :-)


    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.

    Wednesday, November 26, 2014 10:19 PM
  • My mistake again, the folder was actually called WSS_Content which I mistook for WSUS_Content.

    The sqlservr process is running at about 13%, but this is now 3 or 4 days since this event occurred and I have shut down and restarted a few times since then, can it still be running?  The WSUS_Content folder hasn't changed size in the last 24 hours.

    Anyway I have uninstalled the role and deleted the database.  Thanks for all your help.


    • Edited by LevDev Thursday, November 27, 2014 1:26 AM
    • Marked as answer by Steven_Lee0510 Sunday, December 7, 2014 1:28 PM
    Thursday, November 27, 2014 1:18 AM
  • The sqlservr process is running at about 13%, but this is now 3 or 4 days since this event occurred and I have shut down and restarted a few times since then, can it still be running?

    Yep.

    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.

    Monday, December 1, 2014 2:35 PM