Patch Management

SUS : Software Update Services

It's all good and well to setup applications without user intervention and to automate Software Deployment, but in these days, software is old the moment you install it. So it needs patching and updating. We could include statements in our setup scripts to update the software after it's been installed, and in some cases we might just do that. Still, implementing a centralised patch management system could be convenient.

Here we investigate the use of Microsoft's SUS (Software Update Services) to keep our windows operating systems up to date - which gives the system administrator control over which updates and services packs the workstations will install. It saves a bit of internet bandwith as well, as the patches and updates are only downloaded once and distributed to the workstations from a server on the LAN, in stead of having 100 workstations go to the Windows Update website.

However, there may be a problem, as SUS expects an Internet Information web server on port 80 for it to work. The Automatic Updates Client on the workstations will be pointed to the SUS server with http://srv01. The SUS setup routine also executes an ISS lockdown, hardening ISS a bit and removing a lot of the default folders and configurations. In a small business with only one server for all services, the ISS on this server may already be serving Outlook Web Access and/or an intranet website - presumably also on the default WWW port 80, so we may have a problem.

Setting up SUS

When you run the SUS installer without any preparation, SUS takes over the default website of the Internet Information Server and configures it to manage automatic updates. However, Exchange is left intact and Outlook Web Access continues to work, even on the default http port 80, as the Outlook Web Access site it is identified by the /Exchange/[username]/ portion of the URL. When we also want to run an intranet website on this server, things get even more messy : portions of SUS will end up in the intranet directory structure, URL's to the intranet home page and to the SUSAdmin page won't work, etc. It's a mess.
SUS in ISS default website

It would seem a good idea to create a separate website for the intranet before installing SUS, but even then, SUS interferes with the intranet, SUS subdirectories and files end up in the intranet directories, therefore URL's to SUS and SUSAdmin don't work, etc.



The sollution is quite simple : accept the mess - then work with it. So we will create 2 additional web sites, install SUS and see where the SUS installer puts the SUS stuff, then configure the other site to become the intranet website. If you already have an intranet, simply keep a copy of the files somewhere, and delete the site from ISS Manager. Then, start all over :

If all is well, you will be able to use http://SRV01 as target for Automatic Update clients, and http://intranet for the company's intranet. Obviously, that will only work if you provide name resolution for 'SRV01' and 'Intranet'. You may find that http://SRV01/Exchange/ for Outlook Web Access no longer works, because we had to assign the "SRV01" header to the SUS website. The default website (where exchange web lives) is still accessible via its IP address (like so it's enough to create an record in dns (eg. that points to this server to solve the problem.
setting the update location for Automatic Updates

Note that all sites are accessible via tcp port 80, the standard port for http, so there is no need to add port numbers into the URL's.

Configure the workstations

Configuring workstations to use your SUS server (in stead of the default Windows Update Site) is done through policies - preferably Active Directory Group Policy so you can manage it centrally and auomatically. It can also be done through local policies (for computers not in a domain), or through registry settings - re Microsoft Knowledge Base article 328010. setting the update location for Automatic Updates

To check that indeed the Automatic updates work on the client side, you can trigger an update by following the instructions in Microsoft Knowledge Base article 32669 : how to force Automatic Updates to run. Then, look in the registry for [HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update], and find NextDetectionTime. You can have a packet analyser such as ethereal running to follow the communication between the workstation and (hopefully) the SUS server you've set up - if that checks out, you'll see your wokstation talk to your SUS server and retrieve updates via HTTP.

        Time        Source                Destination           Protocol Info
     62 21.600837         HTTP     HEAD / HTTP/1.1
     63 21.675353          HTTP     HTTP/1.1 200 OK
     64 21.679003         HTTP     GET / HTTP/1.1
     65 21.701785          HTTP     HTTP/1.1 200 OK (application/octet-stream)
     66 21.701913          HTTP     Continuation
     67 21.701950         TCP      1082 > http [ACK] Seq=248 Ack=3160 Win=17520 Len=0
     68 21.702171          HTTP     Continuation
     69 21.739558          HTTP     Continuation
     70 21.739651         TCP      1082 > http [ACK] Seq=248 Ack=6080 Win=17520 Len=0
     71 21.739895          HTTP     Continuation
     72 21.739954          HTTP     Continuation

Koen Noens
August 2005
Alle rechten voorbehouden
back to TOC