–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.
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.
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: