Microsoft Service Pack Management
Will Willis
One of the more common chores for a systems administra= tor is keeping up with service packs and hotfixes for their NT or Windows 2000 servers. It is such a common task that Microsoft even includes exam objecti= ves on service pack deployment on its 70-215 Windows 2000 Server certification exam. Unfortunately, service pack management is often misunderstood by newb= ie sysadmins, who understand neither when or why to apply a service pack or hotfix, or the proper procedures for testing and deployment.
With Microsoft products, a service pack is a collection of patches and fixes that is distributed with a single installat= ion routine for an administrator’s convenience. Unfortunately Microsoft in recent years has stretched this definition by in many cases also including = new functionality to the product rather than just fixing existing bugs. This has caused the size of service packs to grow tremendously and has made testing = even more important as service packs often introduce new bugs. Furthermore, with applications such as Exchange Server, service packs are not even distribute= d as a single download anymore. Service pack 1 (SP1) for Exchange 2000, for exam= ple, requires downloading 13(!) separate setup files for a total of almost 200MB= .
A hotfix is a patch that it released between se= rvice packs to address a specific problem, such as a security hole or a bug introduced by a previous service pack. Sometimes they are simply patches th= at hadn’t been tested enough to make it into a service pack. Generally m= ost hotfixes are rolled up into the next service pack, so if you install SP2 for Windows 2000 on a system that previously had SP1, you get all of the hotfixes that were released in the interim. That isn’t always the case, so it is important to check http://www.m= icrosoft.com/technet/security/current.asp and http://windowsupdate.mi= crosoft.com. These two sites were discussed in a column last here.
Determining issues that are addressed
One trap that I’ve seen many systems administrat= ors fall into when they are starting out (and admittedly I did as well), is installing an update with the mentality that “it is newer, so it must= be better.” That is, installing fixes without regard to whether it will address any problems they are having, or if there is really a need. The old adage “if it ain’t broke, don’t fix it” is very apr= opos for server management. That is why you should first review the documentation that comes with a service pack to determine if there is even a compelling reason to install it. In many cases there will be, particular with NT and Windows 2000, because many of the hotfixes rolled up into service packs add= ress security issues that if left unpatched can expose the server to breaches by hackers. Individual hotfixes usually address a single issue, so whether you need to install one depends on what services your servers are running and w= hat service pack you are currently running.
Documentation!
Because of the nature of making changes to your server= OS and applications, it is imperative that you keep your documentation in orde= r. For each server, you should have a listing of the following:
- Post-Windows
NT 4.0 Service Pack 6a Security Rollup Package (SRP) after installing Excha=
nge
5.5 SP4, since the SRP is a newer release.
Many organizations require extensive testing before ro= lling out a service pack (more on testing in a bit), so it may be mandatory that = you install a particular SP that isn’t the most current. For example, wha= t if in our scenario company policy dictated that you install SP3 for Exchange 5= .5 rather than SP4? In this case the application service pack is older than the operating system service pack, so after installing Exchange 5.5 SP3 you wou= ld want to reinstall NT4 SP6a and the SRP to ensure that system files were not overwritten with older versions. Windows 2000 comes with a windows file protection service that prevents system files from being overwritten with an older version, however, Windows NT 4.0 did not h= ave this feature.
Testing Service Packs
As we mentioned earlier, with the way Microsoft has ta= ken to introducing new functionality in service packs and not simply fixing bugs, service packs can many times introduce new bugs that could affect your serv= ers. Also, hotfixes can affect how services interact with each other and cause problems for existing applications and services. Therefore, you should test= any new service pack or hotfix in a lab environment before deploying it on a li= ve server. That way you can ensure that everything performs as expected since hotfixes are rarely uninstallable, and uninstalling service packs is usually painful at best. A lab machine should have a similar hardware and software configuration as the production server in order to eliminate as many variab= les as possible. Once you have tested a fix and are sure you are ready to insta= ll it live, you can proceed.
Deployment methods
If you have many servers, deploying service packs and hotfixes can be tedious. Products like Microsoft Systems Management Server = go a long ways towards helping this by allowing you to automate deployments of software from a central share across your network. Windows 2000 includes limited software distribution capabilities through Group Policy. In the cas= e of installing multiple hotfixes, which more often than not require you to rebo= ot the server after each one, there is the QCHAIN utility that we discussed in this column last month in Managing Windows 2000 Security Updates.
Slipstreaming
Shortly before Windows 2000 came out, Microsoft introd= uced a new method of handling service packs. I believe SMS 2.0 SP1 was the first service pack to take advantage of a new technique called slipstreaming. This feature allows you to integrate the service pack files with the origin= al installation, so that when installing from scratch you do not have to insta= ll the operating system or application and then the service pack. For example,= you can slipstream Windows 2000 SP2 into the I386 directory of the Windows 2000 setup source. In addition to not having to install SP2 separately when buil= ding a new system, at that point whenever you install a new service under Windows 2000 you no longer have to reapply the current service pack, which is what = you typically had to do in the past. This is a tremendous timesaver if you are managing more than just a few machines.
To slipstream a service pack into a source directory, = first copy the \i386 from your Windows 2000 CD to the hard drive of your computer. Then, unpack the service pack files if you still have them in a single file download. To do this, first ensure that your temp directory is empty. Then, execute the service pack file (such as W2ksp2.exe) and let the files be extracted. When that finishes and you are prompted to install, go to your t= emp directory and copy the contents to a different directory such as c:\W2KSP2 = that you’ve created on your hard drive. Switch back to the service pack installation and cancel it. If you already have the service pack extracted = or on CD, you do not need to perform this step.
The executable to install a service pack is update.exe= , and is located in the \update folder of the service pack source files. To slipstream the service pack into the source files you had copied to c:\downloads\i186, for example, you would type from a command prompt:
Update –s:c:\downloads
The reason you don’t specify the i386 directory explicitly is because the update program looks for it in the directory you supply. Once you executed the command, you would see a progress bar like th= is:
![](3D"MicrosoftServicePackManagement_files/image002.jpg")
Once the slipstream process was complete, you could ei= ther burn the \i386 source directory to a CD for a CD-based installation, or copy/move the source directory to a network share for a network based installation. Installing Windows 2000 or services from this source director= y would automatically put them at the SP2 level and not require a reinstallation of= the service pack afterwards.
By following some basic principles, you should be able= to successfully manage the service packs and hotfixes for your servers. As alw= ays, whenever you make a change, document it so that not only you can refer back= to it, but so others can as well. Staying on top of updates and thoroughly tes= ting them before deployment will keep your servers running smooth and you looking great.
Comments or questions? Will can be reached at WWillis@Transcender.com.