Nathan's Occasional Blog

Windows Server 2008 Core is an old new concept in the Windows world.  We’ve spent the last couple decades trying to put a fancy user interface onto our computers to make tasks easier for the user.  The server world has followed suit as well with the same GUI advancements.  And I’ll be the first to admit that I like working in a GUI for most small or one-off tasks on a server.

The problem is that with all that code to make a pretty interface you get a much larger attack surface for your environment.  All of a sudden you need to apply patches Internet Explorer and media player to your critical SQL server!

So along comes Windows Server 2008 and the option of a “Core” installation.  Server Core removes pretty much all of the user interface components leaving a greatly reduced attack (and patch) surface that you have to manage.  I recently heard the comment that if Windows Server 2000 had a Core install mode only 40% of patches for the platform would apply (60% for Win2003).  Check out more about Server Core here.

So great – I’ve got a lot fewer patches to deploy … but I DO need to still deploy patches.  I work in a smaller-scale environment; roughly 50 servers in my core datacenter with another 40+ scattered in local offices around the country and the UK, and about 650 users.  We’re not big enough to have the right folks on staff to run Microsoft’s System Center Configuration Manager (formally SMS) to push out applications and patches to computers.

Instead we rely on Windows Server Update Service (WSUS) to manage the Windows Update agent already on each machine (the local agent actually does the install).  Our user and dev machines automatically download and install patches, but our servers just download the patches (pre-staged for install) so we can manually manage when each server installs and reboots.  This way we make sure servers are rebooted in the right order and are around to ensure everything comes back up.  🙂

The problem comes in with Server Core … there’s no way for you to see the “you have updates to install” notice in the system tray when you log on to the computer because, well, there’s no system tray!  I looked and looked and couldn’t figure out how to still leverage WSUS to push patches out and kick off an install.

I recently attended an event on the Microsoft campus in nearby Redmond where I had access to some of the key players in the Windows 2008 product world.  The event is under NDA so I can’t give a lot of details, but let’s just say I’M TOTALLY SOLD!

I reached out to a couple of Microsoft contacts from that event to get some help and was rewarded with a link to an MSDN article the solves my issue!  Effectively you get a command-line representation of the Windows Update user interface by calling a VBscript!

http://msdn2.microsoft.com/en-us/library/aa387102(VS.85).aspx

Copy the code to a Notepad window and save the file as a .vbs file accessible on the Server Core machine you want to patch (I copied it to a directory on the local disk).  From the Server Core command line execute that script via ‘cscript nameofscripthere.vbs’ and let it work it’s magic.  You’ll see the patches it scans and finds you need (according to your WSUS group policies … guessing this would work against the public Microsoft Update servers too), will download them (or leverage the pre-staged bits already downloaded), and then ask if you if you want to proceed to install.  Give it a “Y” and you’re on your way!

Special thanks to Brendan and Paul for finding this solution!

😀

As an aside, you can also manually download each patch’s .MSU installer to the Server Core box (using a file copy from another machine) and then call each patch individually from the command line using ‘wusa.exe patchnamehere.msu’.  You’ll actually still get the standard Windows Update user interface dialog where you can prompt it not to reboot.  You can even use a couple command line options to make wusa.exe run in a quite mode and not reboot, thus allowing you to apply multiple patches via a batch script.  Still kind of clunky though.

The problem is that the WSUS/WUA tools don’t download the .MSU files (or if they do they store them in an “exploded” form) so you can’t use that combination to push out the patches to your boxes for deployment – thus the need for the VBS script above and my 4 day search for a good solution.