h0bbel.p0ggel.org

As most serious Windows administrators do, I run WSUS to manage testing and rollout of Microsoft hotfixes for all of the computers at work.

For the most part, WSUS runs great and provides us with a lot features and manageability, but one thing has been bugging me for a while. There is no "native" way of removing stale computer accounts, or even automatically remove computers that has been removed from Active Directory.

Until now, I've been unaware of the sample app called CleanStaleComputers, that comes with the Update Services 3.0 API Samples and Tools download.

The API Samples also include a few other code snippets and examples, but the most useful one is by far the CleanStaleComputers one.

Download and install it on the WSUS server and you'll find the tool located in %ProgramFiles%\Update Services 3.0 API Samples and Tools\CleanStaleComputers\.
Usage is pretty straight forward, but here is an example:


CleanStaleComputers.exe /DAYS:60 /DELETE:NO /PROMPT:NO


This command will move all computers that hasn't contacted the WSUS server in the last 60 days into a "Stale Computers" computer group in WSUS. That makes the task of checking the list of stale computers much easier.

Of course, you can have the tool automatically delete the computers from WSUS as well, but I prefer to look over the list manually and double check the validity of the accounts before I delete them.

Erroneously deleting a compuer account in WSUS isn't that big a deal really, as the computers autoregister themselves again next time they sync anyway.

WSUS is a great tool for administering and deploying Windows updates and patches to your clients and servers, but recent problems are causing my own faith in it to wear a little thin.

A while ago a a new package from Microsoft, the WDS 3.1 update, was mis-tagged by the WSUS team and thus auto-applied to a lot of WSUS users. This has caused lots of problems ranging from network congestion issues to the amount of time needed to remove the WDS package again on clients and servers. I still wonder why WDS is tagged as software for Windows Server 2003 though, as this is clearly a desktop product.

The newest problem is this, as posted in the WSUS blog

The cause of this issue is that, on Sunday evening, Microsoft renamed a product category entry for Forefront to clarify the scope of updates that will be included in the future. Unfortunately the category name that was used included the word Nitrogen in double quotes (appearing as “Nitrogen”). A double quote is a restricted character within WSUS, which created an error condition on the administration console. This issue occurred on many WSUS servers that synchronized with Microsoft servers between 5pm Sunday and 11am Monday Pacific Time.

This problem isn't as bad as the WDS affair, but it still illustrates that bad moves made by Microsoft and the WSUS team can adversely affect your production environment. In itself this isn't a huge issue, and it "autofixes" itself when your WSUS server downloads new updates according to your set schedule. But it seems amazing that a "stay" double-quote can pretty much disable the management console. Input validation guys, please. Also, how on earth did this slip through internal testing?

Again, Microsoft does a good job informing it's users through the WSUS blog and they are very open in explaining what has happened. If you do use WSUS in your environment, be sure to add the WSUS Blog to your feed reader now. You will get informed there if any problems arise.

WSUS as a product is of such a nature that it requires you to trust it, and to trust that the maintainers behind the Microsoft infrastructure that powers it. We've now had two issues in the last month, both of them should never have happened and with good testing/quality control regimes in place at Microsoft should never have been pushed out to it's corporate users. Both of these should have been avoided and caught long before customers where affected.

It's clear that Microsoft can not continue to make mistakes like this. They are directly responsible for this, and needs be sure that their customers trust the management solution.

Others are echoing my worries about the future of WSUS, especially Eriq Oliver Neale who has the same problems with trust and WSUS:

Wait, did I just say that running WSUS increases the risk vector for my clients? I thought the entire purpose of WSUS was to help reduce the risk vector for my clients. Ironic.

Some times you run across applications that makes your work as a system administrator that much easier, and last night VMTS Patch Manager really came to the rescue. Due to some problems encountered during the day, I had to reboot one of our ESX hosts and decided it would be a good time to do another patch run and get my ESX hosts updated.

Normally I've done patching the hard way (which by the way is way easier in ESX 3.x compared to 2.x), which basically consists of downloading the patches from VMware onto a http or ftp reposiitory, and then using esxupdate, from the host, to fetch the updates and apply them to the host. You also need to open up the builtin firewall and put your hosts in maintenance mode. If you want all the details, have a look at the Patch Management for ESX Server 3 PDF from VMWare. In itself this is a pretty straight forward job, but it does require that you keep track of the updates manually and apply them manually.

VMware will release a new VMware Update Manager with the new 3i and 3.5 versions, but for now there is no real automation tool provided with the stock Virtual Infrastructure 3 package. As is natural, many administrators deploy scripted solutions to manage the task of updating their hosts and have successfully been able to automate patch deployment that way, but there is a tool freely available that takes care of all this in one single package.

VMTS Patch Manager provides both a way to download all available patches into a local repository and then scan your hosts to see which patches are required. If there are any that needs to be deployed, it will take care of that for you as well. It can put your hosts in maintenance mode, do the required firewall changes and apply the patches. I successfully patched both our hosts, by using the patch manager, last night without any problems.

VMTS Patch Manager can also do upgrades like upgrading your ESX 3.0 hosts to the latest 3.0.2 version and then apply any patches that has been released since the 3.0.2 release. The tool itself works like any other Windows application, and it really does make the job of maintaining your ESX server patch levels current.

So, until ESX 3i and 3.5 is available, VMTS Patch Manager seems to be the ultimate way of maintaining your ESX host patches! Just remember to update your Virtual Center to the latest version before you attempt to upgrade your ESX version!

Thank you Massimiliano Daneri, your tool provides a great service that for now is missing from the core ESX product!