Most software deployments using Group Policy rely on the Windows Installer technology to facilitate software deployment and life-cycle management. However, it is also possible to deploy an application setup package that has not been packaged using the Windows Installer technology. This means there are two general approaches for deploying and maintaining software:
Software deployments using Windows Installer packages
Software deployments using non-Windows Installer packages
Each of these techniques is discussed in the sections that follow.
Windows Installer packages are designed to simplify software installation. The Windows Installer technology relies on two key components:
A software installation package file
A software installer service
The software installation package file contains a database of information detailing how the software should be installed and removed. This machine-readable file ends with the .msi extension and is used by the Windows Installer service (Msiexec.exe).
The Windows Installer service is a standard component on all Windows-based computers. The service uses a dynamic-link library (Msi.dll) to read .msi package files. During installation, the contents of the package file tell the Windows Installer service exactly what application files should be copied to the local computer, the shortcuts to create, the registry entries to modify, and so on. This same information can be used when you uninstall an application to completely remove the software.
There are many benefits to using Windows Installer packages, not the least of which is that any application using a Windows Installer package can be self-repairing. How does this work? Well, the Windows Installer package contains all the details needed to install and uninstall the related application. Because it lists all the files and the system configuration required to properly run the software, the installer file can also be used to repair an application that has failed. Here’s how this works: Say that a critical file needed to run the application was deleted or became corrupt. Because of this, the application failed to start for the next user, but because the application was installed using Windows Installer, the file can be used to repair the application by reinstalling the missing or corrupted file.
Other advantages of deploying software with Windows Installer packages include:
Privilege escalation. When you use policy to install managed applications assigned or published to users, the processing runs in an elevated security context so users who belong to neither the local Administrators group nor the Power Users group on their workstations can successfully install the applications. Essentially, during the application installation, the package is in the context of a privileged user, with full rights to install applications on the system.
Transforms. Using Software Installation policy, you can automatically apply one or more Windows Installer transform files during application deployment. Transforms allow you to customize an application’s default Windows Installer package at install time to modify the elements of the application that are installed on the user’s computer.
Advertisement. This feature, also known as install-on-first-use, is a Windows Installer capability that can be leveraged by Software Installation policy. Specifically, when you assign an application to a user, the default installation mode when that user logs on is to advertise the application rather than fully install it. Advertisements are a set of associations that use an "activator"—such as a shortcut, document extension (for example, .doc files for Microsoft Word), or COM object registration. If the user launches one of these activators, the application package is installed.
Upgrades. Using Software Installation policy, you can establish upgrade relationships between old and new versions of applications. For example, if you previously deployed Office XP via policy, you can deploy Office 2003 and create an upgrade relationship between it and the previous version. All computers or users who previously deployed Office XP will be upgraded to Office 2003 when the Software Installation policy is processed.
Automatic removal. Using Software Installation policy, you can automatically remove, or uninstall, an application when the user or computer is no longer subject to the GPO that originally installed the application. For example, if a user gets Microsoft Excel installed on his machine by virtue of being located within the Finance OU within an Active Directory domain, you can specify that if his job changes and he moves into the Marketing OU, Excel will automatically be removed during the next foreground Group Policy processing cycle.
You’ll find that just about every new software application has a .msi package file that can be used to install and uninstall the application. When a .msi package file is included with an application, it is referred to as a native Windows Installer file. Using a native Windows Installer file to deploy software through Group Policy is the easiest deployment technique to use, but you can also create your own installer file.
To create a Windows Installer file, you first need a third-party Windows Installer packaging tool, such as WISE for Windows Installer from Wise Solutions, Inc. The steps you follow to create a .msi package differ depending on the tool you use, but the basic steps are as follows:
Start with a clean installation of each operating system to which you plan to deploy the software. For example, if you plan to deploy the software to Windows XP Professional, start a new installation of Windows XP Professional on a computer and do not install any other application software.
After the operating system is installed, use a software packaging tool to create a snapshot of the computer. You must take this snapshot before you install the application software.
Install the application software on the computer. In most cases, you will perform a standard installation of the software. Be sure to select the install options that will offer the best support and configuration for your users.
After the application is installed, optimize the application configuration. You can create or remove application shortcuts, customize toolbars, set default options, and so on. Run the application at least once in case there are components that install only after startup.
Use your chosen software packaging tool to create a second snapshot of the computer. During this process, you will create the Windows Installer file.
Repeat this procedure for each operating system to which you plan to deploy the software. If you want to install to both Windows 2000 and Windows XP Professional, you will usually need two separate Windows Installer files.
Once you have the necessary installer files, you can use policy to distribute the software throughout your organization.
Once you have your Windows Installer file and have copied all the necessary files to a network share, you can configure software installation through Group Policy. As discussed in "Creating Software Deployment GPOs," in most cases you should create a new GPO, configure Software Installation policy, and then link the GPO to the appropriate sites, domains, or OUs to deploy the software.
To configure Software Installation policy to deploy your software, complete the following steps:
Access Software Installation in Group Policy. For a per-computer software deployment, access Computer ConfigurationSoftware SettingsSoftware Installation. For a per-user software deployment, access User ConfigurationSoftware SettingsSoftware Installation.
Right-click Software Installation and choose New, Package.
In the Open dialog box, type the path to the network share where your package is located or use the options provided to navigate to the package and select it.
Caution
If you are delivering the package from a network share, you must always enter the UNC path to that share when defining the package in policy. Generally speaking don’t use local paths. For example, if you enter the path c:packagesoffice2003pro.msi in policy because the package is on the server’s C drive, the client that is processing that policy will look for the package on its own C drive rather than on the server.
Click Open. If for some reason the network path cannot be verified, you’ll see a warning message asking you whether you want to continue. If you click Yes, the path you entered will be used. If you click No, you will exit the Software Installation deployment process and will have to start over.
In the Deploy Software dialog box (Figure 9-3), you’ll see the Published, Assigned, and Advanced options. Select Published to publish the application without modifications; select Assigned to assign it without modifications. Select Advanced to deploy the application using advanced configuration options, as discussed in the "Configuring Advanced and Global Software Installation Options" section in this chapter.
Note
Global defaults can affect whether the Deploy Software dialog box is displayed. If the dialog box isn’t displayed, a default deployment option is set. For more information, see "Setting Global Deployment Defaults" later in this chapter.
Once the policy is configured, the application will be deployed to all computers or users as appropriate. By default, per-computer software packages are made available when a computer starts up and per-user software packages are made available when a user logs on. As discussed in Chapter 3 under "Refreshing Group Policy Manually," you can also use the Gpupdate command-line utility to force restart and logoff.
To deploy software using a non–Windows Installer package file, you must create a special text-based file called a Zero Administration Package (ZAP) file. Once you have the necessary ZAP file, you can configure the software for deployment through Group Policy. However, this approach is limited and does not provide any of the benefits of a managed application—such as privilege escalation, life-cycle management, and automatic removal. Specifically, you can perform only user-based publishing, which means the program will be listed as an available application in the Add Or Remove Programs utility and user’s will be able to select the application for installation from there. If you include information about an application’s file extensions, you also get a limited install-on-first-use capability.
Other than that, that’s the extent of what you can do with non–Windows Installer package files. The installation of the application runs in the normal installation file and with the user’s normal permissions. This means that although you can pass the installation file optional parameters, you cannot customize the installation. You cannot, for example, perform an installation with elevated permissions, so a user might need local Administrator privileges to install the application. In addition, the self-repair, upgrade, and patching benefits available with Windows Installer files are no longer available.
Note
Because of the limitations of ZAP files, these files are best used for deploying applications that you will not need to upgrade or patch. The only way to upgrade or patch software deployed using ZAP is to remove the existing software through policy and then use policy to redeploy a completely new version of the software.
A ZAP file takes the form of a standard Windows initialization file, with a section header and a set of key, value pairs. The file can be created in a standard text editor, such as Notepad, and must be saved with the .zap extension so Software Installation policy can recognize it.
ZAP files must contain the following sections and keys, at minimum, to be valid:
[Application] FriendlyName="ApplicationName" SetupCommand="\ServernameSharenameApplicationinstaller.exe" /Parameter
where ApplicationName is the name that will be displayed in Add Or Remove Programs, \ServernameSharenameApplicationinstall.exe is the complete path to the application’s installation file on a network share, and Parameter is a setup parameter you want to pass to the application’s installation file.
To see how this would look with an actual application, consider the following example:
[Application] FriendlyName="Microsoft Visio 2003" SetupCommand="\cpandl.comdfsrootpackagesVisio 2003setup.exe" /unattend
This example calls Setup.exe from a domain DFS root share called packages. We also pass an /unattend switch to allow the application to be deployed in an unattended fashion. Note that this switch is setup-package independent. Your application packages might support different switches to provide an unattended setup.
Note
You should consider several caveats when setting the installation path. If the path to the setup command contains spaces or long filenames, it must be enclosed in quotation marks. Also note that referencing drive letters within the SetupCommand path causes the application deployment to fail.
The FriendlyName and SetupCommand values represent the minimum information needed in a ZAP file to properly deploy an application. A set of optional key, value pairs can provide additional information within Add Or Remove Programs. Specifically, the following three keys can provide additional information about the application:
DisplayVersion = VersionNumberToDisplay Publisher = SoftwarePublisher URL = SoftwarePublishersURL
where VersionNumberToDisplay is a software revision or version number you want to display in Add Or Remove Programs, SoftwarePublisher is the software manufacturer, and SoftwarePublishersURL is the URL for the software manufacturer’s Web site. Here is an example:
DisplayVersion = 11.0 Publisher = Microsoft Corporation URL = http://www.microsoft.com/office
The following additional section and key, value pair let give you some limited install-on-first-use capability by associating a file extension with the application being published:
[ext] ext=
where ext is the extension you want to associate with the application being published. In the following example, the file extension .vsd is referenced within the section called [ext]:
[ext] vsd=
If a user who has had this application published via a ZAP file opens a .vsd file, the application is installed from the path specified in the SetupCommand key. However, because ZAP file–based deployment provides no privilege escalation, the user must have sufficient rights on her machine to be able to successfully run the application setup.
Example 9-1 shows a complete listing of a ZAP file based on the previous examples.
Once you have your ZAP file and have copied all the necessary files to a network share, you can configure software installation through Group Policy. As discussed previously in "Creating Software Deployment GPOs," in most cases you should create a new GPO, configure Software Installation policy, and then link the GPO to the appropriate sites, domains, or OUs to deploy the software.
To configure Software Installation policy to deploy your software, complete the following steps:
Non–Windows Installer files can be installed only on a per-user basis. Access Software Installation under User ConfigurationSoftware SettingsSoftware Installation.
Right-click Software Installation and choose New, Package.
In the Open dialog box, type the path to the network share where your package is located or use the options provided to navigate to the package and select it.
Caution
If you are delivering the package from a network share, you must always type the UNC path to that share when defining the package in policy. Generally speaking, don’t use local paths. For example, if you enter the path c:packagesvisioviso.zap in policy because the package is on the server’s C drive, the client that is processing that policy will look for the package on its own C drive rather than on the server.
In the Files of Type list, select ZAW Down-Level Applications Packages (*.zap) as the file type.
Click Open. If, for some reason, the network path cannot be verified, you’ll see a warning message asking you whether you want to continue. If you click Yes, the path you entered will be used. If you click No, you will exit the Software Installation deployment process and will have to start over.
In the Deploy Software dialog box, select Published to publish the application without modifications. Select Advanced to deploy the application using advanced configuration options, as discussed in the next section.
Note
Global defaults can affect whether the Deploy Software dialog box is displayed. If the dialog box isn’t displayed, a default deployment option is set. For more information, see the "Setting Global Deployment Defaults" section in this chapter.
Once the GPO is configured, the application will be advertised to all users as appropriate. By default, Software Installation policy published to users is applied only when a user logs on. As discussed in Chapter 3 under "Refreshing Group Policy Manually," you can use the Gpupdate command-line utility to force logoff.