Packaging Software for Deployment
Updated: March 28, 2003
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2
Each time you use the software installation extension of Group Policy to deploy an application, patch, or upgrade package, you must first prepare the application for Windows Installer. If the application does not include a natively authored Windows Installer package (.msi), you must obtain one or create a .zap file.
Each Windows Installer package file contains a database that stores all the instructions and data that are required to manage the state of a program. For example, an .msi file of an application might contain instructions for installing the application when an earlier version of the application has been installed. The .msi file might also contain instructions for installing the software on a computer where that application has never been installed.
To package software, you might only have to perform an administrative installation to prepare the application for later installation by client users or computers from a network location. However, you might want to customize the application deployment so that you can create a transform that modifies the .msi. Also, if your application does not include a Windows Installer package, packaging can be much more complex. In that case, you must determine how long your organization expects to use the application. Your decision might lead you to reauthor the Setup.exe file of the application.
Figure 8.3 illustrates the process for packaging software for deployment by using Windows Installer and the software installation extension of Group Policy.
Figure 8.3 Packaging Applications for Deployment
Using Native Windows Installer Packages
Many software authors develop applications to include native Windows Installer packages. A native Windows Installer package contains a single product, such as Microsoft® Office 2000, which can be made up of several features, such as Microsoft® Word, Microsoft® Excel, and Microsoft® PowerPoint®. However, you can configure the software to install features individually. When the user selects an uninstalled feature, the feature is installed. Each feature (Word, Excel, PowerPoint, and so on) contains components, such as a thesaurus, spelling checker, or an additional user-interface language. When the user selects a feature or component that is not installed, the feature or component is automatically installed. Automatic installation of selected features saves network bandwidth during the initial installation. It also gives users only the features and components that they need to do their jobs. Automatic installation can also save space on users’ local disk drives. However, this type of installation delays the availability of a feature when the user first selects it.
Windows Installer packages ensure that an accidentally deleted file, such as Winword.exe, is reinstalled the next time the user tries to start Word because Windows Installer detects and reinstalls missing files.
After you obtain a native Windows Installer package, perform one of the following tasks if the application you plan to deploy includes a native Windows Installer package:
If the package requires no further customization, copy it to the designated shared folders on the software distribution point servers.
If you want to modify the .msi package use transforms to customize it.
For information about copying packages to the software distribution servers, see "Deploying Applications in a Managed Environment" later in this chapter.
Customizing Windows Installer Packages by Using Transforms
A transform (.mst file) is a collection of specified changes that you apply to a base Windows Installer package file at the time of deployment. After you package the software in the Windows Installer package format, you can use transforms to customize the software for your organization. At this phase, the modular design of Windows Installer packages simplifies deployment. When you apply transforms to an .msi file, Windows Installer can dynamically add or modify data in the installation database to customize the installation of the application.
Office 2000, for example, provides the Office 2000 Custom Installation wizard, which you can use to build transforms. You can create a transform for managing the configuration of Office 2000 that you deploy to users in your organization. Other tools in the Windows Installer SDK, or other non-Microsoft tools, can also help you to create transforms for Windows Installer packages that do not include their own custom installation tools.
Purposes for Transforms
Transforms tailor the installation of an application. Although they are optional, you can use transforms for a variety of purposes including encapsulating and customizing.
Customizing can involve configuring installations so that a particular set of features from a specified software application, or suite of software applications, is installed locally on the computer.
You can also use transforms to add new features to an existing application’s package. For example, you can add custom Excel templates for the Finance group. However, if the templates change frequently, it might be a better practice to package them, and then assign or publish them as a separate package.
You can encapsulate numerous customizations of a base package that are required by different groups. For example, in organizations where the Finance and Marketing departments require different installations of a product, you can make the product’s base package available to everyone at one software distribution point. Then you can distribute the appropriate customizations separately as transforms to each group of users.
Store transforms at the same software distribution point and in the same shared folders as the Windows Installer package that they customize or the installation will fail.
Customizing a Native Windows Installer Package Example
An organization maintains a large number of applications. Some of these applications contain native Windows Installer packages that require some customization, and many of the applications require modification to prepare them for Windows Installer. The Finance and Marketing departments of the organization require different installations of a custom-designed customer database application that includes a native Windows Installer package (.msi). The Finance department requires financial information about customer accounts, and the Marketing department requires customer purchase history to determine the best use for marketing resources.
The software administrator made the application’s base package available to everyone from one software distribution point, and then distributed the appropriate customizations to each group of users separately as transforms. To achieve this, she did the following tasks:
Copied the original .msi to the designated software distribution point servers.
Created two separate transform files (.mst), each containing the customizations for the Finance and Marketing departments.
Copied the .mst files to the same shared folders on the software distribution point server where the original .msi files are located.
Created a <a ID="wPopUp" href="help=glossary.hlp TOPIC=gpo1">GPO </a>and assigned the application to the users in both the Finance and Marketing departments.
When users log off and log on again, the application is published on their desktops, and it is also listed under Programs on the Start menu.
You associate a transform with a Windows Installer package by using a GPO when you first deploy the package.
To associate a transform with a Windows Installer package by using a GPO
Select the software installation extension of the Group Policy object.
In the right pane of the Group Policy Object Editor, right-click the managed software.
In the appropriate fields on the Modifications tab, specify the modifications or transforms that are associated with the package.
Do not change the manufacturer’s product code for the package when you create a transform to customize a native Windows Installer package. The software installation extension of Group Policy treats the new code as a new product. This can cause a failed installation and void your licensing agreement.
Modifying a Transform
To modify a transform by using the software installation extension of Group Policy, you can create an upgraded relationship between the application and the old transform, or between the application and the new transform. An appropriate time to do is this when you create a new transform or when you distribute new software that requires a transform.
To modify a transform
Create a new .mst file.
Remove the existing associated .mst files by using the software installation extension of the Group Policy Object Editor.
Associate the new .mst file by using the original .msi.
Remember that a transform is applied at the time of assignment or publication, not at the time of installation. Verify that the Modifications tab of the package properties dialog box is properly configured before you click OK. If you do not do this, and you deploy an incorrectly transformed package, you must either remove the software and redeploy it, or upgrade the software to a correctly transformed version.
After Modifying a Transform
After you create or modify a transform, you must deploy the new transform.
To deploy a new or modified transform
Copy a new .msi file and a new .mst file to the designated shared folders on the software distribution point servers.
Delete the existing package object from the software installation extension of the Group Policy Object Editor.
Associate the new .mst file with the original .msi file.
Deploy the new package and the transform at the same time.
For information about copying software to the software distribution point servers, see "Deploying Applications in a Managed Environment" later in this chapter.
Reauthoring Applications for Windows Installer
When you reauthor an application, you create an application that adheres to the Windows Installer format. You are essentially redeveloping the setup portion of the application to take full advantage of the advanced capabilities of Windows Installer.
If you plan to reauthor an application that does not include a Windows Installer package, you must have the following:
All executable files, dynamic-link library (DLL) files, and other resources. For all but the simplest applications, you need the source code to understand the logic and actions of the original setup program.
An understanding of the application and the registry entries, shortcuts, and other information that are needed for it to run correctly.
An authoring tool that supports creating Windows Installer packages.
There are some authoring tools available to help developers create new Windows Installer packages, but the procedures can be resource-intensive and costly. If you determine that the application will play a key role in the future of the company, it is important to weigh the benefits of reauthoring the application with the costs of reauthoring the application.
Tools to Help You Create Windows Installer Packages
Several tool vendors supply .msi package–authoring tools that developers can use to create Windows Installer packages. Such authoring tools include, but are not limited to:
Microsoft® Visual Studio® Installer
Microsoft® Visual Studio® .NET
Commercial installers for Windows
To develop any new or custom applications for your organization, use Windows Installer technology during the design phase. By designing the application with Windows Installer in mind from the outset, you can take full advantage of Windows Installer capabilities.
If you plan to reauthor an application to include a Windows Installer package, see the Windows Installer Software Developer’s Kit (SDK) link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources
For more information about the Microsoft® Visual Studio® Installer authoring tools for installing software, see the Microsoft Visual Studio Installer link on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources
After Reauthoring Applications for Windows Installer
After you have reauthored an application to include a Windows Installer package, the next step is to perform one of the following tasks:
If the package requires no further customization, copy it to the designated shared folders on the software distribution point servers.
If you want to customize the .msi package for your users, use transforms (.mst files) to modify it.
For information about copying packages to the software distribution point servers, see "Deploying a Managed Software Environment" later in this chapter.
Reauthoring an Application for Windows Installer Example
Administrators have developed a simplified custom application so that users can arrange their own business travel. Because the application was developed internally, the organization has all the files for the software, and the developers understand how the software must be installed. IT management determined that this application is ideal for reauthoring packages for Windows Installer.
To reauthor the business travel application, the administrator performed the following tasks:
Compared the benefits of having the application with the costs to reauthor it.
Identified the developers to perform the task of reauthoring the application.
Chose the appropriate reauthoring tool.
Reauthored the application to include a native Windows Installer package.
Placed the native .msi on the software distribution point.
Created a GPO and published the application for a particular group of users.
Users who need the business travel application can go to Add or Remove Programs in Control Panel, and then download the software from a published list of applications.
Creating .zap Files
Applications that do not use the .msi file format for the Windows Installer Service can be set up for distribution by creating a text file that has a .zap file extension. This method is not as flexible as .msi package files. If you have many applications that do not contain native Windows Installer packages, and you know that your organization plans to discontinue these applications, you can create software installation settings (.zap) files for the installation executable (such as Setup.exe or install.exe) files. Additionally, if you use custom applications that do not have Windows Installer support, but you plan to use them in the long term, .zap files might be your only choice. When you create .zap files, you do not benefit from the capabilities of Windows Installer. By creating .zap files, you wrap 32-bit or 64-bit Setup.exe files into a .zap file format that the software installation extension of Group Policy recognizes. This method allows you to publish the applications for users to install by using Add or Remove Programs.
Because these applications do not use Windows Installer setup programs, they do not do the following:
Use elevated permissions for installation.
Install a feature on the first use of the feature.
Roll back an unsuccessful operation, such as install, modify, repair, or removal.
Detect a broken state and automatically repair it.
Implement customized installations (transforms).
Suggestions for Working with .zap Files
When you work with .zap files, consider the following:
While applications that are installed by using .zap files run their original setup programs, they do not run with the elevated permissions that Windows Installer packages have. If installing the application requires administrative permissions, only users who have those permissions can install it.
Because .zap files are typically created by using text editors, the files might have a .zap.txt file name extension. Make sure that the file name extension of a .zap file is only .zap (without the .txt extension). Also, make sure that any software installation file that you distribute by using GPOs does not end in .txt.
If you have 64-bit clients, test 32-bit .zap applications to verify that you can install and run them on 64-bit clients. This is important because more .zap applications fail on 64-bit clients than on 32-bit clients.
Unless you change the default behavior, 32-bit .zap applications are deployed so that they are not listed in Add or Remove Programs on 64-bit clients.
After Creating .zap Files
After you create a .zap file, copy it to the designated shared folders of the software distribution point servers. You can then use the software installation extension of Group Policy to publish the application in Add or Remove Programs in Control Panel. This makes the application readily available to users. You cannot customize .zap files by using transforms.
Creating a .zap File Example
The software administrators of the organization have identified a group of users who use an Excel template that is only compatible with Microsoft® Excel 97. Although all other users in the organization plan to upgrade to Microsoft® Office XP, this group of users must continue using Excel 97 until the end of this particular project. Excel 97 does not include a native .msi package file. After this project is completed, this organization has no further need for Excel 97.
To make sure that these users have Excel 97, the administrator performed the following tasks:
Wrapped the setup program of Excel 97 into a .zap file.
Copied it to the designated software distribution point servers.
Created a GPO and published the software to that particular group of users.
The users who need Excel 97 can now go to Add or Remove Programs in Control Panel, and then download the software from a published list of applications.
To publish Excel 97 by using the existing Excel 97 setup program, only the three path-information lines are needed in a .zap file. The following example represents the .zap file that the software administrator created for the purpose of deploying Excel 97 to the users on this project.
<Application> FriendlyName = " Microsoft Excel 97" SetupCommand="" \\server\share\Excel 97\setup.exe""
The path and the name of the .exe file are enclosed in quotation marks in the Application section. If there are no command-line arguments, the .exe file path and name must be enclosed in two sets of quotation marks. For example:
SetupCommand=" \\server\share\long folder\setup.exe" /argument SetupCommand="" \\server\share\long folder\setup.exe""
SetupCommand="setup.exe" /argument SetupCommand=""setup.exe""
When you create your own .zap file, modify the information in the preceding sample .zap file according to the application that you are managing and the location of your software distribution point.
For more information about publishing .zap file-packaged applications, see "Targeting Software to Users and Computers" later in this chapter.
Packaging 64-Bit Applications
In the Windows Server 2003 family of servers, the software installation extension of Group Policy and Windows Installer 2.0 continue to support and protect the investment that you have made in 32-bit applications. Additionally, Microsoft® Windows® Server 2003, Enterprise Edition and Windows® Server 2003, Datacenter Edition introduce support for 64-bit application installation.
Windows Installer version 2.0 installs three types of Windows Installer packages on a computer running a 64-bit operating system:
32-bit packages that contain only 32-bit components
64-bit packages containing some 64-bit components and some 32-bit components
64-bit packages containing only 64-bit components
You cannot publish or install a 64-bit application on a 32-bit operating system.
You can use the Software Installation extension of Group Policy to allow or disallow installation of 32-bit applications to 64-bit clients.
To allow or disallow installation of 32-bit applications on 64-bit clients
Open the Group Policy Object Editor to the Software Installation item.
Right-click the managed software, and then select Properties.
On the Deployment tab, click Advanced.
You might decide not to deploy a 32-bit package to a 64-bit system if that application functions poorly or not at all on 64-bit systems. Make your configuration determinations as you test the applications and system combinations in your test lab and during your pilot phase. For more information about piloting the deployment of applications, see "Conducting a Pilot for Software Deployment" later in this chapter. For guidelines about testing the applications in your organization, see "Planning and Testing for Application Deployment" in Planning, Testing, and Piloting Deployment Projects in this kit.
Do not deploy a 32-bit application that uses the same Windows Installer 2.0 Product ID as a 64-bit application. Instead of creating such Windows Installer 2.0 packages, create a separate Product ID for the 64-bit version of a product. Windows Installer does not support different architecture packages that have the same product code.
If you incorrectly configure a 64-bit package for 32-bit clients (or use the wrong Product ID), Group Policy tries to install it, but then removes the package at logon. It then installs the package again the next time a user logs on, and then removes it again, creating network traffic and preventing users from using their computers.
Repackaging Applications for Windows Installer
When you cannot reauthor a package to use Windows Installer, you might want to repackage it. Repackaging an application for Windows Installer involves taking a snapshot of a clean computer (including the registry settings, files, and system settings), installing the software, and then taking a post-installation snapshot of the computer. The repackaging software detects the difference between the two snapshots, and then creates the necessary instructions to reproduce the installation. If any registry changes, files changes, or system setting changes occur during the capture process, they are included in the installation. You use repackaging when you do not have control over DLL files, source code, and registry entries, or for applications about which you do not have in-depth knowledge.
Use this method only as a last resort when you need to repackage an application into an .msi. It is easy to underestimate the cost of repackaging in terms of labor hours. Also, users often set their expectations too high for the reliability of repackaged applications. Repackaging requires a thorough knowledge of the application’s installation program and of the Windows Installer setup on the Windows platform.
Success with repackaging is affected by the state of the computer where you perform the repackaging. For best results, always perform a repackaging by using a clean computer. For the purpose of repackaging, a clean computer is defined as a computer that has only the operating system and operating system service packs installed before you run the repackaging software. Because of this limitation, and other issues, repackaging is not recommended.
Repackaging is not a function or a feature of Windows Installer. As with reauthoring applications, several vendors provide tools to enable administrators to repackage applications for a variety of needs. The same vendors who provide tools to reauthor applications can also help you repackage them.
When you repackage an application, you replace the existing components, such as DLLs, .ini files, registry settings, and shortcuts, and then you create a path for Windows Installer to find these items at installation time.
Packages that you create on a computer running Windows 2000 by using Veritas WinInstall LE, will work on target computers running Windows XP. However, the Veritas WinInstall LE program itself does not run on Windows XP. For more information about repackaging applications on newer computers, contact your repackaging-software vendor.
Microsoft supports authoring and customizing applications that natively use Windows Installer for installation and maintenance. However, Microsoft does not provide support for applications that are repackaged as .msi files. Contact the application manufacturer for this type of support.
As with other repackaging techniques, repackaging applications into the Windows Installer format has limitations and might not be supported by the application manufacturer. For more information, contact each application manufacturer.
If you have an application that does not include a native Windows Installer package, and you decide to repackage it in the .msi format, see the Windows Installer SDK for detailed documentation about the Windows Installer package format. For more information about the authoring tools for deploying a managed software environment, see the product links, as listed by product name, on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources.
After you repackage an application for Windows Installer, copy it to the designated shared folders of the software distribution point servers. You cannot customize repackaged applications by using transforms.