Tuesday, August 14, 2007

Virtual machines in WSUS

With it being patch Tuesday, I thought I'd post about a problem we dealt with recently regarding virtual machines and WSUS.

Microsoft Windows Server Updates Service (WSUS) is a Microsoft patch management tool which allows SysAdmin's to distribute security updates to Windows servers, clients, and various Microsoft applications. Our shop uses the web based 2.0 version as we've not yet scheduled the testing of its successor, 3.0, which apparently has a richer administrative interface (it's MMC based).

Recently we've been pushing to migrate Windows based applications running on legacy hardware into virtual machines, using VMware as the hosting environment. These servers, of course, need to be monitored for Microsoft updates. VMware allows the use of Templates to deploy Windows servers in a very efficient manner. A Template is essentially an image of a server you have customized to your specifications (patch level, service packs, security policies, etc) from which you can deploy multiple servers as needed (licensing permitting, of course). The deployed servers are uniquely configured using Sysprep. This eliminates the need to perform server installations from scratch. I'll get into that in a later posting.

I came across an issue recently when deploying Windows servers from one of our Templates. When a new virtual server gets deployed it is added to a WSUS management group and subsequently inherits any patch approvals. However, what I noticed was that each time a server was deployed, the server which was deployed before it vanished from WSUS! Initially I thought maybe something had gone awry when the servers were joined to the domain, however having checked Active Directory all the new server deployments seemed fine. Each new server had an associated object in the domain tree and was assuming a DHCP address before being assigned a static address. What I discovered was that the Windows Update client (which comes by default with a Windows Server installation) obtains a unique SUSClient ID for the server, when under WSUS management. Unfortunately, when each server was deployed from our pre-configured VMware Template, although they successfully joined the domain (using Sysprep) and obtained their own domain SID, the SUSClient ID remained the same. This ID is maintained in the registry key:

HKLM\Software\Microsoft\Windows\
CurrentVersion\WindowsUpdate\SusClientId

(this text has been wrapped due to formatting constraints)

In order to remedy this, I had to use the following procedure for each server:

1. Stop the Automatic Updates Service
2. Browse to the registery key above and delete it
3. Start the Automatic Updates Service
4. Click Start, Run, and enter 'wuauclt /resetauthorization /detectnow'

Each virtual server then showed up individually in the WSUS management console. I'll be working on remedying this in our Templates in the near future.

Happy patching!

No comments: