Over the last few years, patch management has gone from being a relatively unimportant task to being absolutely critical to an organization’s security. Although Windows Update Service (WUS) is still in beta testing, it is time to start planning how your organization will make the transition from the Software Update Services (SUS) to WUS. In this article, I will tell you what you need to know in order to insure a smooth transition.
Before I Begin
Before I get started, I want to give you a little background information on WUS, just in case you aren’t already familiar with it. WUS is basically the next version of SUS. As you probably already know, SUS is Microsoft’s free patch management solution. Microsoft’s other primary patch management solution is SMS Server. SMS Server tends to be expensive and complex to deploy, but offers greater patch management capabilities than SUS. WUS has been designed to replace SUS, but was not designed to compete with SMS Server. SMS Server will still be Microsoft’s high end patch management solution.
Why Upgrade to WUS?
WUS is loaded with new features, but there are three particular features that really make the upgrade worthwhile. The first, and probably most important feature is broader product support. SUS did a great job of keeping Windows up to date, but WUS will be able to update other products such as Microsoft Office, Exchange Server, and ISA Server. Eventually, WUS will be able to keep all current Microsoft server products up to date.
The second feature that really makes WUS worthwhile is something called patch delta. The idea is that many security updates require modifying multiple files. Imagine that you applied an update that modified three system files. Now, imagine that the next day, you downloaded another update that modified the same three files, plus another file. If the newest patch brought the three files that had already been modified up to their current version (which happens a lot), then technically, only one file out of the entire update would need to be applied. WUS is smart enough to apply only the files that are actually needed. This helps to conserve bandwidth, especially over slow links.
The third big feature is that WUS will allow you to produce detailed reports of exactly which patches have been applied to each machine. This is great for anyone who has to worry about compliance issues. WUS also has dozens of other minor improvements. For example, WUS allows you to deploy updates to only a select group of clients if you so desire. WUS is also designed to reduce the frequency at which users must reboot their machines after updates have been applied.
Co-Existence With SUS
The nice thing about making the transition from SUS to WUS is that you can do it at your own pace. As you probably know, SUS is Web based. Clients are pointed at a Web server within your organization to download updates. WUS is also Web based and can co-exist with SUS with no compatibility issues. This allows you to migrate clients over to WUS as you see fit.
Deploying BITS 2.0
One of the primary architectural differences between SUS and WUS is that WUS requires BITS 2.0 and WinHTTP 5.1, while SUS did not. BITS is an acronym standing for Background Intelligent Transfer Service. Although BITS has been around for a while, WUS will not work without the 2.0 version (which is still in beta testing).
I don’t want to waste too much space talking about all of the technical details behind BITS, but I will tell you that BITS is designed to facilitate the file transfer process. As you probably know, Windows limits the number of files that you can download simultaneously. BITS makes it possible for WUS to download update files in the background, even if other files are being downloaded in the foreground. BITS also allows you to limit bandwidth consumption and also supports range downloads and server message blocks (SMB).
The other background component that WUS requires is WinHTTP 5.1 WinHTTP is basically a background service that helps facilitate communications between Windows Servers and HTTP servers. The reason why WinHTTP is required is because BITS is designed to use WinHTTP in order to send HTTP requests and to process responses.
Like BITS, WinHTTP has been around for a while. Version 5.1 is very similar to the previous version, but contains some minor security updates. If you would like to read more technical details about BITS and WinHTTP, you can find them at http://support.microsoft.com/default.aspx?scid=kb;en-us;842773
You can download the required updates to BITS and WinHTTP from the WUS Web site (http://www.microsoft.com/windowsserversystem/wus/default.mspx) Both components are included in a single file that at the present time is only listed as BITS 2.0. There are separate versions of the update for Windows 2000 Server and Windows Server 2003 though. One word of caution is that the update requires you to reboot your server.
After downloading the BITS update, double click on it to launch the Setup wizard. Click Next to bypass the wizard’s Welcome screen. When you do, you will be prompted to accept the end user license agreement. Select the I Agree option and click Next. The Setup Wizard will now copy all of the necessary files. When the file copy process completes, click Finish to reboot the server.
Deploying WUS
For the most part, WUS has very similar requirements to SUS. WUS has very low overhead, so pretty much any machine that’s capable of running Windows 2000 Server or Windows Server 2003 is capable of running WUS. The only major requirement that differs from SUS is that WUS relies on a SQL Server database. Before you stop reading because you either don’t have the budget for SQL Server or because you need to run out and buy a SQL Server license, I do have some good news. If you are installing WUS on Windows Server 2003, you can take advantage of the built in Microsoft Database Engine (MSDE). MSDE is a watered down version of SQL Server that is included in Windows Server 2003. If you have a full blown SQL Server, you will have better database administration tools and better reporting capabilities. If you don’t have a SQL Server though, it’s no big deal because MSDE will work just fine.
Prior to installing WUS, you must also make sure that your server is running Service Pack 1 of the .NET framework version 1.1. The easiest way to accomplish this is to run Windows Update on your server and make sure to install any critical updates. Since Service Pack 1 for the .NET framework is considered to be a critical update, it should be installed.
To install WUS, double-click on the WUSSETUP.EXE file that you downloaded, and Windows will extract the necessary files and launch the WUS Setup Wizard. Click Next to bypass the wizard’s Welcome screen and you will be prompted to accept the end user license agreement. Select the I Accept option and click Next.
At this point, Setup will prompt you for a location in which to store updates. Consider the location carefully, because WUS could potentially store 6 GB of update files in the location that you specify (possibly even more over time). Make your selection and click Next. Setup will now ask you whether you want to use an existing SQL server or if you would rather install MSDE. Make your selection and click Next. Setup will now inform you that you can manage WUS by entering http://server_name/WusAdmin into your Web browser. Clients can download updates at http://server_name Click Next twice, followed by Finish to complete the installation process.
Using WUS
Working with WUS is really similar to working with SUS. Both use a Web interface for administration. Obviously, WUS has a lot of new features, but having used SUS in the past, I had no trouble finding my way around WUS. If you would like to know more about the new features in WUS and how to use them, there is a great article on the subject at: http://www.windowsecurity.com/articles/Windows-Update-Services-Review.html
Conclusion
Although WUS is still in beta testing, it’s worth taking a serious look at WUS now, because WUS will be able to keep virtually all of your Microsoft products up to date. Since WUS can co-exist with SUS, I recommend setting up a WUS Server and attaching a small subset of your clients to it. This will allow you to start getting used to WUS. When the beta testing period expires and WUS is released, you will already be ready to move forward with it. You will simply have to redirect the rest of your clients from the SUS Server to the WUS Server.
