WUS Server Tryout

–I never finished trying out WUS, its still installed on the server, but I didn’t get it work, and havn’t had time to get back to it! Please bear that in mind if you read or follow this article!–

–This article is not ‘finished’–


Microsoft has released Windows Update Services Open Evaluation.


Registration will get you the 70mb setup.

Wus seems to be a completely different beast than SUS, reading though the features summery, it appears to have adressed practicly every major issue SUS had.

I thought I would give WUS a spin, see what its like, and I will blog my progress here. This post should not be regarded as a guide or walk though, though you may find it usefull nonetheless.


SUS uses BITS 2.0 to download updates more efficiently. Before installing WUS you need to get the BITS 2.0 update. Windows Server 2003 requires a restart for this.

You will need an SQL database for the download metadata (not the actual updates), and for storing configuration information about WUS and about clients.

I have an unnused instance of SQL that I will be using, using the standard port.


The WUS installation will create a database for in the instance, I dont have to manually edit the settings.

SUS requires at least 6gb of free disk space for content,but 30gb is recommended.

I like to see what I am installing, so I always extract the single-file executables microsoft produces. This also often exposes and MSI file, which is rather handy for software distribution, but not in this case.







The final screen gives the option of launching the configuration screen.


Lets have a look at what WUS has installed on IIS


Notice the SelfUpdate virtual directory at the bottom? That will be important for later..

Under the options tab of the main menu, I can select settings for syncronisation.


Here I hit the products that WUS will update, and I deselect anthing exept for Windows XP and Server 2003 family, as I dont run anything else in my little network.  I select a large number of new classifications, just to see what kinda stuff that is.


I also change the default languages WUS downloads at the bottom om this screen, and confirm that only approved downloads will be downloaded to my server.


I have chosen to install WUS on a non-standard port. The primary reason for this is security, and also you dont want SUS to install itself all over any website you might already be running on port 80 on the server. WUS clients will work just find using the nonstandard port of 8530, however, the self update functionality of Automatic Updates clients, an all versions of Windows Prior to XP SP2, need to selfupdate from a website on port 80.

Since we are running SUS on the nondefault port, we need to create a virtual directory on our default port 80 site, where to host the so called ‘update tree’, for Automatic Update clients to look for in order to self-update.

In this beta version of WUS, a script is provided especially for this.

For the beta release, you can perform all the steps in this section, “Step 2: Create folders in the file system of the WUS server” and the next section, “Step 3: Setup virtual directories in the Web site on port 80 of the WUS server” by running the following script:

cscript WUS install drive:program filesMicrosoft Windows Update ServicesSetupInstallSelfupdateOnPort80.vbs

If this script doesn’t work, and it didn’t in my case, you need to follow the manual steps in the deployment guide, but its no biggy. You need to create 2 virtual directories on your default port 80 website: SeflUpdate, and ClientWebService, see the deployment guide for details.

Final steps for the web server setup is DNS if you hadn’t sorted this yet. Both A records in your DNS server, and the proper host headers configured per IIS site.
I end up with http://fs_srv1.fluffshack.local:8530/wusadmin/ for my admin site, http://fs_srv1.fluffshack.local:8530 for the actual WUS update location, and http://static.fluffshack.local for my default website, whereunder the SelfUpdate virtual directories can be found.
I use Fully Qualified domain names here as best practice, but you dont have to.
(Note: http://static.fluffshack.local is a site that was already running on this server, you can find it publicly at http://static.jemimus.net .. of course the Selfupdate and ClientWebService virtual directories are under there, but all it needs are read and run script rights.)
I have defined a new OU in Active Directory to host the computer account, so I can apply a test policy to the computer.
The test policy will do 2 things: First it will make sure that any clients that fall under it, recieve the SUS Client component.
This software is needed for clients that are either Windows 2000 SP2 and lower, and Windows XP without SP1. Anything above that already has a version of Automatic Updates that will auto-update to a WUS version, apon first contact with the WUS server.

And that is what the group policy is for secondly, to apply the settings that will make Automatic Updates behave the way we want it to.

Windows XP Service Pack 2 clients, already have the version of the Automatic Updates client that WUS would otherwise install, and it support all the client-side settings natively.

In order to apply WUS client side settings via group policy, we also need to use a newer administrative template for Group policy, than the one that was installed by default with Windows Server 2003.

Windows XP Service Pack 2 computers already contain the updated ADM file, simply copy this file to the same location on your server, or the pc from which you edit the policy in MMC (or the Group Policy Management Console). The ADM files are always located on %systemroot%windowsinf

The file is called wuau.adm

When loading the new ADM file for the first time, and this may be true of any ADM files that come with Windows XP SP1 or SP2, you may recieve and error box that says the following:

The following entry in the [strings] section is too long and has been truncated.
This is simply the Group Policy editor not being able to deal with these newer ADM templates, this bug is known under KB 842933, and you can get the fix on that KB page also.
I set up the group policy object I have linked, with the SUS client MSI as assigned software, and I fill in the SUS/WUS options that I want to be enforced.