Group policies can help distribute Windows XP SP2, but they can be complicated to manage. Here's how you can use the Group Policy Management Console to get a handle on deploying XP SP2 from Windows Server 2003.
Windows XP Service Pack 2 (SP2) is a complex update with many ramifications for IT pros. TechRepublic's Windows XP Service Pack 2 Quick Guide drills down on critical SP2 need-to-know areas, with sections on fundamentals, changes that occur after installation, deployment procedures, problem areas, and removal.
Distributing Windows XP Service Pack 2 (XP SP2) in an organization can be a daunting task. Although you can speed the distribution by using group policies, group policies in and of themselves can be a complicated matter to deal with. Fortunately, Microsoft created the Group Policy Management Console (GPMC) for Windows Server 2003 that helps make managing group policies easier. Here's how to use GPMC to create policies to distribute XP SP2.
What's the Group Policy Management Console?
Microsoft first introduced the GPMC for Windows Server 2003 as a way to help Windows administrators get a handle on group policies, a powerful but often confusing aspect of Windows 2000. Microsoft extended the Group Management Console to Windows 2000 as well as Windows Server 2003 so long as the Windows 2000 server was running Service Pack 3 or later. Oddly enough, even though the GPMC will modify group policies on Active Directory running under Windows 2000, you can't run it from Windows 2000. You can only run it from Windows XP or Windows Server 2003.
Windows Server 2003's GPMC centralizes all Group Policy management functions, including backup and restore of Group Policy objects, import and export capability of Group Policy objects, and resultant set of policy reporting. By combining functions from a number of tools, such as Active Directory Users And Computers, Active Directory Sites And Services, the Resultant Set Of Policy snap-in, and the Delegation Wizard, the GPMC eliminates the need to go to a bunch of locations to perform common tasks. For more information about the GPMC, see the article "Learn how to take advantage of the Group Policy Management Console".
You’ll need the network installation version of Windows XP Service Pack 2. It doesn’t matter how you obtain the file, whether from Microsoft’s Web Site or from a Windows XP Service Pack CD. If you download it from Microsoft, you better have a fast connection. SP 2 weighs in at over 250 MB and will take quite a while to download. Microsoft also uses a long file name for the service pack: WindowsXP-KB835935-SP2-ENU.exe. After you download the file, you may want to rename the file to something easier to type such as winxpsp2.exe.
Create an installation directory on your server from where you'll distribute the files and copy the Winxpsp2.exe file into it. Next, extract the SP 2 files from the file by typing winxpsp2 /x at a command prompt in the temporary directory and pressing [Enter]. When you see the Choose Directory For Extracted Files dialog box, type c:\tempdir, where tempdir is the name of the installation directory you created, and click OK.
Naturally, you'll also need a copy of the GPMC. You can obtain that from Microsoft's Windows Server 2003 Web site. If you haven’t already downloaded and installed it on your network, you'll need to do so before applying the service packs or creating the group policies.
Installing Windows XP service packs
You can install Windows XP service packs through Group Policy as easily as you can other application patches and updates. Group Policy offers an excellent means of ensuring that your operating systems are up to date. As with applications, however, you should explore how the application of a service pack will affect each user and plan accordingly. It’s rare that a service pack causes problems instead of fixing them, but you should be aware of any potential problems and any post-SP fixes that address those problems so you can deploy them at the same time. Before applying the service pack via group policy to all of your workstations, you should try to deploy the service pack via group policy in a test environment.
The process for deploying a service pack is much the same as for an application upgrade, with two main exceptions: You’ll assign the package rather than publish it, and you’ll apply the GPO through the Computer Configuration branch rather than the User Configuration branch.
Start by preparing the distribution share for the service pack. This is the temporary folder that you created above where you copied the SP2 files to. Configure permissions on the folder, and share it to make it accessible to workstations on your network.
Once the files are in place, you can define the GPO that will cause the service pack to be deployed. Open the GPMC by clicking Start | Administrative Tools | Group Policy Management. When you do, you'll see the screen shown in Figure A.
|You can control group policies from the Group Policy Management Console.|
One nice feature of the GPMC is that it allows you to set filters which help control what computers will apply the policy. These are known as WMI Filters. For example, you can make a policy apply only to Windows XP workstations and not Windows 2000 Professional workstations. In the case of SP2, if you're in a mixed environment with XP and 2000 workstations, attempting to apply XP SP2 to a Windows 2000 Professional workstation won't crash the workstation. Instead, the Service Pack Setup will fail. Although that may be acceptable, it still delays the amount of time it takes for the Windows 2000 workstations to log on and causes needless excess network traffic.
To prevent Service Pack 2 from applying to Windows 2000 Professional computers, you can specify that the policy only apply to Windows XP computers. To do so, expand the domain. Right click the WMI Filters selection and select New. You'll then see the New WMI Filter screen appear. In the Name field, enter Windows XP Computers or some other descriptive name along with other information in the Description field.
Click Add to create a special query specific to Windows XP workstations. When the WMI Query window appears, make sure that root\CIMV2 appears in the Namespace window. In the Query box type Select * from Win32_OperatingSystem where Caption = "Microsoft Windows XP Professional" as shown in Figure B. Click OK to close the WMI Query window and then Save to close the New WMI Filter window.
|By setting a filter, you can specify the policy to only apply to Windows XP workstations.|
Next, right-click the domain where you want to set the new Group Policy and select Create And Link A GPO Here. When the New Group Policy Object window appears, enter a descriptive name such as WinXP SP2 and click OK.
The new group policy will appear in the left pane of the Group Policy Management Window. Right-click it and select Edit. You'll then see the Group Policy Object Editor appear as shown in Figure C.
|The Group Policy Object Editor allows you to set the policy.|
In the editor, open the Computer Configuration | Software Settings | Software Installation branch. Right-click in the right pane and choose New | Package. Rather than browsing to the share where the service pack files are installed, type the UNC path to the file server share where you copied the Service Pack files, such as \\server\share\installdir\i386\update\Update.msi, and click Open. When the Deploy Software dialog box appears, leave the Assigned option selected and click OK to create the package.
After you've created the policy, you must associate the filter with it. Click the WMI Filters branch again, and select the filter you created earlier. In the right pane, right-click the GPOs That Use This WMI Filterwindow and click Add. When the Select GPO window appears, select the group policy you created earlier and click OK. You can then close the GPMC.
Applying the package
With the package in place, the next time your Windows XP workstations reboot, SP2 will install on them. The service pack will install in unattended mode before the user sees a login screen. Because the service pack is so large, you probably want to warn your users in advance that it will take a while for the package to install when they restart their machines.
Keep in mind that the group policy refresh interval will control how soon the service pack will be applied. While you can change this refresh value (the default is 90 minutes), in most cases, it’s more trouble than it’s worth. Simply allow the policy to refresh as scheduled. Also, note that if you define the policy at the domain level, the change will not always occur as you expect it to. It has been my experience that you must sometimes reboot the clients more than once before the domain-wide policy changes are applied. When applying the policy at the OU level, the change typically happens the first time you reboot after the policy refreshes.
Here’s one bit of advice on planning and deploying application updates and SPs through Group Policy: Consider the impact on your servers and availability issues when deploying the software. A typical upgrade can generate a significant amount of network traffic. This potential problem is magnified as the number of systems being upgraded increases. For example, you wouldn’t want several hundred users all deploying a service pack at the same time—your network would probably slow to a crawl.
To keep this from happening, stagger the upgrade by deploying it through multiple OUs at varying times. Link the applicable GPO to one OU and allow the policy to apply the upgrade to those users. Then, when the majority of users in that OU have had their systems upgraded, link the GPO to the next OU to repeat the process for its users. Continue linking the GPO to the remaining OUs one at a time until the deployment is complete. An alternative to this method, if you have sufficient servers and network segmentation to make it feasible, is to create multiple distribution points and GPOs to distribute the upgrade load across multiple servers.
If for some reason the service pack doesn’t appear to be installing properly after the workstations reboot, check the Event Viewer on the workstation. Under the Application branch, look for errors coming from Userenv and Application Manager. By checking these errors, you can often discover problems with the installation. Common errors may include ones dealing with the installation files being damaged or that the installation source was unavailable.
Installation errors may also occur when you first create the group policy and attempt to install it right away on test machines. This is common if the Windows server hasn't refreshed the group policies yet when you restart a Windows XP workstation. On the test machines on our network, the policy applied properly after powering down the workstation, letting it sit for five minutes and then powering it back on.
If the service pack installation fails, you'll have to reapply the policy or manually install the service pack.