WSUS 3.0, Windows Internal Database, and Memory Usage
I’m posting this here, not because I think anyone will care, but because if I ever have to do this again I want to be able to remember it!
With the release of WSUS 3, Microsoft switched from MSDE to Windows Internal Database. I did the upgrade for a client on Tuesday, and came back to finish patching some of his systems today… lo and behold, the sqlservr.exe process was eating 1.6GB of RAM. Thanks, Microsoft.
I’d seen this before with the full versions of the SQL Server product, and was pretty sure I could fix it… till I realized that it was no longer MSDE. Initially, googling showed me how to do this with OSQL… but guess what? It wasn’t present in the Binn directory where sqlservr.exe was running. Thanks again, Microsoft… I mean, why would ANYONE need to reconfigure a running instance? Let’s save space and not include management tools.
After more googling, here’s what I found:
1) Install the management tools for SQL Server. You can find the necessary files here: Microsoft SQL Server Native Client and Microsoft SQL Server 2005 Command Line Query Utility.
2) Run the sqlcmd utility and change the config options.
c:\Program Files\Microsoft SQL Server\90\Tools\binn\SQLCMD.EXE -S -E
1> sp_configure 'show advanced options', 1;
2> reconfigure;
3> go
Configuration option 'show advanced options' changed from 0 to 1. Run the RECONFIGURE statement to install.
1> sp_configure 'max server memory', 512;
2> reconfigure;
3> go
Configuration option 'max server memory (MB)' changed from 2147483647 to 512. Run the RECONFIGURE statement to install.
1> exit
Voila. No more freaking RAM for you, sqlservr.exe. 
Thank you very much for the information. It was very useful.
Comment by flatron — November 9, 2007 @ 11:30 am
I too found the OSQL method but needed an alternative solution. This is just the job, many thanks.
Comment by Leigh — December 7, 2007 @ 5:42 am
Great Information
I just did the upgrade from WSUS 2 to v3 and it (tried) installed the 2005 db without the above tools.
The database failed to upgrade because of a permissions problem however to change the permissions you need the tools you have listed above.
Comment by John — August 28, 2008 @ 5:01 pm
Gotta use this command with the new WSUS:
sqlcmd -S \\.\pipe\MSSQL$MICROSOFT##SSEE \sql\query –E
Comment by Moktarino — October 28, 2008 @ 4:25 pm
The command to execute sqlcmd didn’t work for me. I had to use this instead:
SQLCMD.EXE -E -S \MICROSOFT##SSEE
Everything else worked as specified. Thanks!
Comment by Jason Shuler — November 3, 2008 @ 8:55 am
Trying this on SBS 2008 (win 2008 x64)as windows internal database is taking 2.1GB mem!!!
Can’t get any of the sqlcmd.exe scripts to work. Anyone found a way?
Comment by Gerard — November 4, 2008 @ 4:06 pm
Ran into this issue on W2K8 and, like the above poster, had problems with the supplied command lines. Found this one:
sqlcmd -E -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
Comment by Jamie — March 20, 2009 @ 7:13 pm
Thanks a lot! Very useful information!
Especially when you need a quick WSUS install on an older server after a virus outbreak
Comment by Xhan — July 9, 2009 @ 2:48 am
It’s worth pointing out to SBS2008 users that your server will typically be set up to grab everything available for local distribution. In my case that led to 53GB of drivespace getting chewed and 5GB of RAM to track it. Using the WSUS console, configure your server to just track critical updates and then run the server clean up wizard. It should scale back to an acceptable level. If you drop its max RAM requirement before this you will thrash your paging file when running the cleanup.
Comment by Todd — August 31, 2009 @ 7:37 am
Thanks a lot, eating 1.6 GB of 4GB is just….
The command
sqlcmd -E -S np:\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
worked on my SBS2003 with WSUS 3.0 SP2
Comment by Gregor Streng — September 3, 2009 @ 1:07 pm
I have found that the memory use builds over time, and by just restarting the sql service the memory usage returns to an acceptable amount. I have added a stop/start batch file to the scheduled tasks…
Comment by WdLuhn — April 8, 2010 @ 12:43 pm