When it comes to Microsoft service packs, it seems that there have always been two different schools of thought. One philosophy is that service packs have been thoroughly tested by Microsoft, they fix bugs and patch security vulnerabilities, and therefore it is prudent to deploy a service pack as soon as it becomes available. The other philosophy is based on the fact that when you deploy a Windows Service Pack, you are changing core operating system code, and that by doing so there is always the chance that you could break something. People who buy into this philosophy generally like to wait for six months to a year before deploying a service pack, just to make sure that the service pack is stable.
Obviously, if you buy into the "Wait And See" philosophy, the last thing that you want is to have WSUS or Windows update automatically applying Windows Server 2003 Service Pack 1 to your servers. Personally, I tend to prefer deploying service packs immediately after they are released. Even if you share my philosophy on service pack deployment though, there are still situations in which you might not want to apply Windows Server 2003 Service Pack 1. For example, if you have a mission critical application with a known compatibility issue with Service Pack 1, then you sure don't want to deploy it.
Fortunately, if you need to block the installation of Windows Server 2003 Service Pack 1, there are some ways to do so. In this article, I'll show you how to defer the automatic installation of Windows Server 2003 Service Pack 1.
Automatic updates mean automatic problems
If you are using WSUS or Windows Update to apply updates to your computers, things can get to be complicated. WSUS does allow you to prevent the installation of Windows Server 2003 Service Pack 1. To do so, simply open the WSUS console through Internet Explorer. When you do, you will see a summary screen similar to the one that's shown in Figure A.
|Locate the link labeled Review Security and Critical Updates.|
If you look toward the lower left portion of the screen shown in Figure A, you will see that there is a link labeled Review Security and Critical Updates. Click on this link and you will see all of the critical and security related updates that have not yet been approved for installation. The screen will look something like what you see in Figure B. Now, simply select Windows Server 2003 Service Pack 1, and then click the Decline Update button. After doing so, the service pack will be removed from the default view so that you don't accidentally approve it for installation.
|Select Windows Server 2003 Service Pack 1 and click the Decline Update button.|
Of course in the real world, things are rarely that simple. Telling WSUS to decline the Service Pack 1 update is fine if you need to block installation of the service pack across your entire organization. What happens if you only need to block the update on a couple of servers though?
Fortunately, you aren't forced to make an all or nothing decision. There are a couple of different tricks that you can use to ensure that Service Pack 1 is deployed where you need it, and blocked from deployment where necessary.
Divide and conquer
One technique involves using WSUS to separate your servers into two groups. One group will contain servers that Service Pack 1 can be safely applied to. The other group will of course consist of servers that Service Pack 1 should not be applied to.
To create these groups, open the WSUS console and click the Computers button found in the top, right portion of the screen. When you do, you will see a screen similar to the one shown in Figure C, that lists all of the computers that WSUS knows about. As you can see in the figure, this screen lists both servers and workstations. I recommend clicking the Operating Systems column heading so that you can sort the list by operating system. This will allow you to gain a better prospective of what servers exist on your network.
|The Computers screen displays all of the computers that WSUS knows about.|
At this point, click the Create a Computer Group link. When you do, WSUS will prompt you to enter a name for the group that you are creating. For demonstration purposes, we will create two groups. Let's call one group SP and the other group NO SP. You will use the same technique to create both groups.
Now that the groups are created, it's time to start moving your servers into the appropriate group. To do so, select a server and then click the Move the Selected Computer link. You will now see a dialog box appear that asks you which group you want to assign the server to.
One word of caution before you move the server though. If you look at Figure C, you will notice that all of the computers are lumped into a group called Unassigned Computer by default. Once you move a computer into a group, you can move it to other groups, but you can't move it back into the Unassigned Computer group. Now, repeat the procedure until your servers are grouped into the SP or NO SP group.
Now that the servers are all grouped, it's time to tell WSUS how the service pack should be deployed. To do so, click the Updates button and then set the view options to show you All Updates from Any Time and click Apply. You will now see a list of every update that WSUS has on file. At this point, I recommend clicking on the Classification column so that the various types of updates are grouped together. After doing so, scroll through the list of updates until you find the service packs (they are toward the bottom of the list).
Select Windows Server 2003 Service Pack 1 from the list and click the Change Approval link When you do, you will see a screen similar to the one that's shown in Figure D. If you look at the figure, you will see that each of the groups that I have created are listed, and just to the right of the groups is an approval column. If you click on the approval status for a particular group, a drop down list will appear that allows you to choose the approval type for the group.
|Set the SP group's approval to Install and set the NO SP group's approval to Not Approved.|
Set the SP group's approval to Install and set the NO SP group's approval to Not Approved. Click OK and the new approvals (and disapprovals) will be set. Keep in mind that the approvals that we have set only apply to Windows Server 2003 Service Pack 1. You can set custom approvals on other patches if you like, but as of right now we have not done so.
The technique that I just showed you works well enough, but it is a bit impractical as a long term solution. For example, what would happen when Service Pack 2 comes out if you had an entirely different group of servers that Service Pack 2 could be applied to? You would probably have to create yet another group and start shuffling around group memberships again. Even if you are able to pull this off without too much effort, the problem is that every server in your organization has slightly different operational requirements.
As such, there may come a day when a particular server really needs to belong to multiple groups. To the best of my knowledge, WSUS will not allow a server to belong to more than one group, so this type of situation would require you to make some tough decisions. My point is that you can use WSUS to control which servers the service pack gets applied to, but you probably won't want to impose this limitation permanently.
Reaching for the proper tool
There is another good solution to blocking the deployment of Service Pack 1, but again, it is also a temporary solution. Microsoft has released a special tool that is specifically designed to block the deployment of Windows Server 2003 Service Pack 1. The tool is called Toolkit to Temporarily Block Delivery of Windows Server 2003 Service Pack 1. Seriously. That's the tool's name. Since I'm lazy and I don't feel like typing that huge name a million times, I will simply refer to this utility as the Tool for the remainder of this article.
The Tool is designed to prevent Windows Server 2003 Service Pack 1 from being automatically deployed to a Windows Server that has automatic updates enabled. It will also prevent Service Pack 1 from being installed by WSUS or by SUS. There is a catch though. As I mentioned earlier, the tool is designed as a temporary solution. The tool contains a time bomb that will render it ineffective on March 30, 2006. You can download the Tool directly from Microsoft.
The download itself consists of an 83 KB self-extracting executable. When you download the tool, double click on the executable file and you will see a prompt asking you to accept the end user license agreement. Click Yes, and you will be prompted to enter a path to save the extracted files to. Enter the desired path, and three files will be created. There is an executable file (SPBlockingTool.exe), a script (SPreg.cmd), and an ADM template (NoSPupdate.adm).
Although Microsoft gives you three files, you really only need one of them, and that's the executable. The executable file is a simple command line utility. Those of you who hate command line utilities don't have to worry because this utility only has two different switches that you can use. Just open a command prompt window and enter the name of the executable file (SPBlockingTool.exe) followed by either /B to block the service pack or by /U to unblock the service pack.
Of course blocking and unblocking the service pack doesn't happen by magic. The tool works by modifying your system's registry. When you use the /B option, the tool creates a new registry key named DoNotAllowSP at HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate. The tool then assigns this new registry key a value of 1 to enable it.
So what about the script and the ADM template? Well, the script does the exact same thing as the executable file does. The only difference is that the script is designed so that you can specify the name of the server that you want to run the tool against. This makes it possible to protect remote machines against service pack installations. That way you don't have to visit each server individually and run the executable file. Microsoft stresses though that the script is to be run as-is. The script is not designed to be included as a part of a more complex script that you might develop on your own (at least that's what the Web site says).
The ADM file that comes with the tool is a template that you can import into your group policy. By doing so, you can block the installation of Service Pack 1 at the group policy level. This is handy if you have a lot of servers and you don't want to have to run a remote installation script against each individual server.
The procedure for importing the ADM file will differ from network to network depending on how your group policy is set up. For a default Windows Server installation though, you would open the Active Directory Users and Computers console right click on the domain of choice, and select the Properties command from the resulting shortcut menu.
When you do, the domain's properties sheet will appear. Select the properties sheet's Group Policy tab, select the Default Domain Policy and click Edit. Windows will now open the Group Policy Object Editor. Navigate through the console tree to Default Domain Policy | Computer Configuration | Administrative Templates. Now, right click on the Administrative Templates container and select the Add / Remove Templates option from the resulting shortcut menu. Windows will now display the Add / Remove Templates dialog box. Click the Add button and specify the path the tool's ADM file.