Supplemental Applications Feature Team Guide

This section describes the focus of the six role clusters during the Planning Phase. It also explains the importance of a lab environment, packaging techniques, and distribution techniques. Figure 3 illustrates the Planning Phase of supplemental application packaging.

Figure 3. Planning for supplemental application packaging
See full-sized image

On This Page

	Roles and Responsibilities
	Integrating with the Application Compatibility and User State Migration Feature Teams
	Establishing the Lab
	Understanding Packaging Techniques
	Inventorying Applications
	Choosing Distribution Techniques
	Milestone: Build Environment Established

Roles and Responsibilities

The six role clusters from the MSF Team Model play a role in the Planning Phase of the initiative. Table 1 lists those roles and defines the focus areas for each. For more information about MSF team role clusters, see the MSF for Agile Software Development page at http://www.microsoft.com/technet/itsolutions/msf/default.mspx.

Table 1. Roles and Responsibilities During the Planning Phase

Top of page

Integrating with the Application Compatibility and User State Migration Feature Teams

The Supplemental Applications feature team must integrate with the Application Compatibility and the User State Migration feature teams. The Application Compatibility feature team must determine which applications will be deployed to client computers and identify any special requirements to enable the applications to run properly on the target platforms. The User State Migration feature team will identify the best way to migrate application data from supplemental applications. Consult with the User State Migration feature team to identify any changes that may be necessary during the deployment of supplemental applications to ensure user data can be retained after the migration is complete.

Top of page

Establishing the Lab

During the Planning stage, you establish the lab environment in which you will conduct all the development work. The Supplemental Applications feature team does not necessarily need a separate lab. Typically, the team can use the lab infrastructure established by the Computer Imaging System feature team, the Application Compatibility feature team, and the User State Migration (USMT) feature team. However, the Supplemental Applications feature team needs to ensure that it has the application packaging software.

For more information about establishing the lab environment, refer to commandment number 1, “Prepare your Packaging Environment,” in Macrovision’s “The 20 Commandments of Software Packaging”
(included with BDD).

Top of page

Understanding Packaging Techniques

Many organizations want to customize application installations to help them meet their unique business requirements. Providing a single way to install all applications and guarantee the installation process greatly reduces the amount of time and effort spent troubleshooting application issues. A simple customization might involve configuring the installation process to proceed without user input. This type of installation is commonly known as quiet, silent, or unattended mode. A more complex situation might involve fully customizing the content of an installation by adding, removing, or changing files and other resources that are to be installed.

In the past, application manufacturers delivered a unique Setup program for each application. In some cases, the Setup program that was supplied with the application allowed a limited amount of customization (for example, by editing a Setup.inf file). However, information technology (IT) personnel frequently had to manually customize and repackage applications that did not allow customization.

The command-line interface to control the installation of each application also varied. This required administrators to spend time learning different managerial facilities for each program. For example, the command-line option to uninstall an application could have been /u, /r, /x, -u, -r, -x, or even something totally different. Additionally, needing to install an application for a single user or for all users on a computer sometimes required radically different procedures.

While modern applications are much more consistent in the way they provide unattended installations, legacy applications are still burdened with complicated and varying setup procedures. Organizations that want to deploy such applications in a consistent and reliable way must use application packaging. This guide covers three major categories of application packaging.

Note   Within the Planning Phase, you will choose an application packaging technique. You will not implement the application packaging until the Developing Phase.

Within each of the three major categories, there can be several different solutions. The three categories are as follows:

The following sections discuss each technology in more detail. For instructions about how to use each of these technologies, see “Developing” later in this guide. References to detailed instructions and documentation, when available, about the various technologies and methods are listed.

Evaluating an Application

You can use the decision tree in Figure 4 to help decide which automation approach to use.

Figure 4. Decision tree for application packaging technology selection
See full-sized image

Consider the following factors when answering the questions in Figure 4:

Table 2 shows the similarities and differences among common automated installation tools: Windows Installer, setup scripts (provided from the application vendor), AdminStudio, Wise Package Studio, and Windows Script. You can use this table to help determine which tool best fits your environment and needs.

Table 2. Automated Installation Tool Features

For more information about evaluating applications for repackaging, refer to commandment number 5, “Know When to package,” and commandment number 6, “Repackage or Customize all of your Software Installations,” in Macrovision’s “The 20 Commandments of Software Packaging”
(included with BDD).

Windows Installer

Windows Installer, also known as Microsoft Installer or MSI, is a technology and file format for installing applications on Windows computers. Most new applications, including almost all new Microsoft applications, include Windows Installer files. The inclusion of a Windows Installer package (.msi) file with an application greatly simplifies deployment, because you will probably not need to repackage the application.

Because Windows Installer is so flexible and easily deployed to an enterprise, you might want to deploy applications in a Windows Installer package even if the software developer has not included an .msi file. You can usually repackage an application into an MSI file by using a repackaging tool, such as AdminStudio or Wise Package Studio (each discussed in this paper). Sometimes, repackaging an application is very easy. Other times, it is extremely challenging and time-consuming. Occasionally, it is impossible or impractical to repackage an application.

If your IT department develops applications internally, you should work with the development team to have them package their applications in Windows Installer files to enable simplified deployment. This is known as authoring. Authoring is often done directly within the development environment with tools such as Microsoft Visual Studio®. Authoring can also be performed with third-party tools such as InstallShield. For more information about Visual Studio, visit the Microsoft Visual Studio Developer Center page at http://msdn.microsoft.com/vstudio/. For more information about InstallShield, visit the InstallShield home page at http://www.installshield.com/products/installshield/.

Windows Installer packages provide the following to enable flexible application deployment:

A Standard Command-Line Interface

By providing a standard installation engine and packaging format for applications, the Windows Installer technology enables all applications using it to share the same Windows Installer properties and command-line options. For example, for every application installed by Windows Installer, the command-line option to perform an installation without displaying a user interface (UI) is /qn. The command-line option to create verbose log files is /lv*.

A Standard Format and Method

Windows Installer provides a standard package format for applications and a standard method for customizing applications. You can tailor an application to a particular group of users by taking the application's Windows Installer package and customizing it by creating and using a transform that installs a selected set of features for that group of users. For example, for a group of users in the Marketing department, you might create a Microsoft Visio® transform that installs a special set of stencils. For users in the Engineering department, you might create a transform that installs a set of stencils different from those installed for the Marketing department.

In most deployment situations, you need to maintain only a single Windows Installer package for each application and a library of transforms that you can apply to each package. For more information about the standard Windows Installer package file types, .msi and .mst files, see "MSDN Windows Installer overview" in the “References” section later in this guide.

At its basic level, a transform file contains a set of differences between the base package (provided by the application manufacturer) and the customized package.

You can also use a transform to answer all installation questions for the user. This can eliminate the need for user intervention during the installation of an application while replacing the manufacturer's defaults with defaults appropriate for your organization. This is particularly useful in customizing and performing unattended installations. The following are the most common application customizations that you can create by using transforms:

Installation Privileges

Users who do not have full administrative privileges are called limited users, low-rights users, or restricted users. To create limited users, exclude the users from the Administrators and Power Users local security groups on their computers. This reduces security risks by blocking many types of malware that might infect the computer. It can also increase system stability and uptime by preventing the user from making configuration changes to his or her computer. However, these benefits have a cost. Limited users will not have sufficient privileges to run some applications properly. As a result, enabling the applications to run requires the application packaging team to spend extensive time testing applications and adjusting permissions and configuration settings. For more information about limited users, refer to the Solution Accelerator for BDD Security Feature Team Guide.

It is possible for limited users to be able to run many applications but still not have sufficient privileges to install the application. For example, if the installation procedure makes changes to the All Users profile, setup will fail if run by a limited user. To work around this limitation, the Windows Installer service enables you to install packages while a limited user is logged on. Currently, the only way to take advantage of these elevated installation privileges is to use Group Policy–based software deployment in a Microsoft Active Directory® environment.

Windows Installer enables you to install packages in two ways:

Currently, only the Group Policy–based software deployment technology, implemented in the Active Directory components of Microsoft Windows Server™ 2003 and Microsoft Windows 2000 Server, takes advantage of the functionality of providing elevated privileges on a per-user and per-computer basis. Administrators can use Group Policy with Windows-based security to prevent users from installing applications not required for their jobs. This can help you reduce management and licensing costs substantially.

System Restore

Users can use the System Restore feature of Windows XP Professional to reverse harmful changes to their computer caused by installing or uninstalling applications. This feature enables the user to return the computer to an earlier state known as the restore point. Windows Installer automatically creates a restore point each time an application is installed or removed. Restore points identify the name of the application and the stage of the installing (or uninstalling) of that application. The System Restore Wizard helps a user return a computer to the state just before installing or uninstalling the application.

Note   System Restore can slightly degrade system performance, particularly during application installation. In organizations with many small applications, especially during the supplemental application deployment, administrators may decide to disable checkpointing from within the installer to improve performance. You can prevent Windows Installer from creating restore points by setting the Disable Creation of System Restore Checkpoints policy. For more information about this policy, see the “References” section later in this guide. After installation is finished, re-enable System Restore. You can use Windows Management Instrumentation (WMI) scripts to enable System Restore.

Windows Installer File Extensions

Table 3 lists the filename extensions that are used with Windows Installer.

Table 3. Windows Installer File Extensions

Top of page

Inventorying Applications

As part of the Planning Phase, the Supplemental Applications feature team must identify which applications need to be packaged and deployed. The sections that follow discuss important considerations for inventorying supplemental applications. For information about the inventory process and tools to use for inventorying software, refer to “Generating an Application Inventory” in the Application Compatibility Feature Team Guide.

Prioritizing Applications

After the Supplemental Applications feature team has obtained a copy of the application inventory from the Application Compatibility team, it can review the application inventory.

The Supplemental Applications feature team typically addresses only the applications that will be redeployed during the deployment project and that have been through the application compatibility testing to ensure they can be run on Windows XP. There is little use in packaging an application that will be neither deployed nor run on the target operating system.

Often, a committee is established with representatives from the User Experience team, IT operations, the Application Compatibility feature team, the Supplemental Applications feature team, the User State Migration team, and product management. This committee reviews the application lists and decides which applications will move forward and be redeployed during the deployment process and which applications will be retired. These decisions affect all the teams on the committee, but they have particular significance to the Supplemental Applications feature team, the Application Compatibility team, and the User State Migration team.

Prioritizing this application list helps the team focus on the applications in an orderly process. Often, the applications are prioritized based on a combination of how pervasive an application is in the environment and the application’s complexity. The most pervasive or complex applications are listed first, followed by the less pervasive and simpler applications.

Identifying Application SMEs

After the Supplemental Applications feature team has its prioritized list of applications that are known to work on Windows XP, it can start to address each application in order of priority. This will be a repetitive process, cycling through each of the applications in turn.

The application packaging developers need not be experts in all the applications in the enterprise. It is important for both the Supplemental Applications feature team and the User State Migration feature team that an SME be identified for each application. Though the term “subject matter expert” is used, the SME does not necessarily need to be an expert in the application; however, the SME is the person identified as having the most overall experience with the application. The SME will provide insight into how the organization installs, configures, and uses each application.

Identifying Files and Settings

The investigation and identification of each application starts in the Planning Phase and continues through the Developing Phase of the deployment project.

The application packaging developers and the application SMEs review each application and identify specifically which files, or file types, need to be migrated, which settings or preferences need to be migrated and where they are to be stored, and where the files should be placed during the restore process on the new workstation.

SMEs should provide assistance in the following key issues:

The User State Migration team, the application SME, and the Supplemental Applications feature team should work together very closely because there are expectations and dependencies across these teams and the SME with respect to where data and settings are located.

Top of page

Choosing Distribution Techniques

To distribute supplemental applications without requiring administrators to manually install software on each client computer, you must identify a way to automate the installation. Most applications, especially recently developed applications, have native support for Windows Installer or InstallShield Reponses files.

Alternatively, you can create a Windows Installer package for an application by using a technique called repackaging. Repackaging is a challenging, time-consuming, and error-prone process, however, and should only be used when no more efficient method of installation automation is available. If neither native automation nor repackaging is available, you might be able to automate the installation by using scripting.

The sections that follow discuss how to plan for automating installations or for repackaging a supplemental application.

Automating Installations

Most applications provide native support for automation by using their native setup routine. Recently created applications almost always provide Windows Installer packages. Legacy applications released before Windows Installer became a popular format might instead use InstallShield response files for automation. If an application’s setup procedure supports neither of these automation technologies, you might be able to automate the installation by using scripting to simulate keypresses. The sections that follow discuss these technologies in more detail.

Planning for Automation of Windows Installer Packages

Automation of Windows Installer packages is straightforward and flexible. If you have a software distribution infrastructure, such as Group Policy software distribution, you can configure the packages for deployment by using a simple, point-and-click UI. If you do not have a software distribution infrastructure, you can automate the installation of Windows Installer packages by using command-line parameters and logon scripts. For detailed instructions, refer to the “Developing” section in this paper.

Planning for Automation with InstallShield Response Files

InstallShield is a popular developer tool for authoring a setup process for an application. Though most modern InstallShield-based setup procedures now support Windows Installer packages, earlier versions of InstallShield used a proprietary format. Fortunately, this format is easily automated by using InstallShield response files. For detailed instructions for customizing InstallShield response files, refer to the “Developing” section.

Planning for Automation Using Scripting

Some applications cannot be automated with command-line parameters. These applications might provide a wizard-based setup routine but require the user to click buttons or press keys on the keyboard to progress with the installation. If a user can complete the installation by using only the keyboard, then you can probably automate the installation by creating a script (a series of text commands) that simulates keypresses.

To understand how to automate a procedure by simulating keypresses, you must first understand that most applications provide keyboard shortcuts, even if most people use the mouse. For example, in most Windows applications, you can press the Alt key to open a menu. After you press the Alt key, one letter on every menu item is highlighted. You can then press that key to select that menu item.

For example, in Microsoft Word, you can save the current file by pressing three keys: Alt, F, and S. The Alt key selects the menu and causes keyboard shortcuts on the menu to be underlined. The F key opens the File menu. The S key selects the Save command. Similarly, you can perform a Save As in Word by pressing Alt, F, and A.

Dialog boxes often have underlined letters, which indicates that you can hold the Alt key and press that letter to activate a link, list, or button. For example, Figure 5 shows a portion of a dialog box that is part of an installation wizard. The x in Exit Setup is underlined, so you could press that button without using the mouse by pressing Alt+X. Similarly, the H in Help is underlined, so you could press Alt+H to open help.

Figure 5. Keyboard shortcuts in installation wizards
See full-sized image

In Figure 5, OK does not have an underlined letter. Typically, an OK or Next button is considered the default button, and you can activate it by pressing Enter. Alternatively, you can select the button by pressing the Tab key repeatedly. A dotted box shows which button is currently highlighted. Then, you can press Space to active that button.

Again considering Figure 5, there are two ways to activate the OK button: pressing Space (because it is selected) or pressing Enter. There are also two ways to activate the Exit Setup button: pressing Tab, then pressing Space, or pressing Alt+X. Either accomplishes the same goal. Depending on the application, you may have to rely on different techniques.

To automate an application installation, first install the application by using only the keyboard. Write down every key you press. Note any significant delays, such as the time taken to copy files or perform the actual installation. Then, create a script that simulates those keypresses and delays. When you run your script on client computers, the keypresses will install the application. The “Developing” section of this paper provides explicit instructions for creating scripts, as well as sample scripts.

Repackaging Overview

If you have an application that is not designed for Windows Installer and does not support another native installation automation technique, you can repackage it into the Windows Installer package format so that you can use the features of Windows Installer to distribute the application. A repackaged application combines the entire feature set of the application into a single feature. In other words, after an application is repackaged, you cannot pick and choose which components you want to install. Instead, you would need to create separate packages for each combination of application components.

After an application is repackaged, you can install it with Windows Installer. However, repackaged applications lack the flexibility to efficiently customize the application installation, which is a feature of applications natively designed to be deployed with Windows Installer.

Note   Before repackaging any applications in your organization, it is important to compare the benefits with the costs involved. Repackaging is an advanced operation. There are tools that can help developers create the final Windows Installer package, but the procedure is resource-intensive and can be costly.

Warning   Do not repackage Microsoft Office 2003 Editions. The Office 2003 Editions package file includes logic that customizes the installation per each target computer. Repackaging the Office 2003 Editions package file loses this logic, potentially preventing the package from installing correctly in some configurations. For more information about deploying Office 2003 Editions with Solution Accelerator for BDD, see the Solution Accelerator for BDD Core Applications Feature Team Guide.

The Repackaging Process

Repackaging is not a function or feature of Windows Installer. However, third-party vendors provide tools to enable you to repackage applications in a variety of formats.

Organizations have repackaged applications for years largely for the purpose of customization. Transforms, however, eliminate the need to repackage Windows Installer–based applications for customization. In fact, repackaging an application that already uses Windows Installer for installation and maintenance would be very difficult and is not supported.

Some organizations prefer to repackage existing applications to gain the benefits of Windows Installer and the Group Policy–based software deployment technology of Windows Server 2003 and Windows 2000 Server. Repackaging also requires a thorough knowledge of the application's installation. The cost of repackaging in labor, time, and reliability is often underestimated.

Repackaging a Windows Installer package involves taking a snapshot of a clean computer (including the registry settings, files, and system settings), installing the software, taking a post-installation snapshot of the computer, and cleaning the package, as shown in Figure 6. The repackaging software detects the difference between the two snapshots and creates the necessary installation instructions to reproduce the installation. Any changes to the registry settings, files, or system settings that occur during the capture process are included in the installation. Typically, from 30 to 40 processes run on a Windows XP Professional computer at any given time. Thus, any one of those processes can modify a system during the installation, and the modification appears in the repackaged application.

Figure 6. The repackaging process

For more information about the repackaging process, refer to commandment number 2, “Use Proper Workflows,” in Macrovision’s “The 20 Commandments of Software Packaging”, and review Macrovision’s “MSI Repackaging and Customization Best Practices Guide” (both included with BDD).

Potential Repackaging Problems

You can improve the reliability of repackaged applications by running them on computers that have identical hardware and software. Some common causes of failed installation or poor functionality of repackaged applications include the following:

The following information can prepare you to deal with the most common challenges of repackaging applications:

Repackaging Tools

You will need to use tools not included with Windows Installer to create Windows Installer packages. While many such tools are available, this paper addresses the following:

The sections that follow discuss these tools in more detail.

AdminStudio

AdminStudio is available in two main varieties:

This paper contains only information about AdminStudio Professional Edition. For information about AdminStudio SMS Edition, please refer to the Supplemental Applications Feature Team Guide  in the Standard Edition of the Solution Accelerator BDD.

AdminStudio Professional Edition includes the full-featured industry leading InstallShield Repackager, which prepares legacy Setup.exe packages for deployment by converting them to Windows Installer .msi packages. The InstallShield Tuner is included to assist in customizing MSI packages by adding files, changing registry settings, adding license keys, removing registration wizards, and making other modifications that will then be compiled in a transform (MST). Finally, a Distribution Wizard and secure SMS Web console are included to assist in handing off the packages for distribution through SMS 2003. Table 4 describes these features in more detail.

Table 4. AdminStudio Professional Edition Key Features

Note   On Windows Server 2003, add the Application Server role and enable ASP.NET before installing AdminStudio to take advantage of important Web-based features.

A trial version is available for download from http://www.installshield.com/products/adminstudio/eval.asp.

Wise Package Studio

Providing similar functionality to AdminStudio, Wise Package Studio repackages applications and updates as Windows Installer files. There are three versions of Wise Package Studio:

For more information about the Wise Package Studio products, visit the Wise Package Studio product overview page at http://www.wise.com/wps.asp?bhcp=1.

Top of page

Milestone: Build Environment Established

Milestones are synchronization points for the overall solution. For more information, see the Solution Accelerator for BDD Plan, Build, and Deploy Guide. This milestone measures the team’s progress toward building a lab environment to support proper development and test and producing the deliverables summarized in Table 5.

Table 5. Build Environment Established Milestone Deliverables

Top of page

4 of 7