Using Group Policy to Deploy XP

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:

• [Unattended]
• NTupgrade=yes
• [UserData]
• ProductID=(insert your product key here)

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.