Deploying Mitigation Fixes

Published: November 19, 2004
On This Page

Implementing Windows XP SP2 on New Deployments
Upgrading Existing Windows XP Clients
Deploying the Service Pack
Implementing a Rollback Strategy


After thoroughly testing your applications, identifying compatibility issues, and developing workarounds or fixes, the next stage is to deploy Microsoft Windows XP SP2. Finally, you implement the mitigation strategy by running any mitigation scripts, configuring the UI, making changes, or altering settings in Active Directory Group Policy.

Deployment of Windows XP SP2 broadly fits into two categories—new Windows XP deployments and existing Windows XP deployments. Each deployment scenario requires careful planning and thorough testing. You are advised to read the Microsoft Windows XP SP2 installation and planning guide. For more information on deploying Windows XP SP2, see:

After you have deployed Microsoft Windows XP SP2, in time you will need to deploy further updates and combine these updates with new Windows XP deployments. For more information on deploying Windows XP updates, see the Microsoft Windows XP Hotfix Installation and Deployment Guide, at:

Implementing Windows XP SP2 on New Deployments

If you are including Windows XP SP2 with new deployments of Windows XP, you can use the normal installation process that your organization currently uses.

Using Manual Installations

This is the least efficient and slowest method of deploying Windows XP SP2 except in the smallest of organizations. This process involves installing Windows XP manually, deploying Windows XP SP2 manually, and finally applying any required application compatibility mitigation scripts. Even with setup scripts, this method is time-consuming, repetitious, and prone to error. If more than one installation is required, a procedural document and checklist is needed to ensure consistency across installations.

Running application compatibility scripts after installing the service pack can be simplified by implementing a batch file that chains compatibility scripts together.

It is difficult to find any advantages in this method because any time saved in implementing any of the following procedures is usually spent on the manual install itself.

Slipstreaming the Service Pack into the Installation Media

If a manual installation is necessary, the most efficient approach is to integrate (or slipstream) Windows XP SP2 into the original Windows XP source files. To do this, you must first extract the files from the Service Pack distribution executable using the /x switch:

WindowsXP-KB835935-SP2-ENU.exe /x

You are prompted to enter a destination location for the extracted files. The extraction process creates a subfolder called Update in the destination folder containing the setup program Update.exe.

To create an integrated Windows XP and Windows XP SP2 source, use the following command:

Update.exe /integrate:<path>

For more information on How to integrate software updates into your Windows installation source files, see the Microsoft Web site at;en-us;828930 

Note: The <path> must contain the i386 folder for the Windows XP Source files. You do not need to include the i386 folder in the path. If the Windows XP installation source does not have the i386 folder in this path, the slipstream command fails.

One additional benefit of creating a bootable integrated CD is that you can use this CD for system recovery in the future. For more information on integrating service packs and hotfixes into a single source, see the Microsoft Windows XP Hotfix Installation and Deployment Guide at the Microsoft Web site at

Using Remote Installation Services Images

Remote Installation Services (RIS) was introduced in Windows 2000 to improve the deployment of client systems.

RIS enables an administrator to install an operating system, together with applications, service packs and hotfixes. This process is accomplished by first building a baseline system, installing the applications, uploading the image to a RIS server, and then downloading that image onto un-partitioned client computers.

For more information about Remote Installation Services, see the Microsoft Web site at

Using Other Imaging Software

Many organizations have used non-Microsoft imaging systems for deploying client systems for a number of years. This imaging software takes a snapshot of a system, which includes the operating system, applications, service packs, hotfixes and configuration settings. This image can then be distributed on CD, DVD, or over the network.

For more information about Desktop Deployment Solutions from Third-Party Companies, see the Microsoft Web site at

Upgrading Existing Windows XP Clients

Deploying Windows XP SP2 in the appropriate configuration onto new computers is relatively straightforward. However, deploying Windows XP SP2 and compatibility scripts onto existing systems requires careful planning, to ensure data integrity and maintain the current functionality level. Deploying Windows XP SP2 to existing clients involves one of two approaches—manual deployment or automated installation. The following sections describe these approaches in greater detail.

Using Manual Deployment and Configuration

Manually deploying the service pack and scripts is inefficient in all but the smallest environments. Deployment of Windows XP SP2 can take several minutes and administrators are advised to take this into account when calculating the time to complete the upgrade process.

A summary of the deployment process is as follows:

  • Develop written guide and deployment check list.

  • Apply Windows XP SP2.

  • Apply Configurations Changes.

  • Apply Scripts.

  • Check that all applications and configuration are applied.

To initiate the installation, run the service pack setup program Update.exe with the relevant switches. As with previous service packs, a wizard appears to guide you through the installation process. When you have completed the installation and restarted the system, run the Application Compatibility Scripts and check that applications work as expected. If your scripts make changes to the registry, you need to run the scripts with an account that has local Administrator privileges. However, checking application functionality should be completed using an account that has only user rights.

Automating the Installation

For all but the smallest environments, automating the update to Microsoft Windows XP SP2 is the most efficient approach. The time spent developing and testing the automation process enables the organization to reach the largest number of seats, enhance rates of success, and reduce downtime.

The main issues with automated deployment arise when Windows Firewall is enabled, immediately following Microsoft Windows XP SP2 installation. This is because this configuration prevents most remote management tools from working until further configuration is applied. This is a key point for administrators who normally perform a two-phase update with the service pack deployment—the Service Pack in phase one and the additional configuration scripts or hotfixes in phase two. After Windows XP SP2 is installed, and the computer restarts, it is unlikely that you are able to connect and perform additional configuration tasks or run Application Compatibility Scripts.

Therefore, the automation process needs to ensure that your Application Compatibility Scripts run automatically after Windows XP SP2 restarts.

Figure 4.1 shows the process logic for the automated deployment process.

Figure 4.1 Flowchart for automated deployment of Windows XP SP2

Figure 4.1 Flowchart for automated deployment of Windows XP SP2
Using Command Line Switches

The service pack setup program Update.exe has a number of command line switches to aid the automation process.

For the Guide for Installing and Deploying Microsoft® Windows® XP Service Pack 2, see the Microsoft Web site at 

Switches that assist automated installations include /q or /u and /norestart. Either the /q or /u switch will cause setup to occur without user intervention (the /q switch hides the user interface and the /u switch results in passive display), and the /norestart switch results in setup completing without restarting the computer (by default setup will prompt the user to restart the computer).

Implementing Automatic Administrator Logon

This section contains information about modifying the registry. Before you modify the registry, back it up and make sure that you understand how to restore the registry if a problem occurs.

For more information about and a description of the Microsoft Windows registry, see the Microsoft Web site at;EN-US;256986

Microsoft Windows XP has several registry keys that can aid an automated installation. The AutoAdminLogon registry key is often used for Kiosk type systems or to continue an application installation following a restart. This setting relies on two other registry keys, the DefaultUserName and DefaultPassword having appropriate user account and the correct password. The AutoAdminLogon settings are located in the Windows registry in the following key:


Note: The password value in the DefaultPassword key is stored in clear text. This is a potential security issue because your Application Compatibility Scripts may need to run with local Administrator privileges. If you plan to use a domain account, you are advised not to use an account in the Domain Admins security group and enable this account only for a deployment. You are advised to use a strong password and change this password regularly.

For more information about How to turn on automatic logon in Windows XP, see the Microsoft Web site at;en-us;315231

Using RunOnce Settings

There are other registry keys that can assist in automating the deployment of Windows XP SP2. The most useful of these is the RunOnce key.

The RunOnce key allows an application or script to run once (and only once) after a computer restarts. This setting is often used to complete an application installation or to run configuration scripts without user intervention.

You can use the RunOnce key to run your Application Compatibility Scripts on the first restart after installing Windows XP SP2.

For more information and Definition of the RunOnce Keys in the Registry, see the Microsoft Web site at;EN-US;137367

Deploying the Service Pack

The combination of Update.exe switches and registry keys provides you with the tools to automate the deployment of Windows XP SP2 and any required application compatibility scripts. It is important to remember the required security context to write to the registry or perform administrative commands. Your script fails if the script attempts to run a command without the appropriate privileges. It is also important to get the order of the commands correct.

If your scripts need to change registry settings that are only available after the update to Windows XP SP2, you need to ensure that this script runs after the restart using the RunOnce registry key. You can combine the Windows XP SP2 setup program with the appropriate command line switches, configuration commands, and application compatibility scripts, in one batch file that completes the entire task.

Deploying with Logon Scripts

Many organizations choose to deliver the service pack and the application compatibility scripts using a logon script. The issues with this method revolve around the security context of the user. Application compatibility scripts that make alterations to the registry or execute commands that require local Administrator privileges fail unless the user is a member of the Local Administrators security group.

The secondary logon service and the command line tool Runas.exe can provide a workaround, but the secondary logon service prompts the logged on user for a password. Organizations should review the security implications of this approach.

Deploying with Remote Desktop Tools

Remote management tools enable a remote administrator to log on to a computer and run a combined Windows XP SP2 and application compatibility scripts installation batch file. However, the application compatibility script must configure the Windows Firewall for remote administration, or you will be unable to connect to the remote system once Windows XP SP2 has installed and the system has restarted.

Deploying with Active Directory

Group Policy is one of the key benefits of Microsoft Windows Active Directory. Group Policy makes it easy for administrators to distribute software and make configuration changes to groups of computers. Windows XP SP2 adds entries to the Group Policy administrative templates to enable configuration of some of the new features.

Distributed File System (DFS) lets you to create replicas of files across the network.

For more information about the Distributed File System, see the Microsoft Web site at

For more information about Distributed File System and File Replication Services, see the Microsoft Web site at 

Full details of deploying Windows XP SP2 and additional configuration changes using Group Policy are included in "Service Pack 2 Enterprise Implementation Guide."

For more information about Changes to Functionality in Microsoft Windows XP Service Pack 2, Part 8: Conclusion and Appendices, see the Microsoft Web site at 

Distributing the Service Pack Using Group Policy

Active Directory Group Policy supports software distribution, making this an ideal way to distribute Windows XP SP2. You can create Group Policy at site, domain, and organizational unit (OU) levels by creating a Group Policy Object (GPO) and linking it to the relevant container. Most organizations implement an OU structure for computers so that they can apply specific computer policies.

For more information about Group Policy Software Deployment Background, see the Microsoft Web site at

Using Group Policy to Assign Application Compatibility Scripts

Group Policy provides an excellent way to configure application compatibility mitigation across groups of computers.

Managing Windows Firewall

Remote management of client computers is a key requirement for many organizations. The default configuration of Windows Firewall blocks all unsolicited incoming network traffic, which prevents the use of remote management tools. Group Policy allows you to configure the Windows Firewall to enable remote communications. Figure 4.2 shows the Group Policy settings for the Windows Firewall.

Figure 4.2 Group Policy settings for managing Windows Firewall

Figure 4.2 Group Policy settings for managing Windows Firewall

You can use Group Policy to configure many of the other application compatibility mitigations that Chapter 3 of this guide discusses, such as, settings for Internet Explorer, Outlook Express, and DCOM. The additional benefit of using Group Policy is that when you update an application so that compatibility mitigation is no longer required, you can remove the mitigation fix for multiple computers in one step. Windows Firewall settings with Windows XP SP2 are included in “Deploying Windows Firewall Settings for Microsoft Windows XP with SP2.”

For more information about Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2, see the Microsoft Web site at 

Deployment with Systems Management Server

Using SMS 2003 to deploy software and service packs is another option for many organizations. Windows XP SP2 can introduce some incompatibility issues for customers using SMS, which require additional configuration.

It is recommended that you read the FAQ concerning Windows XP SP2 and SMS, and all the associated documents.

For more information, see: 

Most of the incompatibilities involve the Windows Firewall default settings and SMS remote management ports. Information concerning the deployment of Windows Firewall settings in managed environments is included in "Deploying Windows Firewall Settings for Microsoft Windows XP with Service Pack 2."

For more information about SMS Client FAQ, see the Microsoft Web site at

Checking Non-Microsoft Management Tools

It is recommended that organizations using non-Microsoft management and deployment tools contact the vendor for information on how those products interact with Windows XP SP2.

Implementing a Rollback Strategy

However much you test your deployment process, there may be unforeseen issues that arise during the deployment phase. Whichever deployment method you choose, plan a rollback strategy to ensure business continuity. This may involve uninstalling Windows XP SP2 or running rollback configuration scripts. Test both the rollback plan and any associated scripts before the deployment process.


Microsoft Windows XP SP2 includes many new security features that help organizations create a more secure desktop environment, minimize the attack surface available to intruders, and reduce the threats from e-mail and other vulnerabilities. However, many existing applications may not have been designed to work with these more stringent security settings and therefore, thorough testing is required.

It is recommended that before deploying Windows XP SP2, you formulate a deployment strategy to:

  • Decide which systems to update first.

  • Discover which applications have compatibility issues.

  • Develop and test application compatibility scripts to mitigate compatibility issues.

  • Develop and test a deployment process.

  • Develop a rollback strategy to maintain business continuity.

With careful planning and implementation, organizations can overcome any potential application compatibility issues and enjoy the security benefits that Microsoft Windows XP SP2 brings to desktop computing.