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.

   Previous  [1]  2  Next