Using Group Policy to Deploy XP

Upgrading systems within a network environment requires a substantial commitment of time and money, especially when you deploy a new client OS such as Windows XP. The process entails thorough planning and testing before finally installing the new software. Planning requires the most effort because you likely have limited resources and must allocate what you have efficiently. Upgrading clients selectively (e.g., by department) can increase efficiency during deployment, and automating this process increases efficiency even further. Let's discuss using Group Policy—managed software to automate a client OS upgrade to XP. Group Policy—managed software is a great solution that lets you easily upgrade Windows 2000 Professional machines to take advantage of the new benefits of XP Professional Edition.

Using Group Policy for Deployment
Microsoft designed Group Policy to let you granularly control settings for groups of users and computers. As a result, you can use Group Policy to deploy software packages within organizational units (OUs), for example. Win2K introduced software installation to Group Policy and provided even more granular control, but an Active Directory (AD) infrastructure is required.

Using Group Policy to deploy XP Pro simplifies much of the testing and installation stages of deployment, as I explain in this article. XP Pro includes a Windows Installer (.msi) file that requires only minor customization for Group Policy deployment.

Group Policy has two software installation types: user and computer. You can assign or publish user software installation packages. When you assign an application, a shortcut appears on the user's Start menu and registry changes occur that advertise the application. The application then installs on first use. A published application doesn't have advertisements, but the application becomes available when the user clicks Add New Programs from the Control Panel Add/Remove Programs applet. Computer software installation packages have only the Assigned option. The application installs after the next boot to all computers that the Group Policy affects, which lets you efficiently deploy software to users and computers according to factors such as group or department. The only minor disadvantage to using managed software to deploy applications is that Win2K Pro must be running on the client computers.

Typically, installation packages are self-healing, meaning they repair themselves if anything becomes corrupted or lost and let you easily uninstall the files by using the Group Policy console. Group Policy provides an easy, efficient method for deploying XP, but the deployment doesn't let you take advantage of all the benefits of managed software. For example, when you deploy XP, you can assign the deployment of XP packages only to computers, not to users. This limitation makes sense because you wouldn't want users to accidentally click a Start menu link and install Windows at an inappropriate time. User software installation packages uninstall from a computer when the user logs off and reinstall upon logon. In essence, the application "follows" the user. Having Windows install and uninstall every time a user logs on to and off of a computer isn't feasible. Also, be aware that you can't use Group Policy to uninstall the XP software package, as you can with other applications. To uninstall XP, you must visit each computer to manually invoke the uninstallation.

The benefits of using Group Policy far outweigh the drawbacks. You create just one XP package, which you can then use for all deployments in your organization, including test deployments. With this one package, deployments are simple: You create a test OU, add the computers on which you want to test the deployment, then assign the package to that OU's Group Policy. When you're satisfied that your test deployments are successful, you can start assigning the package to other OUs' Group Policies as you see fit. The package upgrades only computers in the OUs you specify. When you're ready to perform a full deployment, you can do so selectively—for example, by department—with relative ease.

After you assign the package, all computers in the OU will begin the installation after the next boot, which means that you must reboot each computer to start the upgrade. Because you'd probably rather not have to manually reboot dozens or hundreds of machines yourself, I show you how to automate this step and schedule it to occur after business hours.

Creating the Software Installation Package
The first step when preparing to use managed software to deploy XP is to create a network share that all workstations can access. Make sure that the Everyone group has read and execute NTFS permissions and read and execute share permissions to the folder. You can even create a hidden share to prevent users from accessing the folder accidentally. Copy the entire contents of an XP Pro CD-ROM to the share; without the full contents, this procedure won't work. (This article assumes that you have a volume license copy of XP.)

Next, you must edit the default .msi file that comes with XP. To perform this step, you need an .msi database editor, such as Orca. (To learn how to obtain and install Orca, see the sidebar "Installing Orca.") Run the .msi editor, then open winnt32.msi from the shared directory you created. You must change the action that occurs when the installer runs. Click CustomAction, as Figure 1 shows, then change the value in the Target field for both RunSetupImmediate and RunSetup to

"<SourceDir>winnt32" /s:"<SourceDir>."/unattend:"<SourceDir>unattend.txt" /batch 

Save winnt32.msi to the directory share (you might have to disable read-only permissions first).

Configuring Unattend.txt
Many organizations use unattend.txt files to customize software deployment. You can use the unattend.txt file to specify any installation options that you want to provide during the installation. Using an unattend.txt file not only lets you run unattended installations but also guarantees that all your computers have the same settings. If your organization doesn't use an unattend.txt file, create a new one or use one that suits your organization's needs. In either case, be sure to include the following attributes:

The NTupgrade option instructs the installer package to perform an upgrade, and ProductID provides the product key. These parameters let the upgrade run and finish without any user input after the installation starts.

Linking the Software Installation Package
You link the XP software installation package in Group Policy just as you would any other computer-assigned package you deploy though managed software. Open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, right-click the OU that contains the computers you want to upgrade, then choose Properties. Click the Group Policy tab, then choose Edit (choose New if a policy doesn't already exist). Under Computer Configuration, expand Software Settings. Right-click Software Installation, then select New, Package. Enter the Universal Naming Convention (UNC) path to winnt32.msi. In the Deploy Software dialog box that appears, choose Assigned, as Figure 2 shows, then click OK. The package is then queued to install the next time the client computers reboot, as Figure 3 shows. Upon reboot, Windows will invoke the installer and use the unattend.txt file you created, and the automated installation will run.

Restarting Client Computers
You can use a script to instruct the client machines to reboot at an opportune time (e.g., after business hours). The script, which Listing 1 shows, searches the OU you specify for computers, then creates a batch file with a shutdown command for each of them. You must schedule a task to run this batch file when you want the upgrade to occur. Open Task Scheduler and create a new task. Choose Add New Task. When Task Scheduler prompts you for the program to run, click Browse, then locate and select the batch file that the script created. When Task Scheduler asks how many times you want to perform the task, select One Time Only.

On the next page, specify when you want the reboot to occur—I suggest you reboot the machines the same evening that you link the software installation package to Group Policy so that no users have the chance to reboot their machines and inadvertently launch the upgrade before the scheduled time. Enter a username and password to run the script. Make sure the account is a member of the Domain Admins group and the Administrators group in the domain, and make sure that Force shutdown from a remote system isn't defined under User Rights Assignment in the domain policy or that both Administrators and Domain Admins are present there. Everything is now configured, and XP will install as an upgrade to all the computers in the OU you specified at the time you set in Task Scheduler.

Saving Time
Using Group Policy to upgrade client machines is a great time-saver. The process is efficient and flexible and is especially useful for upgrading systems that didn't ship with XP. You might consider various alternatives, including Microsoft Systems Management Server (SMS) packaging and disk cloning, but such options require considerable resources, more bandwidth, and substantial configuration.

If you have many Win2K Pro machines that you need to upgrade to XP, consider the process I've described. Just remember to try the installation package on a test OU before rolling it out to other users.