When a client recently asked for help in reducing the amount of time the IT staff was spending installing systems and applications, coming up with a solution didn't take much effort. Remote Installation Services (RIS) and Group Policy were just the ticket. With a little effort up front, this combination can save you a lot of administrative overhead you would otherwise incur installing Windows and applications. Perhaps more important, automated OS and application deployment can pull your fat out of the fire when the CEO's hard disk crashes.
Applications: One Part of the Puzzle
Deploying new systems, either when a new employee comes on board or when you upgrade existing users, can consume a lot of time that you could otherwise spend on more crucial tasks. Anything you can do to automate the process will make your life a lot easier.
Setting up a new system typically requires installing a client OS, installing applications, and configuring items such as shared documents or templates. A handful of OS installation methods exist, including RIS, which comes with Windows Server 2003 and Windows 2000 Server. RIS is relatively complex when you take into account service packs, slipstream installations, and image duplication, so I won't cover that part of the puzzle here. (For more information about using RIS, see "Remotely Deploy Windows 2000," May 2000, http://www.winnetmag.com, InstantDoc ID 8433.) Instead, I focus on the second and third phases of system setup: installing applications and setting up a user's documents and working environment. However, you should consider all three phases as essential to a comprehensive approach. Here's why.
If you take a manual approach to system setup, you'll likely spend in the neighborhood of 2 hours per system installing the OS. Incorporating a slipstream installation of all service packs and patches or starting with an OEM-installed OS can cut that time in half. If all your workstations have the same hardware, you could use disk-imaging software to install the OS. (See "Automated Deployment Services," page 43, for information about Microsoft's disk-imaging solution.) Whatever your approach, you're to spend at least some time just getting the OS ready.
When the OS is installed, your next step is to install whatever applications your users will need. The time you spend on this task can vary considerably depending on the number of applications. After the applications are installed, you face the prospect of updating them when application vendors release bug fixes and enhancements.
Automating this entire process not only gives the IT staff time for other tasks but also gives you greater control over which applications a given user will receive. The key to managing applications automatically is Group Policy, which gives you two ways to deploy applications.
Publish or Assign Applications
Through Group Policy, you can either publish or assign applications. When you publish an application, it appears in the Control Panel Add or Remove Programs applet so that users can choose whether to install the application. You should publish applications that you want made available to users but that aren't required.
When you publish an application, you can specify a category for it (I explain how to set up categories a little later). Any categories you specify also appear in the Add or Remove Programs applet, as Figure 1 shows, and serve to organize the applications into logical groups. For example, you might place Microsoft Office, Office Visio, and other Office-related applications in an Office group; Autodesk's AutoCAD and other graphics-related applications in a CAD/Engineering/Graphics group; and so on. Categorizing applications can help users find the applications they want to install.
Assigned applications work differently from published applications. When you assign an application, it shows up in the user's Start menu as if it's already installed. Then, when the user starts the application for the first time, Setup performs a just-in-time (JIT) installation of the application from the network installation share, just as it does when you install an application locally and choose the Install On First Use option. Windows 2003 adds the capability to automatically install assigned applications when the user logs on for the first time, eliminating the need for user-initiated installation. You should assign, rather than publish, applications that users must have.
As you determine which applications to publish and which to assign for specific user groups, you might realize that your Active Directory (AD) needs a little reworking to support application deployment. For example, if all the users in a department typically need the same applications and your AD organizational units (OUs) don't align with departments, you might need to create OUs and adjust OU membership accordingly. Doing so will let you create Group Policy Objects (GPOs) that deploy applications to users as needed. You can use domain-level GPOs to deploy applications that everyone needs. Restructuring the AD namespace is a good idea only for namespaces that are currently unstructured, however. A better approach for structured namespaces is to use security group filtering of GPOs to control deployment.
After you decide who will receive which applications and how, you're ready to start setting up the servers and shares to make the application packages available. Group Policy uses Windows Installer to install applications, so the first step in making the application available is to obtain or create the Installer package. If the application comes prepackaged as an .msi file and your deployment doesn't require any modifications, such as the addition of custom files or changes to installation options, you can typically just copy the source files from the application CD-ROM to the target share on the server.
In many cases, however, you'll need to customize or create the Installer package. A handful of third-party applications—among them OnDemand Software's WinINSTALL, InstallShield Software's InstallShield, and Wise Solutions' Wise for Windows Installer—let you create new Windows Installer packages or repackage existing ones. Microsoft offers Visual Studio Installer as a free download, but it requires an existing Visual Studio (VS) product to run. OnDemand Software's WinINSTALL LE 2003 is a free, limited-function option.
Simple applications require only that you package their files into an .msi file. For more complex installations, such as Microsoft Office, you can create a transform file to specify a set of exceptions to the package's defaults. For example, you might create a transform file to install a subset of the Office applications, specify the installation location, and set other installation options. Transform files are particularly useful for targeting one set of application source files to multiple groups of users who need different installation options. You create an .msi file to service all the users, then apply transforms to tailor the installation for individual groups.
Each packaging application has its strengths and weaknesses. If you don't already have a packager, take the time to download evaluation copies and test them to find the one that best suits your needs. When you're comfortable repackaging applications and creating transforms, you're ready to start setting up the distribution points for your applications.
Set Up Distribution Shares
Before you publish or assign an application in Group Policy, you need to put the application package on a network server where it will be available to users when they need to install it. No specific service is required to host an application package, so almost any file server will do. However, you need to take into account the number of users who will be installing applications and other factors such as available bandwidth, the number of applications a server will support, other services hosted by the server, and security considerations, and distribute applications to servers accordingly.
Server availability is another important consideration, particularly as the number of users who rely on Group Policy–deployed applications grows. You can use Dfs in Windows 2003 and Win2K Server to help ensure that application installation shares are available even if a server goes down. Dfs lets you place an installation folder on multiple servers and add the folders as replicas under the Dfs root. If one server goes down, users can still install the application from one of the other replicas in the root. The redirection happens automatically and is transparent to your users and to Group Policy, which references the folder's generic replica Universal Naming Convention (UNC) path in the Dfs namespace, not the absolute target path.
To set up a share, create a folder on a server to act as the root of your application folders, configure permissions on the folder as necessary, then share the folder. Create individual application folders under the share, then copy the package files for a given application to its folder. You can use NTFS compression on the share folders to help manage disk usage.
Create the GPO
With the Windows Installer package in place for an application, you're ready to create the GPO that will deploy the application. Open the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in, right-click the domain or OU for which you want to apply the policy, and click Properties. Go to the Group Policy tab, then create a new GPO or select an existing GPO and click Edit.
The Software Settings\Software Installation policy branch, located under both the Computer Configuration and User Configuration branches, is the creation point for application deployment packages. Use the Computer Configuration branch to deploy to computers that process the GPO, and use the User Configuration branch to deploy to user accounts that process the GPO. However, understand that you can only assign applications through the Computer Configuration branch, not publish them. If you need to publish an application, create or modify the GPO in the User Configuration branch.
Before you create your first package policy, add any application categories under which you want to publish applications (these are the optional categories that will appear in users' Add or Remove Programs applet). To do so, right-click Software Installation under User Configuration and choose Properties. The General tab lets you set the default application package location, the default deployment type (publish or assign), and UI options. I discuss those settings in more detail shortly. For now, go to the Categories tab, click Add, and add the application categories.
To create a package policy, right-click the Software Installation branch under Computer Configuration or User Configuration and choose New, Package. In the Open dialog box, specify the path to the package file. In almost every case, you should use a UNC path to ensure that users will be able to access the share. Use an absolute path only if the users' local drive mapping to the share will always be the same as the server's local drive letter.
After you specify the package file path, Group Policy Editor (GPE) displays three options: Published, Assigned, and Advanced Published or Assigned. Choose one of the first two if you don't need to add transforms, configure upgrade packages, or set other advanced options when you create the policy. Choose Advanced Published or Assigned if you do need to set advanced options. You can change most of the options later, regardless of whether you choose one of the basic options or the Advanced option here. To do so, just double-click the package in the GPO to open its property sheet, which is the same one that GPE displays when you choose the Advanced option. However, if the package needs one or more transforms, choose the Advanced option and add them when you create the package policy—you can't add transforms after you've deployed a package.
The General tab now shows general information about the application and publisher. After you create the package, the only property you can change here is the package name as it will appear in GPE. Switch to the Deployment tab, which Figure 2 shows, to specify the deployment type and other deployment options. If you want the application to be installed automatically when the user attempts to open a document type that requires the application, select Auto-install this application by file extension activation. If you want to remove the application from the user's system when the GPO no longer applies to the user, such as when the user moves to a different department (and therefore falls under the scope of a different GPO), select Uninstall this application when it falls out of the scope of management. If you want to prevent the application from appearing in the Add or Remove Programs list, select Do not display this package in the Add/Remove Programs control panel. To display only basic installation information during application installation, select Basic; to display all setup information, select Maximum. Click Advanced to configure the application to ignore language during deployment or to remove an earlier version of the application not installed by Group Policy.
Use the Upgrades tab to specify packages in the current GPO or in another GPO that this package upgrades. You can make the upgrade optional or mandatory and specify whether the application should remove the existing version first or install itself on top of the existing version.
If you added application categories earlier, you can use the Categories tab to specify the categories in which the application will be listed in users' Add or Remove Programs applet. Choose an existing category and click Select to add it to the Selected Categories list for the application. You can add multiple categories for an application.
If you're creating as opposed to editing the package, you can use the Modifications tab to add transform files to the package. You can specify multiple transforms and control the order in which the transforms are applied. Finally, use the Security tab to configure permissions for the package policy. For example, you might have a subset of users that falls under the scope of the GPO but to which you don't want to make the application available. Simply remove the Read permission for these users to prevent the policy from applying to them.
Redirect User Folders
Although folder redirection isn't a necessary step, I consider it an important complement to automated OS installation and Group Policy–based application deployment to ensure a complete disaster-recovery scheme. For example, if you use RIS to deploy users' OSs, users can get a functioning computer simply by plugging a new system into the network, booting it, and following a few prompts. When users log on after the OS installation, their applications are either installed automatically (if assigned) or made available through the Add or Remove Programs applet (if published). But what about the users' documents?
If users store documents locally and a user's computer dies, the user must restore his or her documents from a local backup—if one exists. If user documents are stored on the network, you can restore them from a network backup or by using Windows 2003's Volume Shadow Copy Service (VSS). In all these cases, restoring the files will take some time and effort because the user or administrator must go hunting for the previous versions. However, if you've redirected users' folders to their home folder on a network share, neither you nor your user needs to do anything to retrieve the documents lost from the local system because the documents are still intact on the server. The user can simply log on from his or her new system, open My Documents, and find the documents right where they should be. If this feature sounds appealing and you decide to configure it, open the User Configuration\Windows Settings\Folder Redirection branch in the GPO. Right-click the My Documents folder under the branch, select Properties, then specify redirection settings for the folder in the dialog box that Figure 3 shows.
Note that the recovery scheme I've suggested doesn't address restoration of users' custom application settings. You can either employ roaming profiles or use application-centric methods and tools such as the Microsoft Office Resource Kit's Save My Settings Wizard to complete the recovery scheme and ensure that users' customized applications are intact after a recovery.
Costs and Limitations
Most of the tools and technologies you need to deploy applications with Group Policy are built into Windows 2003 and Win2K Server. Because deployment relies on Group Policy, however, only Win2K or later clients can take advantage of automated deployment. The only real capital investment—assuming you don't need to add servers to handle the distribution shares—is for a good packaging application, which won't break the bank. If you also integrate RIS into the picture, you'll likely need to spend at least some money on Preboot Execution Environment (PXE)–compliant adapters for existing systems and perhaps for server hardware.
The amount you spend on these items will likely be minimal when you compare the savings in administrative time that would otherwise be spent in setting up systems and handling disaster recovery for your users. The amount of work required up front to make policy-based application deployment happen is relatively small, and I guarantee you'll make up most of that time and expense the first time you need to deploy a new system or recover the CEO's computer after a crash.
