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.
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.
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 http://192.168.1.250/exchange) so it's enough to create an record in dns (eg. webmail.kicks.be) that points to this server to solve the problem.
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.
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.
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 192.168.1.50 192.168.1.250 HTTP HEAD /iuident.cab?0510161640 HTTP/1.1 63 21.675353 192.168.1.250 192.168.1.50 HTTP HTTP/1.1 200 OK 64 21.679003 192.168.1.50 192.168.1.250 HTTP GET /iuident.cab?0510161640 HTTP/1.1 65 21.701785 192.168.1.250 192.168.1.50 HTTP HTTP/1.1 200 OK (application/octet-stream) 66 21.701913 192.168.1.250 192.168.1.50 HTTP Continuation 67 21.701950 192.168.1.50 192.168.1.250 TCP 1082 > http [ACK] Seq=248 Ack=3160 Win=17520 Len=0 68 21.702171 192.168.1.250 192.168.1.50 HTTP Continuation 69 21.739558 192.168.1.250 192.168.1.50 HTTP Continuation 70 21.739651 192.168.1.50 192.168.1.250 TCP 1082 > http [ACK] Seq=248 Ack=6080 Win=17520 Len=0 71 21.739895 192.168.1.250 192.168.1.50 HTTP Continuation 72 21.739954 192.168.1.250 192.168.1.50 HTTP Continuation