Deploying Windows XP Service Pack 2 (SP2)

Earlier this month, Microsoft finally released the long-awaited Service Pack 2 (SP2) for Windows XP. SP2 presents a number of challenges to system administrators. Several of the security fixes introduced by this service pack, while enhancing system security, have significant side effects. I discussed these side effects in detail in an earlier article (TK: LINK). Here, I'll provide some specific advice to administrators on how to deploy SP2 with minimum system-wide downtime. Controlling the SP2 Roll-Out

Microsoft has been advertising SP2 availability, and is making the service pack available to end-users through Windows Update. This raises the possibility that you'll find yourself with some users moving to SP2 before you've had a chance to test for compatibility and provide appropriate support mechanisms in your organization. To prevent this, you'll need to temporarily disable Windows Update on computers in your organization. Microsoft has instructions for this on their web site:

It would also be a good idea to advise users (via e-mail memo) that SP2 is being evaluated but is not yet supported by your IT staff"if they choose to install it on home computers it's strictly at the user's own risk. Some users will likely complain about this. Keep a record of them"they're candidates as test users when the time comes for an initial test deployment!

Testing for Compatibility The next step is to determine the impact of deploying SP2 in your environment. This is easy: Start by installing SP2 on a single test-bed computer (or just a few) in your IT shop. Use a typical end-user setup and the standard SP2 installation. This is available from Microsoft's web site:

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/winxpsp2.mspx You have the option at this point to use Microsoft's consumer installation (via Windows Update) or a version aimed at multiple computers. I recommend the latter; that will let you control when and how SP2 is disseminated in your organization, and will be necessary if you want to customize SP2 settings.

Follow the directions to download the service pack, and install it on your test computer(s). On restart after SP2 is installed, you'll be prompted for Windows Firewall settings"that's the first SP2 feature end-users will experience. You'll want to keep notes at this point, which will become raw material for end-user instructions and FAQs. Test all standard and mission-critical applications that are typically used in your organization, including any intranet applications and web sites. Keep a list of what problems you encounter. With luck they'll be minor. A very common problem is the failure of automatic downloads on web sites, due to automatic pop-up blocking in the SP2 version of Microsoft Internet Explorer. This is mainly an education issue: Users need to be told about the new Information Bar, and prompted to use it to enable pop-ups from appropriate web sites. For sites that are under your control, Microsoft offers recommendations for how to fine-tune them for SP2 compatibility. See:

http://msdn.microsoft.com/security/productinfo/xpsp2/default.aspx?pull=/library/en-us/dnwxp/html/xpsp2web.asp

It's also possible to deploy a list of permitted (and denied) sites using Group Policy, in Active Directory environments. SP2-related Group Policy Objects (GPOs) allow administrators to propagate a wide range of settings, including firewall mode, permitting/denying peer-to-peer file sharing, and automatic updates, among others. For details see:

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/mangxpsp2/mngintro.mspxWhile most issues with SP2 are likely to be minor, there are some cases where applications may function incorrectly or completely fail to work. In these cases, you're going to have to determine what specific SP2 feature or patch is causing the problem. Microsoft has a guide to SP2 application compatibility testing and migration, which provides detailed instructions for testing, and workarounds for the most common problems. You can download it from: http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/sp2apcom.mspx

Many (though by no means all) of SP2s new features can be enabled or disabled in the Windows XP registry. Documentation on the relevant registry settings is available at:

http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/sp2chngs.mspx

Of course, using the registry to disable SP2's new security features defeats the whole purpose of the service pack, so this should be considered a last resort.

SP2 updates the built-in firewall in Windows XP, and enables it by default. This can cause problems for network applications that communicate using Remote Procedure Calls (RPC), Distributed Common Object Model (DCOM) or Socket protocols. Settings for the firewall can be managed either using group policy or an administrative command-line application. For details, see:http://www.microsoft.com/downloads/details.aspx?FamilyID=4454e0e1-61fa-447a-bdcd-499f73a637d1&DisplayLang=en

Planning Your SP2 Deployment

With your test-bed running, applications (and web sites) tested for compatibility, and any workarounds documented; you can start planning a deployment. Several deployment methods are available, including either upgrades to existing systems or integrated installations (including the XP operating system, and optionally, applications) on new computers. The deployment itself can be performed using Software Update Services (a customizable version of the technology behind Windows Update), Microsoft's Systems Management Server (SMS), and execution of the service pack installation from a network share as you did for your test-bed. These are discussed (along with a good overview of the entire deployment process) in:

http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/sp2entpl.mspx

I strongly recommend that administrators carry out a limited test deployment first, before attempting an organization-wide rollout. There are liable to be some issues in the deployment process that won't show up until you try it for real, and you don't want that to shut down an entire branch/division/company! Microsoft offers detailed instructions for enterprise rollout using SUS, SMS, and Group Policy:http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/sp2entdp.mspx

Additional details on using SUS to deploy SP2 may be found in:

http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/xpsp2sus.mspx

Additional details on using SMS for SP2 deployment:

http://support.microsoft.com/default.aspx?scid=kb;en-us;842844It's probably possible to deploy SP2 using third-party software management/deployment tools as well"if you're using such a system, contact the developer for details. Administrators in smaller organizations, who don't need to use SUS or SMS can perform a local deployment either directly on each PC or from a central network share:

http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/spdeploy.mspx

Troubleshooting and Support

Candidly, at this point SP2 is so new that it's difficult to offer much in the way of useful troubleshooting advice. Microsoft does have a troubleshooting guide for firewall problems, which may be helpful in some situations:

http://www.microsoft.com/downloads/details.aspx?FamilyID=a7628646-131d-4617-bf68-f0532d8db131&displaylang=en There are also a set of SP2 Support Tools, "intended for use by Microsoft support personnel and experienced users to assist in diagnosing and resolving computer problems" (according to Microsoft's web site):

http://www.microsoft.com/downloads/details.aspx?FamilyId=49AE8576-9BB9-4126-9761-BA8011FABF38&displaylang=en

Of course, SP2 isn't the last word in hot fixes and patch management"inevitably, there will be post-SP2 patches. Smaller organizations can most easily deal with this using the automatic updates feature (which can be enforced using Group Policy, if desired). Larger organizations may prefer to operate their own patch servers. For details, see:

http://www.microsoft.com/technet/prodtechnol/winxppro/deploy/hfdeploy.mspx

John D. Ruley is a freelance science and technology writer. He is also principle author of Networking Windows NT 4.0 (John Wiley & Sons, 1997). He's delighted to receive e-mail from readers; write to him at [email protected]

0