Susdb.mdf file too big on a Windows SBS 2008 server


  • I One of my customers is running Windows 2008 Small Business Server. Windows Update Contant folders had been correctly moved away from C drive soon after installation of the server (WSUS Content). That folder is about 8 GB big (small network, 8 computers). The susdb.mdf file however, is still on the C drive and is a whopping 15.1 GB big. I believe this is not according to plan. I have done some server cleanup through the specific WSUS interface, but the biggest chunk just hangs. What can I do? None of the suggestions I found have worked.

    Kind regards,

    Wouter Pinkhof

    Wouter Pinkhof PINKH bvba,

    Thursday, December 20, 2012 5:35 PM


All replies

  • Hi,

    How to Move WSUS Content and Database Files to a Different Volume for Windows Server Essentials and Small Business Server:



    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    Monday, December 24, 2012 3:16 AM
  • The susdb.mdf file however, is still on the C drive and is a whopping 15.1 GB big.

    I do find it somewhat incredulous that a SUSDB.mdf file on a Small Business Server could grow to 15GB+ in size.

    I cannot imagine any scenario in which the 30,000+ updates synchronized by a default SBS2008 server, in combination with the default groups, and auto-approvals, and the maximum 75 clients with the default WUAgent policies, could produce a 15GB database. The idea that =8= clients could do this is near impossible. (In fact, I can't recall that I have ever seen a 15GB SUSDB.mdf!)

    It is possible that an SBS2008 Premium Edition server with WSUS installed to the SQL Server Workgroup Edition instance (not the Windows Internal Database) could produce a 15GB+ SUSDB.LDF (transaction log) file, if the WSUS database were inadvertently created as a Full Recovery database.

    In any event, as is the natural behavior of SQL Server, merely running the Server Cleanup Wizard is not going to shrink the file size. In fact, merely running the Server Cleanup Wizard on an SBS2008 server isn't going to do much of anything useful without first removing the thousands of legacy approvals that were likely generated from the automatic approval rules enabled by default. Assuming those thousands of approvals were removed, and the updates actually declined, the SCW might remove a few hundred rows from the database, but that's still not going to shrink a 15GB+ MDF file. Finding out why there's a 15GB+ MDF file really is the first step to identifying an appropriate solution.

    Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
    SolarWinds Head Geek
    Microsoft MVP - Software Distribution (2005-2012)
    My MVP Profile:
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Friday, December 28, 2012 3:01 AM
  • Mine is 13.9GB, small network, 10 people. Simply incredulous...

    Tuesday, April 30, 2013 11:03 PM
  • 11GB here. And we don't even use it...
    Thursday, May 02, 2013 9:36 AM
  • I hve this same issue, running out of room on C drive with a SBS 2008 server and I have moved all data from the C drive that you can move with the SBS consel to another drive and yet this SUSDB file on the c:\wsus\susdb\updateservicesdbfile\ is 13 gigs I would like to reclaim some of that because email has stopped because there is only 600 megs free on the server.

    how can this DB be reduced or moved?

    Brandon Dillon

    Wednesday, May 22, 2013 12:05 AM
  • how can this DB be reduced or moved?

    First we have to figure out why it's so large; luckily on an SBS system we have a couple of readily available known conditions.

    1. Decline any unneeded updates -- this likely will include several thousand Definition Updates. "Unneeded" is defined as any update reported as "100% Installed/NotApplicable" and superseded.
    2. Run the Server Cleanup Wizard to delete expired updates and old revisions. (This may take multiple runs if the SCW times out performing the task, just restart the SCW and let it run some more)
    3. Run the Server Cleanup Wizard a 2nd time to delete files freed up by the thousands of updates that were declined in Step #1.
    4. Verify that the Client Detection Frequency is in a reasonable range. (Anything less than six hours is pointless.)
    5. Manually delete any computers in All Computers that are not operational. (The Server Cleanup Wizard can do this for machines out-of-service more than 30 days, but in an SBS environment where you probably know every client system by sight, it might be better to visually verify what's there and what ought not be.)
    6. Using SQL Server Management Studio, inspect the actual amount of data storage consumed by the data, and compare that to the physical side of the MDF file. If the actual data consumption is less than 80% of the physical database file size, you may get some benefit from shrinking the database file. If there's <20% free space, though, it's not worth the effort.
    7. After shrinking the database, if applicable, stop the SQL Server service hosting the WSUS database and defragment the filesystem hosting the WSUS database.
    8. Restart the SQL Server service and run the WSUS DB Maintenance utility to reindex the database and recalculate table statistics.

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

    Thursday, May 30, 2013 12:03 AM
  • Is 29gb a record then?

    This is an 8 PC (+1 SBS 2008 server) network.

    I'm only 2 hours into looking at it. It's taken 2 hours to get to the desktop after a UPS failure, due to two separate mirrored disks (partitions) mirroring themselves back to partitions on one single other large disk (= the big disk acts like the most fragmented disk you've ever come across in your life, and takes 2 hours to boot to a desktop, and nearly half an hour to present a mouse cursor).

    Monday, July 21, 2014 6:39 PM
  • Is 29gb a record then?

    Yeah... pretty much.

    The good news is that the detailed information you have provided allows us to rule out a database in FULL RECOVERY mode, and knowing that it's only -10- clients, allows us to fully attribute the database consumption to the number of updates, revisions, and approvals contained within the database (plus, potentially, an overload of client reporting events if the client detection interval has been modified).

    One unique consideration on SBS systems is Definition Updates.. which is exactly WHY approval maintenance is so important.

    Consider this.... in any given week of Defender, MSE, and Forefront updates that there are approximately 60-70 unique Definition Updates, and all of them are automatically approved.

    Now.. multiply that by 52 weeks (1yr), or 104 weeks (2yr), or 208 weeks(3yr), or 312 weeks (4yr), which doesn't even account for the possibility that this SBS2008 deployment is over four years old...

    Not impossible at all that four or more years worth of Everything-Synchronized/Everything-Approved updates on an SBS2008 server could generate a 30GB database (excluding any client reporting events).

    Bottom line... same discipline applies. Clean up the legacy approvals and junk, then run the Server Cleanup Wizard one task at a time and expect to endure <em><strong>several</strong></em> cycles of timeouts while performing the "Delete unneeded updates..." task.

    Lawrence Garvin, M.S., MCSA, MCITP:EA, MCDBA
    SolarWinds Head Geek
    Microsoft MVP - Software Packaging, Deployment & Servicing (2005-2014)
    My MVP Profile:
    The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.

    Tuesday, July 22, 2014 12:41 AM
  • I've inherited support for a server with 32.3GB. Ridiculous...


    Monday, December 12, 2016 3:56 AM
  • I have 60gbs. I win.
    Friday, March 10, 2017 3:25 PM
  • Mine is 17 GB, and it's not even doing anything. We have all Windows 10 machines, which WSUS 3 on Windows SBS 2011 doesn't even work with.  So I don't care WHY it is so big.  I just want to get rid of it.

    Can someone post what else I have to do so that deleting the MDF file will not cause problems?  I have disabled the "Update Services" service. Is SQL going to still be looking for the MDF file though, for example?

    Friday, March 17, 2017 6:10 PM