Planning

Figure 3 provides a detailed breakdown of the activities accomplished during the Planning Phase. These activities are divided into two categories: establishing the lab and identifying the deployment issues that the feature team must address over the course of the project.

Figure 3. Activities during the Planning Phase

Figure 3. Activities during the Planning Phase

On This Page

Roles and Responsibilities Roles and Responsibilities
Integrating with the Application Compatibility and User State Migration Feature Teams Integrating with the Application Compatibility and User State Migration Feature Teams
Establishing the Lab Establishing the Lab
Identifying Core and Supplemental Applications Identifying Core and Supplemental Applications
Understanding Packaging Techniques Understanding Packaging Techniques
Inventorying Applications Inventorying Applications
Prioritizing Applications Prioritizing Applications
Identifying Application SMEs Identifying Application SMEs
Identifying Files and Settings Identifying Files and Settings
Choosing Distribution Techniques Choosing Distribution Techniques
Milestone: Migration Plan Accepted Milestone: Migration Plan Accepted

Roles and Responsibilities

All six role clusters from the MSF Team Model play a role in the Planning Phase. The Plan, Build, and Deploy Guide lists those roles and defines the focus areas for each role cluster (see Table 1).

Table 1. Roles and Responsibilities During the Planning Phase

Role

Focus

Product Management

  • Input into conceptual design

  • Business requirements analysis

  • Communications plan

Program Management

  • Conceptual and logical design

  • Functional specification

  • Project plan and project schedule

  • Budget

Development

  • Establishment of lab

  • Key application issues identification

User Experience

  • Usage scenarios or cases

  • User requirements

  • Localization and accessibility requirements

  • User documentation

  • Training plans

  • Schedules

Test

  • Testing requirements definition

  • Test plan and schedule

Release Management

  • Design evaluation

  • Operations requirements

  • Pilot and deployment plan or schedule

  • Network discovery

  • Application and hardware inventory

  • Interfacing with information technology (IT) Operations and the Security feature team

For more information about MSF Team Model role clusters, see the MSF home page at https://www.microsoft.com/technet/itsolutions/msf.

Integrating with the Application Compatibility and User State Migration Feature Teams

The Application Management 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 that user data can be retained after the migration is complete.

Establishing the Lab

During the Planning Phase, the lab environment, in which all the development work is conducted, is established. The Application Management feature team does not necessarily require a separate lab. Typically, its members can use the lab infrastructure established by the Computer Imaging System feature team and the Application Compatibility feature team. The Application Management feature team, however, must ensure that it has the required licensed software media as defined previously in the “Prerequisites” section of this guide.

Identifying Core and Supplemental Applications

A core application is any application that is common to all (or most) of the organization, that would not readily lend itself to distribution, or that must be available as soon as the image becomes active. Core applications are those that need to be installed on all or most of the desktop computers in the enterprise. These applications, such as Microsoft Office, antivirus software, compression programs, mail clients, and so on, are common to all desktops. Document the command-line options required to install each application without user interaction.

Many organizations consider the following applications core applications:

  • Microsoft Office

  • Adobe Acrobat and Reader

  • Macromedia Flash Player

  • Macromedia Shockwave

  • Various antivirus packages

  • Various Microsoft Office Outlook® plug-ins

  • Various Windows Internet Explorer® plug-ins

  • Corporate screen savers

  • Terminal emulation applications (such as TN3270)

  • Database drivers and connectivity software

  • Network and client management software (such as OpenManage clients)

Some core applications can be installed in silent mode, without user interaction. For example, the 2007 Office system programs and other Microsoft products can be installed in this way. For more information on how to deploy the 2007 Office system, see the Office Deployment Guide available in BDD 2007.

For core applications that do not provide a silent installation, decide how to automate the installation. The Application Management feature team can repackage many applications as Windows Installer setup databases, for example, or the team can create a script to automate the installation. For more information about repackaging legacy applications, see the next section, “Developing.”

Other applications may be required for one or more groups of computers in the environment. Applications not required by the majority of computers are identified as supplemental applications. For example, the engineering department may use a CAD application. Supplemental applications are installed at a post-imaging phase of deployment.

Many organizations consider the following applications supplemental:

  • Microsoft Visual Studio® 2005

  • Microsoft SQL Server™ 2005 Client Tools

  • Microsoft Data Analyzer 3.5

  • Various CAD applications

  • Various Enterprise Resource Planning (ERP) systems

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, 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. In addition, installing an application for a single user sometimes required a radically different procedure than installing the application for all users on a computer.

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   During the Planning Phase, the Application Management feature team chooses an application-packaging technique. The team will not implement the application packaging until the Developing Phase.

Within each of the three major categories are several different solutions. The three categories are:

  • An installation executable that natively supports unattended installation:

    • Windows Installer

    • InstallShield Response Files

    • Other setup scripts

  • Repackaging technologies:

    • SMS Installer

    • AdminStudio

  • Screen scraping (also known as keyboard stuffing):

    • Microsoft Windows Script (SendKeys)

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

Use the decision tree shown in Figure 4 to determine which automation approach to use.

Figure 4. Decision tree for application-packaging technology selection

Figure 4. Decision tree for application-packaging technology selection

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

  • Does the application have its own automation capabilities? First, look for an .msi file in the setup media. This .msi file is a Windows Installer file that team members can use to automate installation. If there is no .msi file, there is still a distinct possibility that the setup procedure supports a different automation technology. If the Application Management feature team is automating a popular, common application (as opposed to an internally developed application), the team can probably find information on the Internet from administrators who have previously automated the application installation. The best place to start is the AppDeploy.com Package KnowledgeBase page at https://www.appdeploy.com/packages, which contains a knowledge base of applications that have been packaged and deployed by other people, a list of ways to automate the installation, and details about potential problems.

  • Can the application be installed using a repackaging technology? If the application lacks its own automation capabilities, the Application Management feature team may be able to install it by repackaging the application. The best way to determine whether an application can be repackaged is to attempt to repackage it, and then test deployment in a lab environment. This guide provides detailed instructions for repackaging applications.

  • Does the application support screen scraping? The Application Management feature team can automate most applications with interactive installers by using a tool that simulates keystrokes, such as Windows Script. Occasionally, the installation procedure may require the user to use the mouse or otherwise perform some complex task that cannot be easily automated. In these circumstances, automating the installation process may not be feasible.

Note   ScriptIt was previously used for simulating keystrokes; however, the tool is now considered outdated. Windows Script provides a more flexible and powerful platform for screen scraping.

Table 2 shows the similarities and differences among common automated installation tools: Windows Installer, setup scripts (provided by the application vendor), AdminStudio, Wise Package Studio, SMS Installer, 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

Attribute

Windows Installer

Setup scripts

AdminStudioSMS Edition/ Professional

Wise Package Studio

SMS Installer

Windows Script

Requires no user intervention

Yes

Yes

Yes/Yes

Yes

Yes

Yes

Available at no extra charge

Yes

Yes

Yes/No

No

No, requires SMS

Yes

Can install more than one program at a time, including file and registry settings

Yes

No

Yes/Yes

Yes

Yes

No

Has an intelligent, wizard-driven interface rather than requiring text file editing

Yes

No

Yes/Yes

Yes

Yes

No

Has a graphical user interface (GUI) with many features

Yes

No

Yes/Yes

Yes

Yes

No

Shows whether the client has completed or failed an installation

Yes, if configured

Not necessarily

Yes/Yes

Yes

Yes

Yes, if scripted

Can create an installation package for multiple computers and can designate the conditions when it will install

Yes

Not necessarily

Yes/Yes

Yes

Yes

Yes, if scripted

For more information about evaluating applications for repackaging, refer to Commandment 5, “Know When to Package,” and Commandment 6, “Repackage or Customize All Your Software Installations,” in Macrovision’s “The 20 Commandments of Software Packaging” (included with BDD 2007).

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, the Application Management feature team might want to deploy applications in a Windows Installer package even if the software developer has not included an .msi file. Team members can usually repackage an application into an .msi file by using a repackaging tool, such as AdminStudio, Wise Package Studio, or SMS Installer (each discussed in this guide). Sometimes, repackaging an application is easy. Other times, it is extremely challenging and time-consuming. Occasionally, it is impossible or impractical to repackage an application.

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

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

  • Command-line options. Use command-line options to specify transforms (described later in this document), variables, switches, and file and path names as well as control the action of the installation at run time.

  • Properties (variables) on the command line. Properties are variables that Windows Installer uses during an installation. A subset of these, called public properties, can be set on the command line.

  • Transforms. A transform is a collection of changes the Application Management feature team can apply to a base Windows Installer package (.msi) file. The team can customize applications by using Windows Installer transform (.mst) files. The team configures transforms to modify a Windows Installer package to dynamically affect installation behavior according to requirements. Associate transforms with a Windows Installer package at deployment time. Transforms for Windows Installer package files are similar to answer files that are used to automate the installation of an operating system such as Windows XP.

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 that Windows Installer installs, 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. The Application Management feature team can tailor an application to a particular group of users by customizing the application’s Windows Installer package 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, the team might create a Microsoft Office Visio® transform that installs a special set of stencils. For users in the engineering department, the team might create a transform that installs a different set of stencils.

In most deployment situations, the Application Management feature team must maintain only one Windows Installer package for each application and a library of transforms that the team can apply to each package. For more information about the standard Windows Installer package file types, .msi and .mst, see MSDN Windows Installer Overview in the “Education and 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. The Application Management feature team can also use a transform to answer all installation questions for the user, which can eliminate the need for user intervention during the installation of an application while replacing the manufacturer's defaults with defaults appropriate for the organization. This is particularly useful in customizing and performing unattended installations. The following are the most common application customizations that the Application Management feature team can create by using transforms:

  • Specify the features to be installed.

  • Define the level of user interaction during the installation. This works in combination with the command-line options set. For example, the Application Management feature team might want to allow the setup procedure to prompt users for their names.

  • Specify the answers to be provided in the Setup UI during the installation.

  • Specify a location to install the files.

  • Specify the placement of shortcuts.

  • Add files to the installation.

  • Specify the registry settings to be added or changed during the installation.

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. Doing so reduces security risks by blocking many types of malicious software (also called 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 Security Feature Team Guide.

Sometimes, limited users might be able to run many applications but have insufficient privileges to install an 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 package installation 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® directory service environment.

Windows Installer enables package installation in either of two ways:

  • Per computer. The Application Management feature team can use software-distribution technologies to install an application on a computer by using administrator-level privileges in the operating system’s All Users profile. The team might use the following sample command-line argument to install an application from an administrative share in the All Users profile (per computer) that does not include a UI (this command must be run by using an account with elevated privileges):

    msiexec /i \\server\share\application\setup.msi /qn ALLUSERS=1
  • Per user. Windows Installer provides software-distribution technologies to assign or publish applications to users. Windows Installer also provides the functionality for installing an application by using administrator-level privileges while operating within the user’s context, regardless of the user’s privileges.

    Note   Install packagers per computer whenever possible. Per-user installations might require each user to install updates, which complicates the update process.

Currently, only the Group Policy–based software deployment technology, implemented in the Active Directory components of Microsoft Windows Server® 2003 and 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 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 computers caused by installing or uninstalling applications. With this feature, users can return their computers to an earlier state known as a 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 program installation (or uninstallation). The System Restore Wizard helps users return computers to the state they were in 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 the creation of checkpoints from within the installer to improve performance. The Application Management feature team 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 “Education and References” section later in this guide. After installation is complete, re-enable System Restore. (The Application Management feature team can use Windows Management Instrumentation [WMI] scripts to do so.)

Windows Installer File Extensions

Table 3 lists the file name extensions used with Windows Installer.

Table 3. Windows Installer File Extensions

Extension

Description

.msi

Windows Installer package

.msm

Windows Installer merge module

.msp

Windows Installer patch

.mst

Windows Installer transform

.idt

Exported Windows Installer database table

.cub

Validation module

.pcp

Windows Installer patch creation file

SMS

SMS Installer was originally developed and released with SMS version 1.2 to address common problems with traditional packaging and installation systems before the release of Windows Installer. The Application Management feature team can use SMS Installer to create new procedural installation scripts, to repackage existing application installations, or both. The team can compile SMS Installer scripts and their related package components into self-extracting executable files for deployment through SMS or other methods.

SMS Installer has since proven to be popular among system administrators for the simplicity and flexibility with which it packages software. As a result, many customers have established libraries of hundreds, even thousands, of SMS Installer packages that are available to administrators for enterprise distribution.

The Installer Step-up Utility for SMS is a command-line tool that migrates (converts) Setup packages from the SMS Installer format to the Windows Installer format. The result is a Windows Installer Setup package with an .msi file extension. Application Management feature team members can run this new Setup package on any computer that has the Windows Installer service.

Feature Summary

SMS Installer is a software-packaging tool for system administrators. It is designed to make it easy for administrators to use SMS to create software packages for enterprise-wide distribution. SMS Installer provides the following three mechanisms for creating software packages:

  • Repackage Installation Wizard. The Repackage Installation Wizard is the simplest method for creating software packages. It operates by taking a snapshot of a reference computer’s file system and registry. After the first snapshot is taken, Application Management feature team members can install a product and modify the configuration as desired. Then, the Repackage Installation Wizard takes another snapshot of the computer and compiles the difference into a script, which is compiled into a Setup executable package. Packages created with the Repackage Installation Wizard can be installed on any target computer that is functionally equivalent to the reference computer.

  • Installation Expert. The Installation Expert provides a GUI for building or editing an installation script. Application Management feature team members can drag files, registry keys, and shortcuts into a package definition and select other options for the package from a simple UI. When the team member finishes describing the package content and characteristics, he or she compiles the script into a Setup executable package. Packages created with the Installation Expert are similar to those created with the Repackage Installation Wizard, because they both represent a described state to be applied to target computers.

  • Script Editor. Using the Script Editor, Application Management feature team members can create an ad hoc Setup program by using the SMS Installer scripting language. An ad hoc script can contain run time flow control that developers would be familiar with, including conditional (if) statements and while loops. It can also call methods in dynamic-link libraries (DLLs), providing a lot of customizability. Such scripts can be quite complex and can provide a very high level of flexibility.

Scripts that the Script Editor generates are also compiled into Setup executable packages. However, the resulting Setup package is not state oriented; it is sequential with a great degree of run time flow control possible. This difference is significant when considering migration to Windows Installer.

The Application Management feature team can use a combination of SMS Installer mechanisms to create a Setup package. For example, the team can start the installation script by using the Repackage Installation Wizard, and then use the Script Editor to customize it.

Regardless of the mechanism used, the result is compiled into a Setup executable package—the actual software package. This package includes the Setup logic and all the files, registry keys, and other data as well as the engine for performing the Setup operation on a computer.

Key Supported Features

SMS Installer mechanisms support the following key features:

  • Pre-/post-installation processing. An example of post processing is having the script send a success Management Information Format (MIF) file (generated using the MIF Form Generator) to the NOIDMIF folder after a successful installation to enable SMS Inventory to track scripted installations (using custom entries such as a scripted application build number). Application Management feature team members can generate reports through SMS Inventory to see who has which builds of installed scripted applications. Another example is enabling and disabling the device-driver signing prompt in the registry for unattended installations. These are examples of what team members can add to the scripts.

  • Check for the existence of a running application in memory. Checking for the existence of an application already running in memory is useful when performing upgrades. For example, Application Management feature team members might need to check for and disable anti-spyware software that would interfere with the installation or close an application that uses a DLL a team member must update. Using Microsoft Win32® application programming interface (API) calls, the script could check for an application running in memory and perform the following steps if one is found:

    • Prompt the user that it is running and attempt to close it when the user clicks OK.

    • Bring the application to the foreground if it contains unsaved data, which gives users the opportunity to save their work and close the application.

    • Prevent the script from continuing, even if the UNATTENDED variable is YES, until the application is closed (that is, the process is no longer running).

    • SMS Installer has an option to check for a module in memory, but it works only for 16-bit applications.

  • Stop and start an antivirus service. The script should have the capability to stop an antivirus service from running and then start it again after the installation is finished, regardless of whether the installation was successful. Many applications cannot be installed properly if an antivirus service is running.

Inventorying Applications

As part of the Planning Phase, the Application Management feature team must identify which applications must 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 Application Management feature team has obtained a copy of the application inventory from the Application Compatibility feature team, it can review the application inventory. The Application Management 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 run on Windows Vista or 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 Role Cluster, IT Operations, the Application Compatibility feature team, the Application Management feature team, the User State Migration feature team, and the Product Management Role Cluster. 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 Application Management feature team, the Application Compatibility feature team, and the User State Migration feature 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 Application Management feature team has its prioritized list of applications that are known to work on Windows Vista or Windows XP Professional, it can start to address each application in order of priority. This process is repetitive, cycling through each application in turn.

The application packaging developers need not be experts in all the applications in the enterprise. It is important for both the Application Management feature team and the User State Migration feature team that an SME be identified for each application. Despite the name, 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 computer.

SMEs should provide assistance on the following key issues:

  • Locating the software media (Often, the SME is the best source of information about where the source media, such as CD-ROMs or floppy disks, can be found.)

  • Describing the appropriate configuration, behavior, and usage of the application

  • Understanding the external interface connectivity requirements, if any, of the application, which may include a back-end database, mainframe, Web site, or other application server

  • Identifying any constraints associated with an application

Knowledge of the above key issues is crucial when modeling the pilot environment to closely match the production environment.

Note   If possible, store all user data under the user’s profile, either in \%userprofile%\My Documents or \%userprofile%\Application Data. The application SMEs should provide information about the feasibility of any data-file relocation requirements.

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

Choosing Distribution Techniques

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

Alternatively, the team 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, team members might be able to use scripting to automate the installation.

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, Application Management feature team members might be able to automate the installation by using scripting to simulate keystrokes. 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 the organization has a software distribution infrastructure, such as Group Policy software distribution or SMS, Application Management feature team members can configure the packages for deployment by using a simple point-and-click UI. If no software-distribution infrastructure exists, team members can automate the installation of Windows Installer packages by using command-line parameters and logon scripts. For detailed instructions, refer to the “Developing” section of this guide.

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, the Application Management feature team can probably automate the installation by creating a script (a series of text commands) that simulates keystrokes.

To understand how to automate a procedure by simulating keystrokes, Application Management feature team members must first understand that most applications provide keyboard shortcuts, even if most people use the mouse. For example, in most Windows applications, users can press the ALT key to open a menu. After pressing the ALT key, one letter on every menu item is highlighted. A user can then press that key to select that menu item.

For example, in Microsoft Office Word, a user 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, users can perform a Save As operation in Word by pressing ALT, F, and A.

Dialog boxes often have underlined letters, which indicates that the user 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 the user could press that button without using the mouse by pressing ALT+X. Similarly, the H in Help is underlined, so the user could press ALT+H to open Help.

Figure 5. Keyboard shortcuts in installation wizards

Figure 5. Keyboard shortcuts in installation wizards

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

Just as there are two ways in this example to activate the OK button (pressing the SPACEBAR because it is selected or pressing ENTER), there are two ways to activate the Exit Setup button: by pressing the TAB key, then pressing the SPACEBAR, or by pressing ALT+X. Either approach accomplishes the same goal. Depending on the application, the user 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 pressed. Note any significant delays, such as the time taken to copy files or perform the actual installation. Then, create a script that simulates those keystrokes and delays. When the script runs on client computers, the keystrokes install the application. The “Developing” section of this guide provides explicit instructions for creating scripts as well as sample scripts.

Repackaging Overview

If the organization has an application that is not designed for Windows Installer and does not support another native installation automation technique, the Application Management feature team can repackage it into the Windows Installer package format so that team members 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, team members cannot choose which components to install. Instead, team members must create separate packages for each combination of application components.

After repackaging an application, the Application Management feature team can use Windows Installer to install it. However, repackaged applications lack the flexibility to efficiently customize the application installation, which is a feature of applications that are designed to be deployed with Windows Installer.

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

Warning   Do not repackage 2007 Office system suites. The Microsoft Office package file includes logic that customizes the installation per each target computer. Repackaging the package file loses this logic, potentially preventing the package from installing correctly in some configurations. For more information about deploying 2007 Office system suites with BDD, see the Office Deployment Guide.

The Repackaging Process

Repackaging is not a function or feature of Windows Installer. However, non-Microsoft vendors provide tools to enable repackaging 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 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, 30 to 40 processes run on a Windows XP Professional or Windows Vista 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

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 2007).

Potential Repackaging Problems

The Application Management feature team 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:

  • Systems that run the same operating systems but which differ in the optional operating-system components that are installed. For example, if the Application Management feature team repackages an application by using a snapshot on a computer running Microsoft Internet Information Services (IIS), then deploy that package to a computer without IIS, the application will not work if it requires IIS or any components of IIS.

  • Differences in service pack versions. Application installation routines may install updated system libraries only if they are not currently installed on a computer. Therefore, deploying an application on a computer with a different service pack or update version can result in system files not being properly updated (or worse, system files that are downgraded).

  • Differences in operating systems, such as Windows XP Professional versus Windows Vista.

  • Differences in versions of shared components, such as Internet Explorer.

  • Differences in versions of other installed applications, such as Microsoft Office. Many applications share libraries. If these libraries already exist on the computer used to create a package but do not exist on a destination computer, the application will not run correctly.

Note   Repackaging applications into the Windows Installer format has limitations and might not be supported by the application manufacturer. Check with each application manufacturer. Microsoft supports authoring and customizing applications that natively use Windows Installer for installation and maintenance. However, it does not support applications repackaged as Windows Installer files. The repackaging software manufacturer provides this support.

The following information can prepare Application Management feature team members to deal with the most common challenges of repackaging applications:

  • Repackaging includes irrelevant or unrelated information. Repackaging, by design, can include information in the Windows Installer file that is not part of the application. For example, if an Application Management feature team member captures the first snapshot, launches a program by using the Run command, and captures the second snapshot, the Command Prompt window is added to the most recently used (MRU) list for the Run dialog box during installation. Another example is if the computer restarts between the first and second snapshot, the package records service state information, logon time, and so on. While these examples are relatively harmless, others can disrupt the stability and functionality of a system. It is possible for a highly skilled and experienced technician to eliminate extraneous or detrimental information from a capture when repackaging applications for Windows Installer. Even then, it is a labor-intensive and therefore costly operation.

  • Installing features on demand is not possible. Installing individual features on demand is not possible when an application has been repackaged. When Application Management feature team members repackage an application, the resulting Windows Installer package contains only one feature. That is, the Windows Installer installs either all or none of the application.

    To take advantage of install-on-demand functionality, an application must be developed with multiple features so that those features can be installed individually instead of all at once. Whether these features rely on shared components depends on the design of the application, and the developer must understand all the relationships among features and components.

  • Repackaged applications have little resiliency after installation. Typically, repackaging specialists create packages that self-repair by using Windows Installer. This type of resiliency can produce unexpected results and can be unreliable. Repackaging tools neither decipher component dependencies nor specify the keypath for an application. The keypath is the file or registry value that the Windows Installer uses to determine whether a component needs to be repaired. Therefore, repackaged applications are more likely to be corrupted after installation than applications that are distributed using their original packaging.

Repackaging Tools

The Application Management feature team must use tools not included with Windows Installer to create Windows Installer packages. Many such tools are available, but this guide addresses the following three:

  • FLEXnet AdminStudio. Available in multiple versions, including a free download, AdminStudio is a powerful and flexible repackaging tool.

  • Wise Package Studio. Wise offers products for repackaging, testing, and configuring the deployment of applications.

  • SMS Installer. A free snapshot-based repackaging tool for users of SMS.

The sections that follow discuss these tools in more detail.

AdminStudio

AdminStudio is available in two main varieties:

  • AdminStudio SMS Edition. This free download from Microsoft.com integrates with SMS to simplify repackaging. AdminStudio SMS Edition prepares legacy Setup.exe packages for deployment by converting them to Windows Installer .msi packages. To download AdminStudio SMS Edition at no cost, visit the AdminStudio SMS Edition download page at https://www.microsoft.com/smserver/downloads/2003/featurepacks/adminstudio.

  • AdminStudio Professional Edition. This full version of AdminStudio is a complete solution for packaging, customizing, testing, and distributing applications. The full version includes all the features included with AdminStudio SMS Edition and adds many others. To download a trial of AdminStudio Professional Edition, visit the AdminStudio software overview page at https://www.installshield.com/products/adminstudio.

The sections that follow describe these products in more detail.

AdminStudio SMS Edition

FlexNET AdminStudio SMS Edition is the result of collaboration between Macrovision (formerly InstallShield) and the Microsoft SMS team. AdminStudio SMS Edition simplifies Windows Installer software repackaging, customization, and distribution by providing the ability to prepare, publish, and distribute software packages by using Microsoft SMS 2003 without ever touching the SMS server console.

AdminStudio SMS 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 file). Finally, a Distribution Wizard and secure SMS Web console assist in handing off the packages for distribution through SMS 2003. Table 4 describes these features in more detail.

Table 4. AdminStudio SMS Edition Key Features

Key feature

Description

Repackager

A wizard-based tool that makes it easy to convert any setup—even difficult–to–package InstallScript MSI setups—into 100 percent MSI packages. Repackager includes InstallMonitor for snapshot-free repackaging, SmartScan for extracting the maximum information from InstallScript setups during conversion to MSIs, Setup Intent for helping to ensure that MSIs do not miss important files, and the Packaging Process Assistant for pointing users to the correct packaging process.

Legacy Format Conversion

Convert SMS, Novell ZENworks, WinINSTALL, and Wise WSE software packages directly into robust MSIs without wasting time. The automated Converter copies all file and registry data from legacy setups into a new AdminStudio project so that users can bypass packaging and automatically convert the installations directly into MSI packages.

InstallShield Tuner

Quickly create transforms (MSTs), including Response File transforms, to customize software already in the Windows Installer format. Add files, change registry settings, add license keys, remove registration wizards, or make other modifications to the MSI package, then automatically validate any changes made to ensure the MSI package conforms to Microsoft guidelines.

Distribution Wizard

This wizard-based system automatically creates the system-specific files necessary to successfully deploy packages, providing excellent integration with SMS 2003.

SMS 2003 Web Console

Provides Web-based access to key settings and configuration capabilities, including server connection settings, package selection, package configuration, distribution points, and package summary.

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

AdminStudio Professional Edition

AdminStudio Professional Edition includes all the features of AdminStudio SMS Edition, plus many other important benefits, including:

  • The ability to convert InstallScript MSI files into 100 percent Windows Installer packages.

  • The ability to author new software packages and to directly customize existing Windows Installer packages.

  • ConflictSolver, which can identify and resolve application conflicts in the lab environment.

  • QualityMonitor, which can test packages before deployment to ensure they will work—and continue to work—as expected when installed.

  • Risk-free deployment testing, which simulates the deployment of a package without physically installing it on any target machine and reports back any installation problems.

  • OS Snapshot Wizard, which captures operating system state, including files, shortcuts, and registry values.

  • Application Isolation Wizard, which helps reduce conflicts related to using multiple versions of a single application in an enterprise.

  • The ability to prepare packages for distribution with Novell ZENworks, Tivoli, Marimba, LANDesk, ManageSoft, and Altiris.

Although a trial version is available for download from https://www.installshield.com/products/adminstudio/eval.asp, AdminStudio Professional Edition is not free. If software-licensing costs are a concern, begin by using AdminStudio SMS Edition. If the Application Management feature team identifies a need for features included only in AdminStudio Professional Edition, contact Macrovision to upgrade AdminStudio.

Wise Package Studio

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

  • Wise Package Studio Standard Edition. The Wise basic repackaging tool provides enough functionality to meet the needs of most organizations, including tools for package creation, customization, validation, and distribution.

  • Wise Package Studio Professional Edition. Adds many features to Standard Edition, including the following:

    • Virtual Capture. Enables the capture of multiple application installations on a single client computer without cleaning the computer between installations

    • Create .zap files. Enables the creation of .zap files if Application Management feature team members must install applications without using Windows Installer

    • .ini file changes. Records changes to .ini files

    • Wise Script Editor. Provides the ability to edit installation scripts

    • ConflictManager. Detects and resolves application conflicts

    • Group Deployment. Deploy multiple packages in one deployment while controlling the order of package installation

  • Wise Package Studio Quality Assurance. An optional feature set of Professional Edition, this version is intended for staff responsible for testing applications before deployment.

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

SMS Installer

SMS includes the SMS Installer, which is an application-repackaging tool. SMS Installer is available for download from the Installer Step-up Utility download page at https://www.microsoft.com/smserver/downloads/20/tools/installer.mspx. Typically, the Application Management feature team would use the AdminStudio SMS Edition instead of the SMS Installer. AdminStudio is an easier-to-use and more robust tool.

The SMS Installer has the unique capability to extract executable files created with previous versions of SMS Installer without needing a reference computer to build the package. However, it cannot convert executable files created with previous versions of SMS Installer to Windows Installer format.

Milestone: Migration Plan Accepted

Milestones are synchronization points for the overall solution. For more information, see the Plan, Build, and Deploy Guide.

At this milestone, shown in Table 5, the Application Management feature team has created the test lab and written a migration plan.

Table 5. Deliverables for Migration Plan Acceptance Milestone

Deliverable ID

Description

Test Lab

The lab environment is running for testing the core applications.

Migration Plan

The migration plan includes input from the team.

The primary deployment blockers for the core applications have been identified and reviewed, and an estimate of their scope and effect has been defined.

Download

Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007

Update Notifications

Sign up to learn about updates and new releases

Feedback

Send us your comments or suggestions