Menu
Patching made painless

Patching made painless

One of the primary drawbacks of the Windows platform is the amount of time it takes to keep up with patches for the operating system and the inextricably entwined Internet Explorer Web browser. New patches are issued so frequently that they could be dubbed “the patch of the week”.

That may be an exaggeration, but there’s no question that keeping a fleet of desktops and servers running Windows 2000 or Windows XP up-to-date requires near-constant monitoring. Or it did until now.

Microsoft first tried to address this problem five years ago, when it introduced the Windows Update service with the release of Windows 98. But the original Windows Update left much to be desired as a solution for managing patches in a business environment. There was no simple way to enforce patch installation through policies, and end users were required to make installation decisions.

As the desktop OS of preference evolved into Windows 2000 and later Windows XP, many shops chose not to give end users the administrative rights necessary to execute Windows Update. Instead, they adopted the practice of creating patched OS images and deploying them when convenient with software distribution utilities from Microsoft or a third party. This often entailed tedious scripting or complex maneuvering to keep the distribution server itself current.

But finally, a simpler, cheaper way is available to perform Windows patch management. Microsoft’s new SUS (Software Update Services) 1.0 gives businesses the ability to create a Windows Update server within their own intranets. Best of all, it’s free.

SUS uses the latest version of the Automatic Update client, installed as part of either Windows 2000 Service Pack 3 or Windows XP Service Pack 1, which allows redirection to the SUS server through use of an Active Directory group policy, or a modification of the desktop’s or server’s registry keys. SUS only accepts content that’s signed by Microsoft, so security is much less of an issue than it might otherwise be. Microsoft’s publicly announced target for SUS is the small and medium business, but the scalability features belie that. Smaller installations can comfortably run SUS on a machine providing other services, such as a domain controller or a computer running Microsoft Small Business Server 2000.

SUS 1.0 — with the Service Pack integrated — is downloadable from Microsoft and installs easily on a server with Windows 2000 or the forthcoming Windows 2003 Server and the IIS (Internet Information Services) Web server. One small catch exists for those deploying a new machine with Windows 2000: The SUS administration pages require Internet Explorer 5.5 or later, so when setting up the new server, one might as well bite the bullet and install IE 6 because IE 5.5 is no longer available through Windows Update. Another minor “gotcha” is that one must have local administration rights to the SUS server to view the SUS admin pages. Installation of SUS went smoothly after we’d updated the browser on our SUS server.

We then created an Active Directory Group Policy that pointed our clients to the SUS server and configured IIS on the SUS server to log client connections to the newly installed Windows Update binary on our intranet. This part of the set-up and configuration took only a few minutes, so we moseyed off for an hour or so while SUS synchronised itself with Microsoft’s own Windows Update servers and pulled down all known critical updates and security roll-ups for Windows 2000, Windows XP, and Internet Explorer 5, 5.5, and 6.

SUS can be configured in multiple tiers, with one server pulling content directly from Microsoft or a manually configured distribution point and other SUS servers connecting to the master or the offline source. This allows networks not directly connected to the Internet to use SUS, and it also provides a way to stage the deployment of patches. It’s fine to have clients and servers loading patches as soon as they’re available, but in a production environment, it’s a good idea to test patches before a general rollout to minimise the chance of conflicts with custom applications or other site-specific issues.

Once we’d approved the downloaded content through the SUS administration Web pages, we set up some clients with fresh Windows installations — meaning the appropriate Service Pack was installed but no further patches were applied — and let them run against the SUS server, which they did without incident.

SUS is definitely not a replacement for software distribution tools such as Microsoft’s Systems Management Server or other third-party products. But SUS fills an important role by taking over the more-valuable but less-demanding task of allowing desktops and servers to pull updates as soon as they’re vetted for fitness by corporate IT, while minimising the impact on users and admin­istrators alike. Not only does SUS rate our Deploy recommendation, but how can you beat the price?


Follow Us

Join the newsletter!

Error: Please check your email address.
Show Comments