Deploying SP2--Or Notby Mitch Tulloch, author of Windows Server Hacks
To deploy, or not to deploy: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous security enhancements,
Or to take arms against a sea of incompatible applications,
And by opposing SP2 deployment, end them?
OK, so I'm obviously not a literary giant. But I have known my share of deployments--unattended, RIS, Sysprep, and others--and maybe I should keep my day job and stick to IT instead of Shakespeare.
I talked about application compatibility woes in a previous article, so it's clear that some shops will want to deploy SP2 quickly while others will want to wait awhile until they've thoroughly tested their applications to ensure nothing will break. Is XP SP2 easy to deploy? How can you do it? And more importantly, what can you do if you don't want to deploy it immediately? Let's look at both sides of the question.
A good place to start in planning your SP2 deployment is to read through the Guide for Installing and Deploying Microsoft Windows XP Service Pack 2, available from Microsoft TechNet. This guide can help you decide on various deployment issues such as:
Let's look at each of these items briefly.
While you would expect SP2 to run just fine on an XP SP1 system, I've found that certain processes slow down considerably when SP2 is installed. An example is searching drivers.cab when new hardware is installed. Another example is browsing Administrative Templates in Group Policy Object Editor. So be forewarned: if your current XP SP1 system runs slowly, SP2 may make it run even slower. Apart from that, all you need to consider in terms of hardware requirements is how much hard disk space you have available. See KB 837783 for more info.
SP2 supports all the standard XP deployment methods, including unattended (CD- or network-based) deployment, RIS, disk cloning, SMS, and so on. In addition, SP2 is available from Windows Update (WU) as a critical update, so if you've got Automatic Updates (AU) enabled on your client machines, they will download and install SP2 automatically, provided users are logged on as local administrators. (The AU installation of SP2 requires user interaction.) You can also use Software Update Services (SUS) to deploy SP2, which like SMS is a method that can perform silent updates that don't require user interaction.
However, you also need to be aware of a few differences regarding deployment tools and methods, namely:
Two of the deployment tools (found in \Support\Tools\Deploy.cab on your XP SP2 Integrated CD) have been updated in SP2, namely Sysprep.exe and Sysprep.inf. See KB 838080.
Several of the support tools also have been updated in SP2. See KB 838079 for more info.
You can customize the Windows Firewall INF file, Netfw.inf, to perform unattended installs with customized firewall configurations. See this article from the Microsoft Download Center. You can also configure Windows Firewall postinstallation using Group Policy. See this article for more info.
Answer files for unattended installation of SP2 have a new [IEHardening] section and new keys for existing sections like [Components], [Data], and [Unattended]. See this PowerPoint presentation from Microsoft for more info.
Finally, if you want to create an XP SP2 Integrated CD, see this article on Neowin. You can then use the CD with a winnt.sif file you create using Setup Manager to perform unattended CD installs of XP SP2.
If you are installing SP2 and the setup fails, you can use the Automatic Recovery feature to roll back your system to its previous pre-SP2 configuration. You can find more information about this feature in KB 875355.
Besides the application compatibility issues mentioned in my previous article, you can't install SP2 on a laptop if it's running from batteries. See KB 883609. If you have other SP2 deployment issues to suggest, use the comment feature at the end of this article to share them with other readers.
What if you feel you need more time to test your applications for compatibility before deploying SP2 across your enterprise? Obviously, IT departments have been making a ruckus with Microsoft over this, especially if they use AU to automatically download and install critical updates on their desktop machines. Microsoft heard these complaints and created a new Registry value that blocks the delivery of SP2 via AU or WU:
DWORD value to 1 blocks the delivery of SP2 to your machine. There's a catch, though--it blocks the delivery only for 120 days starting August 16, the day SP2 first became available as a download via AU or WU. And the clock is ticking.
If you want to use this hack to buy yourself more time, Microsoft has provided a number of tools for letting you do so. These tools include an ADM template you can import into Group Policy, a signed executable that can be run locally from the command line, a script that stops deployment on a specified machine, and several other methods. A description of these tools can be found here; be sure to also read this FAQ. The tools are available for download here, and the Scripting Guys at TechNet's Script Center have written a cool script that can allow/block SP2 deployment on multiple machines in one shot.
SP2 may be good or bad depending on your situation, but one thing is for sure: it is inevitable. Get familiar with it now if you haven't done so already, unless you're still running earlier versions of Windows on your desktop machines and don't plan to upgrade to XP before Longhorn arrives.
Mitch Tulloch is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.
Return to WindowsDevCenter.com.
Copyright © 2009 O'Reilly Media, Inc.