Windows Server Update Services

In the same way Ford and other vehicle manufacturers send out recalls for you to return your SUV or coupe to get a part replaced, does WSUS return to Microsoft for a patch, a fix, a service pack or a new function for your computer? The big difference between cars and Windows is that you don't have to take your software back to the store you bought it from every time it croaks. Without WSUS, you'd be going back to the software store at least twice a week; and with the price of gas, we would all go broke.

Of course, being connected to the Internet is a risky business and you need a way to quickly update your servers and desktops before the next tsunami of hostile bits comes bearing down over your DSL lines and cable connections. In fact, Microsoft touts WSUS as "the way to get secure, and stay secure." It's fast, easy to use and clean. In short, it's the software version of Windex in a bottle.

What It Does

So what does WSUS do? For the most part, it does exactly what SUS does, and then some. It connects to Microsoft, gets a catalog of updates and patches that need application to your machines, and then lets you manually or automatically (unattended) update and patch at your will. WSUS, however, goes a lot further with respect to the products it patches. Like SUS, it patches and updates all Windows 2000 and Windows 2003 Server and Desktop products, but it can also patch server and desktop applications, such as SQL Server, Exchange Server and Microsoft Office. It can also technically update non-Microsoft products that are installed on the Windows operating systems.

The products that can currently be updated by WSUS include Office XP, Office 2003, SQL Server 2000 and Exchange 2003; it's likely that when SQL Server 2005 is released in November, it too will support WSUS. More products will be added to the WSUS-compliant list as Microsoft extends them to support WSUS; you will not need to upgrade or redeploy WSUS when the additional applications announce support for it.One of the best things about WSUS is that the client is already installed on your operating system in the form of the Automatic Updates components. Besides the free price tag, this fact is key when considering using WSUS or going with a third-party ISV product that requires its own update client and special installation considerations. The Automatic Updates on the following operating systems fully support WSUS:

WSUS is not a complex application to manage. Let's first take a peek under its hood. For starters, it fully supports the protocols for Advanced Network Optimization. If you regularly download from MSDN subscriber services, then you have experience with this technology when you use the Download tool to receive MSDN products. You can start and stop and interrupt the download process, and it will pick up from the last bit it received. This technology is provided by the Background Intelligent Transfer Service (BITS).

So WSUS will be able to handle network interruptions and work with changes in download and bandwidth quality as needed. In other words, if the network department decided to switch out the core router in the middle of a critical update, WSUS will simply resume when it can, once again, contact Microsoft. WSUS also hooks into the new binary delta compression technology released with Service Pack 1 and the upcoming Release 2 of the Windows Server 2003 operating system.On the management front, WSUS has a bunch of new features that were sorely needed in SUS. For starters, it comes with a host of status reports that help determine system health and update status. In this regard, SUS did not fare well; often, you would get critical errors and updating problems and not know what was causing them or how to fix them. I cannot begin to recount the number of times I would try and clear a catalog, restart services and finally the server, and repeat attempted downloads and applications. You now get much more detailed information and more of it.

Patch management and updating is a sore point with all Windows administrators. The last thing you want to do in your datacenter and offices is let every server or machine on the network handle its own updating. Not only is it extremely taxing on the network, but it's a very dangerous process. Windows Servers can easily connect to, download and update themselves, if you let them, and you don't want to do this because you essentially can lose control of what gets updated and when as well as lose the entire network.

For example, when Windows Server SP1 was released to the Windows Update site, there were reports of several administrators finding SP1 on servers that were not ready to support it yet. How SP1 got onto the server unauthorized "is a mystery." It does not take very much to connect to the Update site, download SP1 to a Dell or HP server that has hardware management software on it that does not support SP1, and essentially knock out the server. I did it myself--in my lab, of course. There were not many safeguards to prevent this from happening. A week after my SP1 tests, a client's new server admin called me to say he was poised to get SP1 from Windows Update and asked, "Should I install it?" At least he had the sense to double-check. I had him contact his server vendor to get his array controller utilities updated first.

You need absolute control over what gets downloaded from Microsoft, if it should be installed to the target machines, and when. WSUS gives you this power and then some over SUS. Microsoft has been known to release defective patches to fix defects. (Imagine that, a fix that itself needs to be fixed?) In September, for example, Microsoft alerted the IT world to download a critical security update and apply it. Then Redmond later pulled the update saying the update itself had defects and needed more quality control.

To avoid such irritating events and to be sure that your patching and updating procedures are sound, I highly recommend you first update and patch lab equipment. If all goes well, then you can update production. Of course, you would require a WSUS server for your lab. If you can afford a lab server for this task, then do it. You can also swing your WSUS server (as a multi-homed server) between lab and production, but that's a tricky and time-consuming process. At the least, especially if you are new to updating and patching, get WSUS going in the lab first and understand fully how it works and the ramifications of the actions it will take. Make sure server administrators not tasked with updating and patching also understand the updating process.When SUS was first released back in 2003, I was managing a team of server specialists and we decided to let SUS update Exchange and SQL Server's base operating systems in the early hours of each morning. We also set it up so that if a reboot was needed the server would reboot automatically. The Exchange administrator, however, had decided to install a new service on the Exchange clusters and for whatever reason still unknown to me, the servers were rebooted by SUS but then failed to restart. The Exchange administrator found out that his day was toast when he got the first 6 a.m. support call that his 6,000 e-mail clients were dead on arrival at work.

All these nightmares in one shape or another have filtered back to Microsoft and resulted in a better product with WSUS. The product has been endowed with features to ensure that impact on end-user productivity is tightly controlled. The restart scenario is now accommodated with the ability to allow silent installs without needing user notification or interaction, and you have better control over when and if a critical server gets an update and if it should restart. You can also group multiple restarts into a single restart, or delay them until a later time, such as after hours. There are network geniuses that decide in the middle of a busy day that every desktop should restart. They usually end up having to explain that the office is not haunted; it's just the update service run amuck.

Let's now look at what it takes to get WSUS up and running. For starters, know that if you have SUS in place already, you can leave it up and running until your WSUS project is bearing fruit and you are ready to deploy it to production. There is no rush, either. Even though SUS is not going to be further updated now that WSUS has arrived on the scene, Microsoft will continue to deliver patches to it and support it through December 31, 2006.

At the minimum, you need a single Windows 2000 Server (SP3) or Windows Server 2003 server with at least a 1 GHz processor and 1 GB of RAM. This configuration will let you comfortably cater to 500 update candidates--client machines. WSUS servers can be configured in a hierarchy (like a blend of SMS and MOM), so the number of clients to be serviced really has no limit. This is ideal on a multi-hub architecture where you'll have WSUS servers positioned on high-speed networks servicing their local clients.

You also need Microsoft Internet Information Services (IIS) 6.0 installed on the server, which, like SUS, hosts the Web application front end to the service. The entire system is driven in ASP.NET, so you also need the Microsoft .NET Framework 1.1 Service Pack 1 on the system. This is not an issue with Windows Server 2003 SP1 and R2.As mentioned earlier, WSUS depends on the Background Intelligent Transfer Service (BITS). The BITS version you need is 2.0, which can be downloaded from Microsoft. WSUS also depends on SQL Server for its data repository. But you can use the SQL Server desktop engine (WMSDE) for a small deployment or in the lab for testing.

WSUS on its own (that is, without SQL Server running on the same server) is not very disk I/O intensive. Using our 500-client benchmark, you need about a gig on the system partition and at least 10 GB on the data partition. The data partition needs enough space to hold the update and patch binaries, so go with a volume between 30 and 60 GB (without MSDE or SQL Server). Knowing Microsoft and that disk costs are really cheap these days, I suggest getting about a 100 gigs worth of space on a data partition.

The basic installation of WSUS to a lab server on Windows Server 2003 is as follows:

You are now ready to begin configuring your WSUS server for operation. This will entail network configuration, accessing Windows Update to get binaries, server sync with Windows Update, configuring computer groups (clients) and more.

The WSUS site at Microsoft has a ton of whitepapers, operations manuals and data sheets available to you. Take at least a week to put together a WSUS project. Figure a day or two to read all the manuals and become familiar with the intricacies of using the product. A day or two at the most is all you need to get the first server up and your test clients patched.

Configuration is not a difficult process. In the lab environment, your biggest problem is going to be how you get to the Internet to get your updates. The good news is that you can download the update and patch binaries manually and import them into WSUS. This is also a terrific feature if you have security protocols in place that would prevent WSUS server from connecting to Windows Update whenever it feels like it.

Update, service pack and update management is the bane of every network administrator. WSUS is thus a welcome arrival on the road to keeping operating systems and applications secure and as defect free as possible. The day all machines are patched before the next Cassandra or Emily makes it to your datacenter is now closer... and I am not talking about hurricanes.Server Pipeline columnist Jeffrey R. Shapiro is the co-author of Windows Server 2003 Bible (Wiley) and is an infrastructure architect who manages a large Windows Server network for an insurance firm.