While I’ve not been a huge fan of WSUS in the past, it’s been growing on me over the last year or so. Specifically, I’ve been really pleased with how WSUS 3.0 and SBS have been integrated (well, so long as you don’t hit a problem with the integration, which can then lead to a LOT of work to recover or repair or reinstall, but that’s a different post for a different day). But there are still challenges to keeping WSUS in check and keeping it from having unintended impacts on those same SBS servers.

Fortunately, most of the commonly-encountered problems with WSUS 3.x can be dealt with by running the Server Cleanup Wizard from the Update Services console. [NOTE: If you have never run the Server Cleanup Wizard in WSUS on a server that's been in production for a while, I recommend running the wizard manually and only select one category at a time. The first run can clean a LOT of information out of the WSUS environment, and it can take a VERY long time to complete.] But in this day of automating tasks, I don’t want to manually run the Server Cleanup Wizard on a regular basis as it can still take some time to complete the supplemental runs even after the first (and potentially longest) pass has been completed.

Well, there are two mechanisms for automating the Server Cleanup Wizard process on an SBS 2008 server (and other servers running WSUS for that matter). The first method that I’ll discuss below is fairly easy to google, but the second doesn’t show up in searches related to SBS 2008 (that I’ve been able to find at the time that I put this post together), so I’m going to document it here.

Let me start by saying that a lot of people who have implemented one of these two methods seem to be in agreement that these processes (or a variation thereof) should be included within WSUS itself and not relegated to what amounts to an add-on for maintenance and management. I’m in the same category, and really would like the WSUS team to look at providing tools with WSUS to be able to schedule the maintenance out of the box.

The first solution I ran across last year was a tool uploaded to Codeplex: http://wsus.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=17612. This is a complied tool that will perform operations on the WSUS implementation based on command-line parameters that are passed to the tool when executed. It can run each of the cleanup tasks in the Server Cleanup Wizard individually or in groups, and also includes an SQL script that the tool can call to perform maintenance on the WSUS database file itself. I’ve deployed this in testing on a few SBS 2003 installations where I have WSUS 3.x running, and it’s been able to keep the WSUS installation in check rather nicely. My only beef with the tool is that since its a compiled executable, it’s impossible to tweak its operation beyond what the developer has coded into the tool. Currently, I can’t think of any WSUS tasks that I’d like to do that this tool cannot, but if an update to WSUS changes the way some of these tasks can be called, it’s possible that the tool might cease to function or not be able to handle new functionality and need an update from the author. I’ve also not run this on SBS 2008 yet simply because I don’t have a test box that I could run this on to make sure it doesn’t misbehave on that platform. It might work just the same on SBS 2008 as SBS 2003, but I can’t confirm that first-hand, so I haven’t pushed in out.

The second solution I ran across (again, not in an SBS 2008 search) is a PowerShell script that calls the Server Cleanup Wizard functions from WSUS directly. Since PowerShell is enabled by default on SBS 2008 out of the box, and since I can get into the code directly, I went ahead and implemented this script on my own production server, because I honestly hadn’t run the Cleanup Wizard on it in I don’t know how long. The script came from the Microsoft Technet Script Center at http://gallery.technet.microsoft.com/ScriptCenter/en-us/fd39c7d4-05bb-4c2d-8a99-f92ca8d08218. I have a Tools folder on the root of the second partition of every server I deploy, and I added a Scripts folder in that to house this script. I named the script WSUS_Cleanup.ps1 and copied the contents from the Script Center page into the file. I then opened a Command Prompt as Adminstrator and ran “powershell.exe WSUS_Cleanup.ps1″ on the server. After a long wait (like I said, I hadn’t run the Server Cleanup Wizard in a looooooong time),  I got output from the script that showed the results of each of the steps it ran within the script (as listed on the Script Center page, the option to remove old computer from WSUS has been commented out).

Being the kind of guy who likes to review the results of processes once they complete, I build a quick and dirty batch file wrapper for the PowerShell script. Yes, I probably could have done the whole thing in PowerShell, but I’m still a bit of a PS newbie, so I relied on my comfort with batch files to get this wrapper done. Here’s the contents of the WSUS_Cleanup.bat that I put on the server:

@echo off
@echo Starting cleanup: %date% %time% >> d:\tools\scripts\WSUS_Cleanup.log
powershell.exe d:\tools\scripts\WSUS_Cleanup.ps1 >> d:\tools\scripts\WSUS_Cleanup.log
@echo Finished cleanup: %date% %time% >> d:\tools\scripts\WSUS_Cleanup.log

The batch file writes the current date and time to a log file that I created in the same Scripts folder where the other pieces are, then calls PowerShell to run the cleanup script and appends the output of that process to the log file as well. Once that finishes, the current date and time are again appended to the log. Now I can see when the script ran, what it did when it ran, and how long it took to complete.

Either of these tools are easily adaptable to running as scheduled tasks or as scripts from your favorite RMM tool. THE WSUS_Cleanup from Codeplex has a couple of advantages over the PowerShell script. One, you can select which components of the Cleanup Wizard you wish to run by adjusting the command line call to the tool. With the PowerShell script as written, you have to modify the script and comment or uncomment each of the tasks. (Yes, a savvy PowerShell person should be able to modify that script to mimic the behavior of the Codeplex tool, and as I’ve mentioned, I’m not that guy. Yet.) Second, the Codeplex tool has the SQL maintenance script included which can be run within the scope of the Codeplex tool. The PowerShell script does not include anything for SQL maintenance on the actual database files. Again, someone with SQL skills could easily script up and automate a process to do the same thing, and again that’s not me.

Given that PowerShell is getting more and more visibility in the Server 2008 world, I’m going to be focusing (when possible) on dealing with automation tasks that make use of PowerShell or other native scripting tools rather than rely on someone else to build an executable file. Not to say that the WSUS_Cleanup tool on Codeplex is a bad thing. I’m probably going to keep that on my 2003-based systems until there’s a reason not to. But for my 2008 deployments, I’m going to stick with PowerShell for WSUS maintenance. If nothing else, I get an excuse to learn more about PowerShell and keep my WSUS installations in good working order.