Figure 7 illustrates the primary tasks that the Application Management feature team must complete during the first part of the Developing Phase. These activities are directed at creating and testing the core application-deployment packages that will be integrated into the overall deployment package as a subsequent set of tasks.

Figure 7. Detailed tasks for creating deployment packages for core applications

Figure 7. Detailed tasks for creating deployment packages for core applications

On This Page

Roles and Responsibilities Roles and Responsibilities
Automating Application Deployment Automating Application Deployment
Addressing Application-Security Requirements Addressing Application-Security Requirements
Repackaging Applications Repackaging Applications
Integrating Core Applications with BDD 2007 Integrating Core Applications with BDD 2007
Milestone: Scope Complete Milestone: Scope Complete

Roles and Responsibilities

All six role clusters from the MSF Team Model play a role in the Developing Phase. Table 6 lists those roles and defines the focus areas for each role cluster. For more information about MSF role clusters, see the MSF site at

Table 6. Roles and Responsibilities During the Developing Phase



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


  • Creation and testing of the deployment packages

User Experience

  • Usage scenarios or cases

  • User requirements

  • Localization and accessibility requirements

  • User documentation

  • Training plans

  • Schedules


  • 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 IT Operations and the Security feature team

Automating Application Deployment

To achieve a fully unattended and automated installation, the applications added to the BDD 2007 project must support unattended installation. Many Setup programs support the /s or /q command-line options for such a thing; others do not.

Note   For information on deploying the 2007 Office system in silent mode, refer to the Office Deployment Guide.

To find out whether a package supports unattended installation, type setup /? in a Command Prompt window, where setup is the file name of the Setup program. If the Setup program does not provide clues, Application Management feature team members must know which vendor’s product was used to create the package. To tell, run the Setup program and look for logos or branding of the installation wizard pages, or look at the file properties.

Although vendors may provide support for automating a silent installation, the level of customization possible varies from vendor to vendor. The inherent support options provided in the following section are a good starting point. Keep in mind that although the support described below may seem insufficient for your needs, the developers may have provided specialized support for the silent installation of their applications. If the vendor provides any such support, it should be documented in the application’s release notes, quick start guide, or support Web site.

Windows Installer Installations

The number of applications packaged as Windows Installer databases is multiplying rapidly. And what often looks like a self-contained, self-extracting Setup program with a file name such as Setup.exe is often a file that decompresses to a Windows Installer database. Extract the database by using a tool such as WinZip (from WinZip Computing at or by running the Setup program and looking in the %TEMP% folder for the Setup files. Windows Installer databases have the .msi file extension.

To install Windows Installer databases unattended by using Msiexec.exe, use the /qb command-line option for a basic UI (progress bar only) or the /qn command-line option for no UI.

Windows Installer InstallShield Installations

Some Windows Installer setup files that Macromedia’s InstallShield creates may require that Application Management feature team members execute them by using a provided Setup.exe file. Attempts to run the .msi file directly result in a message stating that Setup.exe must be used to initiate the installation. When the author of the installation uses InstallShield Script, this requirement is enforced to ensure that the necessary version of the InstallShield Script Engine (ISScript.msi) is installed on the computer before proceeding. If it is not detected, the required version of InstallShield Script Engine is installed automatically before calling the Windows Installer Setup. The Application Management feature team can deal with such a setup in a couple of ways.

The first is to make use of InstallShield’s command-line support that Setup.exe offers. Not only does Setup.exe provide command-line option support, but the team can also pass options to the contained Windows Installer Setup by using the /v argument. Following /v, team members can specify any options to be passed to the Windows Installer Setup within double quotation marks (“”). For example, the command below instructs Setup.exe to run silently and to also pass the /qn option to the Windows Installer Setup:

setup.exe /s /v"/qn"

The next method available is to deploy the InstallShield Script Engine separately as part of the core applications before any setup files that require it. Application Management feature team members can then safely bypass the restrictive functionality of the provided Setup.exe by running the .msi file directly and including the ISSETUPDRIVEN public property. Obtain the embedded Windows Installer Setup by looking in the %TEMP% folder after the welcome message for the installation wizard is displayed. Then, place the .msi file on the lab server and silently execute it directly by using the following command:

msiexec.exe /i setup.msi ISSETUPDRIVEN=1 /qn

Legacy InstallShield Installations

Legacy setup files that InstallShield creates usually have the file name setup.exe. To create an unattended installation for an InstallShield package, create an InstallShield answer file, which has the .iss file extension. This method works with most, but not all, InstallShield packages.

PackagefortheWeb Installations

PackagefortheWeb is an InstallShield-packaged application in a self-contained, self-extracting file. Create a setup.iss file. Using it is almost the same as described in the previous section. The difference is that Application Management feature team members must use the /a command-line option to pass the command-line options to the setup program after the file extracts its contents. For example, a setup file called Prog.exe expands its contents into the temporary folder, and then runs setup.exe when finished. To pass command-line options to setup.exe, use the /a command-line option.

Wise Installations

Most packages created using Wise Installation System or Wise InstallMaster (now Wise Installation System) recognize the /s command-line option for unattended installation. While this generally succeeds as a method of silent installation, no ability to dictate installation options is provided without express support from the application vendor.

Ghost Installer Installations

Ethalone Solutions’ Ghost Installer setup files may provide silent installation when the -s command-line option is used. The success of this method depends on choices the developer makes when creating the installation. Although Ghost Installer automates the installation, no capability to customize the silent installation is provided without explicit efforts by the installation developer.

Addressing Application-Security Requirements

Some applications will not run properly in the security context of a restricted user. Although in rare circumstances this may be because the restricted user does not hold certain rights, it is most commonly the result of applications that attempt to update files and registry entries not permissible to restricted users. This section discusses methods for identifying and adjusting these application security requirements.

Identifying Application Security Requirements

When installed, most applications should restrict the need to update information to the following locations:

  • The user profile application data directory, typically:

    • Windows XP: C:\Documents and Settings\UserName\Application Data\VendorName\Product Name

    • Windows Vista: C:\Users\UserName\AppData\Roaming\VendorName\ProductName

  • The application user registry hive, typically HKEY_CURRENT_USER\Software\VendorName\ProductName

However, if running an application as a restricted user fails or results in unexpected behavior, look at some common places in which the application may be trying to update:

  • The application directory, typically C:\Program Files\VendorName\ProductName

    Look for file extensions such as .dat, .xml, and .ini. These files may contain settings or other information updated by the application, which, if located outside the user profile directory structure, will fail to succeed for restricted users.

  • The application machine registry hive, typically HKEY_LOCAL_MACHINE\Software\VendorName\ProductName

    Note   The default paths for application installation and for the user profile differ between versions of Windows. When writing scripts or programmatic references to these locations, use environment variables. For application data, %APPDATA% points to the application data root folder. For the current default application installation directory, %PROGRAMFILES% points to the application installation root folder.

Two tools—RegMon.exe and FileMon.exe from—are available to help identify what areas of the system are being written to. Use these tools to monitor changes to the registry and file systems, respectively, and they will report any successes or failures. The registry receives a large number of reads and writes to the registry and file system on a regular basis; however, these tools provide filters that help isolate the items that are of concern.

Addressing Application Security Requirements

After security requirements have been identified and approved for implementation, the Application Management feature team can enforce them in several ways:

Repackaging Applications

This section walks through the process of repackaging an application that is not available as a Windows Installer package. If an application includes a Windows Installer (.msi) file, the Application Management feature team need not repackage the application and should not follow these steps. Instead, the team can distribute the Windows Installer file natively.

The repackaging process consists of the following steps:

  1. Preparing the lab

  2. Managing the workflow

  3. Running the discovery

  4. Cleaning up a new package

  5. Handling application prerequisites

  6. Preparing for highly managed environments

  7. Validating the package file

The sections that follow discuss each step and provide a list of repackaging best practices.

Preparing the Lab

The Application Management feature team must have a lab environment to properly repackage applications. Enterprises typically require a robust lab environment that enables engineers to package multiple applications on different computers simultaneously, simulate a variety of client platforms, and rapidly redeploy “clean and quiet” lab computers. This setup includes two to three computers for each client platform in the enterprise and a deployment server using software-distribution technologies such as SMS, Remote Installation Service (RIS), or Deployment Center for rapidly deploying new operating system images to ensure client computers are always clean. To avoid conflicts with the production network, the lab network should be an isolated network segment.

If the Application Management feature team decides to repackage an application, it can avoid common problems by taking the following actions when repackaging an application:

  • Use a clean computer. A clean computer is one that has only the operating system installed and no other software installed or removed. If the computer is not clean, the repackaging tool might not detect files or registry entries that the application requires. As a result, essential files might be left out of the repackaged Windows Installer file, causing the application to break when it is installed. Because it will probably not have more than one program or suite on it at a time, a reference computer does not need to be an especially powerful computer. To keep this computer clean, install only those tools required to repackage the application. If the Application Management feature team is using AdminStudio, team members can download a zero-footprint repackager from directly to the lab client computers. For more information about why using a clean computer is important, refer to Commandment 7, “Starting with a Clean System,” in Macrovision’s The 20 Commandments of Software Packaging (included with BDD 2007).

    Note   It is important to use clean systems when repackaging an application by using a snapshot technology. If the Application Management feature team is using an installation-monitoring method such as that provided by AdminStudio’s Repackager tool, using a clean system is still an important but less crucial best practice.

  • Use a quiet computer. Running processes may make file or registry changes that the repackaging tool detects and includes in the repackaged application. However, these changes will not be necessary for the repackaged application to install and might actually cause problems. Specifically, follow these recommendations:

    • Stop nonessential services and close unnecessary windows on the reference computer. Specifically, stop Automatic Updates, Background Intelligent Transfer Service (BITS), IIS Admin (and all dependencies), the Server service, and Task Scheduler.

    • Ensure that no components (particularly DLLs) of the program about to be installed already exist on the computer. If a DLL, for example, already exists on the computer, the application’s setup program will not reinstall it, and the repackaging program will not record that DLL as part of the installation. When users try to start the application, they will receive an error message stating that a DLL is missing. Make sure that every element of the installation is accounted for.

    • Shut down antivirus software.

    • Shut down programs and applications that could write to the computer's Temp folder or other directories.

    • Do not use mail and word-processing programs.

    • Do not delete files or send files to the Recycle Bin during the creation of a package file.

    • Disable screen saver utilities, e-mail clients, personal schedulers, and other programs that run automatically in the background.

  • Create a package for each unique hardware and software configuration in the organization. Depending on the changes made by the application installation and the significance of the differences between different platforms in the organization, the Application Management feature team may need to repackage a single application once for every different platform. These platform-specific packages are typically more reliable during deployment.

The Application Management feature team can use the Windows Server 2003 RIS feature to quickly deploy clean computers. This feature reinstalls the Windows XP operating system on a computer by downloading a desktop-configuration image that is stored on a computer running Windows Server 2003. For more information, see Remote Installation Services at The team can also use Microsoft Virtual Server 2005 to quickly deploy clean computers. For more information about Virtual Server, see To speed the repackaging process, include any repackaging tools in the clean computer image.

Managing the Workflow

An efficient workflow typically resembles the following process:

  1. Gather requirements from the group that requested the application:

    1. Which client platforms will receive the application?

    2. What changes to the default settings do they require?

    3. How will the application be deployed?

    4. Do they need to deploy different versions of the application to different users? For example, the marketing and operations departments might require the same application but with different settings.

    5. How can Application Management feature team members test the application’s functionality to verify that the package has been deployed successfully?

  2. Prepare a clean repackaging computer to use for discovery by reinstalling the operating system.

  3. While the client computer operating system is installing, prepare computers to test the package. These computers should not be clean but instead should closely resemble the production computers to which the package will be deployed. Prepare a computer for each type of client computer that will receive the application.

  4. On each client computer, connect to a network folder containing the repackaging tool. Launch the repackaging tool, configure the package to be created, and launch the target application’s setup routine.

  5. After the target application has been installed on the repackaging computer, configure the application. This process might include changing default settings, modifying shortcuts, or removing unnecessary files.

  6. Launch the repackaging tool again and capture the post-installation state of the repackaging computer. This process takes several minutes.

  7. Examine the contents of the package. Remove any files or registry entries detected by the repackaging tool that are not directly related to the application installation. For example, if the repackaging tool added a shortcut to the MRU list, remove this shortcut.

  8. Generate the Windows Installer package.

  9. Deploy the new package to the test clients.

  10. On each test client computer, test the application functionality by using the test identified in Step 1. If any functions fail, identify the source of the problem, modify the package, and start over from Step 8.

  11. On each test client computer, test other applications to verify that deploying the new application did not cause any problems. Often, a new application may overwrite a file or setting used by another application, causing problems that may be difficult to isolate in a production environment. If other applications now exhibit problems, modify the package to resolve the problem and start over from Step 8.

  12. For each additional version of the package required (as identified in Step 1), create Windows Installer transform files. Then, repeat Steps 9–11 to verify that the transforms do not cause any problems. For more information about transforms, refer to “Customizing by Using Transforms” later in this document.

Running the Discovery

Discovery is a three-step process:

  1. Analyze the computer’s current files, folders, registry settings, and other important values.

  2. Install and configure an application.

  3. Reanalyze the computer’s files, folders, registry settings, and other important values to determine what has changed.

In theory, this process identifies the changes the application makes during setup, which enables the creation of a Windows Installer package that makes exactly the same changes. In practice, discovery can capture changes not related to the application installation, such as files downloaded through Automatic Updates, changes to the MRU files list, and changes caused by any other background process.

Note   Application Management feature team members cannot easily install device drivers with repackaging. For applications such as Microsoft Windows NetMeeting® that include a device driver, the team must install device drivers separately from the repackaged application.

The sections that follow describe how to perform discovery with AdminStudio, Wise Package Studio, and SMS Installer. Where possible, external documents are referenced for step-by-step instructions.

Performing Discovery with AdminStudio

To perform discovery with AdminStudio, complete the following steps:

  1. Install Repackager on the client computer by using either the full AdminStudio setup file or by downloading the redistributable setup file from

    As an alternative, run Repackager by mapping a drive to a shared folder containing the Repackager executable files. By default, when AdminStudio is installed, the Repackager file resides in C:\Program Files\InstallShield\AdminStudio\7.5\Repackager\islc.exe.

  2. Launch the Repackager tool on the client computer by clicking Start, pointing to All Programs, pointing to Macrovision, FlexNET Admin Studio 7.5 Tools, and then clicking Repackager.

  3. Click InstallShield Repackaging Wizard to start the InstallShield Repackaging Wizard. Click Next.

  4. On the Method Selection page, select Installation Monitoring, as shown in Figure 8. If this repackaging method fails, select Snapshot.

    Figure 8. Using installation monitoring

    Figure 8. Using installation monitoring

  5. On the Collect Product Information page, in the Program File box, type the path to the executable that launches setup for the application being repackaged (probably Setup.exe). Fill in the remaining fields as shown in Figure 9, and then click Next.

    Figure 9. Collecting product information

    Figure 9. Collecting product information

  6. On the Set Target Project Information and Capture Settings page, specify a folder that will contain the project files.

    To keep the lab computer as clean as possible, store the project files on a remote computer.

  7. Click Start. If prompted, click Yes.

    Repackager launches the application’s setup procedure.

  8. Complete the installation by using the settings desired for all computers.

  9. After installation is complete, make any configuration changes that must be part of the package.

  10. In the InstallShield Repackaging Wizard, click Process. Then, click Finish to edit and build the project.

For more information, read “Repackaging Legacy Installations” in AdminStudio Help.

Performing Discovery with Wise Package Studio

First, install Wise Package Studio on the repackaging computer. Then, launch the Wise Package Studio by clicking Start, pointing to All Programs, pointing to Altiris, WISE Package Studio, and then clicking Wise Package Studio. Click the Projects tab. From the File menu, click New Project. Follow the prompts to create a new project.

On the Projects tab, click SetupCapture. Review the instructions shown in the right pane, and then click the Run link.

Note   For information about creating exclusions for Wise Package Studio, refer to the “Cleaning Up a New Package” section later in this guide.

When SetupCapture is complete, as shown in Figure 10, clean the package, as described in “Cleaning Up a New Package” later in this document.

Figure 10. Completing SetupCapture

Figure 10. Completing SetupCapture

Performing Discovery with SMS Installer

First, install the SMS Installer Setup on the SMS site server. Then, on a clean client repackaging lab computer, install SMS Installer from the setup files the SMS Installer Setup routine created. By default, these reside in the C:\SMS Installer Setup\ folder. After the SMS Installer is installed on the clean client lab computer, launch it by clicking Start, pointing to All Programs, pointing to Microsoft SMS Installer, and then clicking Microsoft SMS Installer 32.

Now, follow the instructions in the “Run Repackage Installation Wizard” SMS Installer help topic to capture the original state of the client computer, run the application’s setup procedure, and then capture the post-installation computer state.

Cleaning Up a New Package

After the discovery process, the package may have noise in it caused by processes not related to setup making file or registry changes. If the Application Management feature team distributes the package with these unnecessary settings, the package may cause unpredictable problems on the target computers. Therefore, the team must examine the package, identify any changes not related to the application, and remove those changes.

Identifying changes that should be removed is more art than science. Some changes are obviously extraneous, such as an item being added to the user’s MRU list. Other changes, especially those to portions of the registry that track application library registrations, are hard to interpret. With experience, Application Management feature team members will see some changes repeated in different applications and gain a better understanding of the types of changes that occur in the background and that are unrelated to an application installation.

Non-Microsoft tools can greatly simplify the process of cleaning up a new package. AdminStudio and Wise Package Studio both include the capability to automatically detect and remove extraneous changes. PackageCleaner, available from the PackageCleaner home page at, uses a database to recommend removing likely extraneous elements from packages. Additionally, it can help evaluate which specific elements are required for the package and which are extraneous.

The sections that follow discuss how to clean a new package with Admin Studio, Wise Package Studio, and SMS Installer.

Cleaning a Package with AdminStudio

AdminStudio attempts to filter out any extraneous changes, so no cleaning may be necessary. To clean a package in AdminStudio, complete the following steps:

  1. Open the project captured in the previous phase with the Repackager tool.

  2. In the Captured Installation node, browse Files and Folders, Registry Entries, Shortcuts, and INI Files for elements that may not be related to the application installation. Select any elements that should not be included in the final package, and then click Exclude, as shown in Figure 11.

    Figure 11. Cleaning a project with AdminStudio

    Figure 11. Cleaning a project with AdminStudio

  3. Verify that any necessary files, registry settings, and shortcuts were captured.

    For example, if no new files were captured, it is likely that the capture process did not function properly. Rerun discovery by using snapshot repackaging rather than installation-monitoring repackaging.

  4. Create the Windows Installer package by clicking Repackaged Output, and then clicking Build.

    Repackager creates a Windows Installer package and saves it to the specified folder. By default, the folder is C:\Packages. This package is ready for testing.

When the Application Management feature team is ready to re-clean the lab client, copy only the .msi file. However, the team may want to copy the entire contents of the C:\Packages folder to a distribution server to enable team members to edit the project with Repackager later, and then regenerate the Windows Installer .msi file. No important information related to the package is stored elsewhere.

Cleaning a Package with Wise Package Studio

Wise Package Studio includes a list of elements that are excluded by default from the discovery process, and it has the capability to automatically build an exclusion list to further reduce the number of extraneous elements in packages. As shown in Figure 12, the Application Management feature team can generate this exclusion list automatically by using the SetupCapture Configuration tool. The automatic exclusion list monitors the computer to determine which changes occur even when no setup process is running. Later, when team members run a setup routine, they can ignore these types of changes. Combined, the default and automatic exclusion lists significantly reduce the labor involved in cleaning packages after the discovery process.

Figure 12. Automatically building a Wise exclusion list

Figure 12. Automatically building a Wise exclusion list

The Application Management feature team can use the automatic exclusion list to produce very clean packages; however, team members may need to further edit packages. To clean packages, use the Windows Installer Editor, as shown in Figure 13. This tool enables the addition or removal of files, registry values, shortcuts, and other elements that might be included in a Windows Installer package.

Figure 13. Using the Windows Installer Editor to clean packages

Figure 13. Using the Windows Installer Editor to clean packages

For detailed instructions on using the Windows Installer Editor, open Wise Package Studio, click Windows Installer Editor, and read the contents of the right pane. After making any significant changes, use the Test, Debug, and Run buttons to verify that the package still installs correctly. For more information about cleaning a package, read the Windows Installer Editor 7.0 Reference for Wise Package Studio available at

Cleaning a Package with SMS Installer

As shown in Figure 14, SMS Installer provides a straightforward interface for cleaning a repackaged application. Unlike other repackaging tools, SMS Installer does not automatically clean a repackaged application. Therefore, it is imperative that Application Management feature team members examine each file and registry entry included with the package. If the element is not part of the application installation, remove it from the package.

Figure 14. Cleaning a package with SMS Installer

Figure 14. Cleaning a package with SMS Installer

If the Application Management feature team is using SMS Installer to package multiple applications, it may be worthwhile to configure SMS Installer to ignore specific files and registry entries, such as temporary files that other processes may modify. For detailed instructions, read the SMS Installer help topic, “Configure How SMS Installer Scans the Reference Computer Overview.” When team members have cleaned the package, they can click Compile to create the SMS installer package.

Handling Application Prerequisites

Most interactive application setup routines verify that the computer has the proper software installed. For example, applications based on the Microsoft .NET Framework check for the presence of the .NET Framework before installation. If the required software is missing, the setup routine either installs the necessary software or provides an error message to the user.

When Application Management feature team members repackage an application, the logic that checks for prerequisite software is lost. Therefore, team members may need to provide this intelligence themselves. The capability to specify prerequisites is not provided by Windows Installer nor any software provided at no cost with the Windows operating systems. The team must use additional software, such as the following:

  • AdminStudio Professional. AdminStudio SMS Edition does not have the capability to require application prerequisites before installing an application. However, AdminStudio Professional includes InstallShield Editor. For more information, refer to InstallShield Editor online help topic, “Installation Prerequisites.”

  • Wise Package Studio. Use the Windows Installer Editor tool to build Launch Conditions for a Windows Installer package. For more information, refer to the Wise Package Studio help topic, “Setting a Requirement by Building a Launch Condition.”

Alternatively, Application Management feature team members can write scripts that perform the following actions:

  • Check a client for specific files and registry values that indicate a prerequisite application is installed.

  • Launch the application installation or report an error.

For more information about scripting, visit the Microsoft TechNet Script Center at To identify application prerequisites, refer to the application documentation. Specifically, look for a Readme file included with the application Setup files.

Preparing for Highly Managed (Locked-Down) Environments

Highly managed environments, also known as locked-down environments, limit the security risks of client computers by restricting the privileges granted to users. Because users lack permissions to make major changes to their computers, there is less chance of malicious software infecting their computer. Malicious software can be worms, viruses, Trojan horses, spyware, adware, or any other unwanted software.

Although highly managed client computers reduce security risks, they increase application deployment costs. Because users have fewer privileges, they are not able to install applications. In some cases, they may not even be able to run an application without an administrator either modifying the application configuration or granting the user additional rights. The sections that follow discuss how to address problems related to deploying supplemental applications in environments with restricted user privileges.

Installing Applications in Highly Managed Environments

Most applications require local administrative privileges to install properly. Therefore, distributing applications to users who lack administrative privileges fails unless the installation uses elevated privileges. Windows Installer packages distributed through GPOs can use elevated privileges for proper installation. Similarly, SMS can use the local Administrator user account or a specialized Software Installation account (as shown in Figure 15) to install an application when the currently logged-on user lacks sufficient privileges. For more information, refer to the SMS help topic, “About the SMS Software Installation account.”

Figure 15. Using the Software Installation Account in SMS

Figure 15. Using the Software Installation Account in SMS

To further simplify deploying applications that require administrative privileges during setup, use the Elevated Rights Deployment Tool, included with the SMS 2003 Service Pack 1 (SP1) Administration Feature Pack. The feature pack is available for download from

To use the Elevated Rights Deployment Tool

  1. Prepare the application to be deployed by placing it on a network share and identifying the setup program and command-line parameters typically used to perform the deployment.

  2. Run the installation program for the Elevated Rights Deployment Tool, and indicate the location of the network share, the setup program, and its command-line parameters.

Setup creates an SMS package, programs, program dependency settings, and a preconfigured advertisement. Run this tool once for each application that requires elevated rights after a system restart. SMS then installs the application on computers that the Application Management feature team makes members of a testing collection, allowing the team to open the deployment more broadly.

Running Applications in Highly Managed Environments

Many applications, especially legacy applications, do not run properly when the user has only local User privileges. To enable the application to run properly, three choices are available:

  • Work with the application developers to modify the application requirements so that the application can run properly in a highly managed environment.

  • Provide a second user account to users, and grant this user account sufficient privileges to enable the application to run properly. Instruct users to use the Run As command to launch the application with the higher-privilege account. This approach adds some inconvenience for users, though the Application Management feature team can offset this inconvenience by modifying the application’s shortcut to always use Run As. In addition, this approach reduces user security by giving users the opportunity to run processes with greater privileges.

  • Grant users’ primary accounts the additional privileges necessary to run the application. If the additional privileges required are minimal, such as being able to write to a few select registry keys, the security risk may be acceptable. If the application requires full administrative privileges, the security risks may not be acceptable. Distribute these permission changes by using GPOs or security templates.

For more information about running applications in highly managed environments, refer to the “Resolving Problems with Overly Restrictive Permissions” section in the Security Feature Team Guide.

Validating the Package File

The sections that follow provide high-level instructions for validating packages with AdminStudio and Wise Package Studio. Note that SMS Installer does not include the capability to validate Windows Installer packages.

Validating a Package with AdminStudio

To validate a package with AdminStudio, use the ConflictSolver tool. ConflictSolver is not included with AdminStudio SMS Edition. ConflictSolver use requires AdminStudio Professional Edition. For instructions about using ConflictSolver to validate packages, refer to the AdminStudio online help topic, “Validating Packages.” For more information about resolving conflicts with AdminStudio, refer to Commandment 15, “Performing Conflict Detection,” in Macrovision’s The 20 Commandments of Software Packaging (included with BDD 2007).

Validating a Package with Wise Package Studio

To validate a package with Wise Package Studio, use the Package Validation tool. The Package Validation tool can check both Windows Installer package and transforms. To use the Package Validation tool, open Wise Package Studio, click the Projects tab, and then click Project Validation. Read the instructions in the right pane.

Packaging Best Practices

The following suggestions can help optimize the packaging process:

  • Always back up and then modify a Windows Installer package through the project file, if available.

  • Make generally required changes to the Windows Installer package. Then, make workgroup-specific configuration changes by using transforms (.mst files) rather than by editing the Windows Installer package. In this way, producing generic packages that can be modified for several environments is easier.

  • When compiling a project, never cancel the process. Canceling could corrupt project files.

  • Always re-image computers before packaging a new application.

  • To expedite packaging time, create templates to reuse for processes such as file and registry exclusions.

  • As a backup, always save the application’s package and project file in a separate directory before modifying them.

  • If problems occur during compiling (for example, if the message “Module signature not found” appears), back up the Windows Installer package in another location, delete the original package, and then recompile the image.

  • To keep self-healing for an application, enable advertising on the shortcuts.

  • If the application is self-healing and how the package is being changed is unclear, look at the date and time stamps of the files being installed on the test computer to verify the changed file. Also, verify that no HKEY_CURRENT_USER registry entries are overlooked.

  • Set the property ROOTDRIVE = C:\ in the property table to force applications to install on drive C. Otherwise, if the target computer contains more than one drive, Windows Installer looks for the one with the most free space. This means that Application Management feature team members will not always know on which drive the applications will be installed.

  • For applications that require HKEY_CURRENT_USER registry entries, ensure that all user-specific parts of the installation (that is, all HKEY_CURRENT _USER registry entries) are contained in a separate component. When a new user logs on to a computer, the self-heal functionality of Windows Installer detects the missing component in the user’s profile and populates the user’s registry with the proper settings for the application.

  • Be sure to generate a new product ID for each application. Otherwise, installation problems will occur during installation of more than one Windows Installer application on a single computer.

  • Ensure that any .ini file changes are recorded in the .ini file table rather than only as files in the file table. This ensures that existing .ini files are edited rather than replaced with the version within the Windows Installer package.

  • Follow the components rules:

    • Do not mix user- and computer-specific entries in a single component.

    • Make sure that only one .exe file exists in each component.

    • Ensure that components are unique (that is, they do not have a .dll file that exists in more than one component).

  • Use custom actions with caution. Anything done within a custom action loses rollback capability. If the installation is cancelled or interrupted, changes made within the custom action will not be rolled back.

  • Generate merge modules (.msm files) for common components, and use the merge module in any application that requires the component. Use commercially produced merge modules whenever possible.

  • If an application does not work under Windows XP, see the Application Compatibility Feature Team Guide for help resolving the problem.

  • When security is problematic with an application and must be relaxed in a particular area of the file system or the registry, use Secedit.exe within a custom action to make the required security changes.

Automating Installations

During the Developing Phase, the Application Management feature team must perform the configuration of Windows Installer packages and InstallShield Response Files necessary to automate supplemental application installations. The sections that follow discuss how to configure this automation.

Windows Installer

If the Application Management feature team chooses to deploy an application in a Windows Installer package, team members can automate the installation by using Windows Installer command-line options. If they must deploy the application in multiple configurations, team members can create transforms for each group of configuration settings. The sections that follow discuss this in more detail.

Windows Installer Command-Line Options

The executable program Msiexec.exe interprets packages and installs products for Windows Installer. Note that Msiexec.exe also sets an error level on return that corresponds to the Win32 error codes. These error codes can be useful for identifying installation failures. For information about the available command-line options, see the MSDN Library Command-Line Options page at

As an alternative to learning command-line options, use the Command Line Builder tool in Wise Package Studio to create command lines for automatically installing Windows Installer packages. As shown in Figure 16, the Command Line Builder tool provides a GUI for reliably configuring Windows Installer command-line options.

Figure 16. Wise Package Studio Command Line Builder

Figure 16. Wise Package Studio Command Line Builder

Customizing by Using Transforms

As described in “Understanding Packaging Techniques” earlier in this guide, transforms cause Windows Installer to apply changes to a Windows Installer package. Transforms are often used to deploy a single Windows Installer package to different types of users. For example, the Application Management feature team can use transforms to deploy the same application to the operations and engineering departments but with different default configuration settings. Regardless of the application used to create a transform, transforms can include the following elements:

  • Adding and removing files

  • Removing, adding, or changing registry values

  • Adding or removing shortcuts

  • Changing modifications to .ini files

  • Changing parameters for services included in the Windows Installer file

  • Modifying Open Database Connectivity (ODBC) resources

  • Changing interactive setup prompts

The sections that follow discuss how to create transforms by using AdminStudio SMS Edition and Wise Package Studio.

Creating Transforms with AdminStudio Tuner

To create a new transform with the AdminStudio Tuner (also known as Tuner) tool, follow the instructions in the AdminStudio online help under the topic, “Creating New Transform Files.” As shown in Figure 17, this process is GUI-based and straightforward.

Figure 17. Using Tuner

Figure 17. Using Tuner

After creating the empty transform file, the Tuner interface walks through the process of choosing customizations for the Windows Installer package. As shown in Figure 18, Application Management feature team members can easily add or remove files, registry values, and other installation elements.

Figure 18. Changing package files with Tuner

Figure 18. Changing package files with Tuner

The Tuner tool also enables the creation of response transforms. Using response transforms, Application Management feature team members can specify different application configurations by selecting different options by using the application’s standard setup routine. Response transforms are perfect for deploying a packaged application by using different settings than the default, and the installer provides for changing those settings.

If the Application Management feature team plans to deploy a package by using SMS, team members can use Tuner to create an SMS package definition file and a management information (.mif) file.

Creating Transforms with Wise Package Studio

To create a new transform with the Wise Package Studio InstallTailor tool, open Wise Package Studio, click InstallTailor, and read the instructions in the right pane. When running InstallTailor, it walks through the setup process for the application and provides the opportunity to hide any pages of the setup wizard that the Windows Installer package allows to be hidden.

InstallShield Response Files

Because silent installations do not require user input, the input must come from a different source. The source in this example is the InstallShield Silent Response File (Setup.iss). The response file contains the information a user would provide during a typical installation.

Application Management feature team members can create a response file by running the application’s Setup program and having InstallShield record the response file that they want to use during silent installations.

Recording and Using a Response File

To record the response file, complete the following steps:

  1. Close any programs that are running. Click Start, and then click Run.

  2. In the Run box, click Browse.

  3. In the Browse dialog box, browse to the installation folder on the server.

  4. Select Setup.exe, and then click Open.

  5. Add the -r command-line option to the end of the path to the Setup file—for example:

    \\Server\Source\Application\Setup.exe -r

    Note   The -r option instructs the Setup program to collect responses to the installation process and place them in the Setup.iss response file.

  6. Click OK.

    During the Setup process, answer the prompts to specify the installation options. Because the -r option was added to the Setup Command Prompt window, InstallShield writes the responses to the application prompts to the Setup.iss file in the %SYSTEMROOT% folder on the computer.

  7. Copy Setup.iss from the Windows folder on the computer to the installation folder on the network server.

To use the response file to install the application, complete the following steps:

  1. Close any programs that are running. Click Start, and then click Run.

  2. In the Run box, click Browse.

  3. In the Browse dialog box, browse to the installation folder on the network server.

  4. Select Setup.exe, and then click Open.

  5. Add the -s command-line option to the end of the path to the Setup file—for example:

    \\Server\Source\Application\Setup.exe -s.

    Note   The -s option instructs the Setup program to get input from the response file recorded earlier. The response file must be in the installation folder on the server or the same folder containing the Setup.exe file for the application.

  6. To begin the silent installation, click OK.

Except for the hard disk activity, the installation is transparent. Dialog boxes and startup screens do not appear. If the application must be restarted after installation and the Application Management feature team member clicked Restart Now when creating the response file, the computer will restart. Typically, no warning appears before the restart.

Note   For applications that must be restarted, be sure to allow time to fully understand, document, and test the installation process. If multiple applications are being installed, address the installation order, when a restart is needed, and how to continue the installation of additional applications after restarting. Doing so helps ensure selection of all necessary options during the installation and identification of any dependencies early in the process.

To validate that the installation completed successfully, review the Setup.log file.

InstallShield Troubleshooting

InstallShield writes the results of the silent installation to a text file named Setup.log in the installation folder. Use additional command-line options to modify the location of this file, but by default it resides in the installation folder. Open this file in a text editor such as Notepad or Microsoft WordPad. The log file contains a section called “Response File,” which shows a result code for the silent Setup. Table 7 lists the result codes.

Table 7. Result Code Definitions

Response code





General error


Required data not found in the Setup.iss file


Not enough memory available


File does not exist


Cannot write to the response file


Not a valid list type (string or number)


Data type is invalid


Unknown error during Setup


Dialog boxes are out of order

An application installation has failed if the Setup.log file shows any code other than 0. Response code -12 is a common result. Setup.iss contains a list of the dialog boxes that InstallShield called when the file was recorded. If the computer on which the Application Management feature team member perform the silent installation is configured differently from the one on which the team member recorded the response file, certain dialog boxes might or might not be required. For example, if the computer the team member recorded the file on has Word or Microsoft Office Excel® installed, InstallShield calls the Toolbar Custom Macros dialog box, in which the team member specifies whether to create an application-specific button on the toolbars of these programs. However, if the computer on which the team member performed the silent installation does not have Word or Excel, InstallShield tries to call the dialog box, and the silent installation fails.

Additional Command-Line Options

A variety of additional command-line options are available for InstallShield. See the Macrovision Knowledge Base article, “INFO: Setup.exe Command-Line Parameters” at for a complete list.

Other Command-Line Options

Silent installations are common in an organization’s software implementation and upgrade procedures. A silent installation does not require user input during the installation process. For example, users do not have to choose the type of installation or the folder in which to install the program. Instead, they run the Setup program and continue with their work while Setup installs the product.

Some applications use their own method of installation without using “Installer” technologies. Often, the vendor also provides a way to install the application without requiring input. The most common way to determine whether the application supports this functionality is to refer to the Readme document or execute the setup.exe /? command. Running setup.exe /q installs the application without input.

Silent installations are most commonly seen with updates to applications and operating systems—for example, reviewing the various updates to Windows 2000 Server, because SP3 shows a few different methods of unattended installation. Some of the command-line options that are used to install the operating system updates are -m, -q, -z, /Q or /Q:A, and /R:N. A commonly used set of options is -z -q -m, which installs the update in unattended mode, without user interaction, and does not restart the computer when complete. Table 8 lists these options and the action for each one.

Table 8. Common Command-Line Options and Actions

Command-line option



Do not back up files for uninstallation.


Do not restart the computer when installation is complete


Quiet mode: no user interaction


Unattended Setup mode


Perform uninstallation (must be used with -m or -q)

/Q or /Q:A

Unattended Setup mode


Do not restart the computer after installation


Restart the computer after installation

Microsoft SQL Server 2000 Desktop Edition (MSDE) has a dedicated version of the hotfix installer. This hotfix installer has different command-line options than the Hotfix.exe file used by the operating system. For more information, including detailed examples, see the Microsoft Knowledge Base article, “SQL Server hotfix installer,” at

Microsoft recommends using the application’s supported method of unattended installation when possible. Some applications can create a response file for Setup.exe to use during an unattended installation. This is similar to the process that InstallShield uses when creating Setup.iss for user responses during the installation. However, when applications use their own response files, it can be difficult to understand the syntax, format, and other things that are expected.

The example script in Listing 1 demonstrates what Application Management feature team members can do to build a response file (OMAgentInstall.ini) for an unattended installation. Team members run this script twice to install the application. The first time, BuildAgentINI is passed (along with several other variables) to build the response file. The second time the script is run, NetIQOMAgent is passed to install the application by using the response file created previously. The response file is deleted and the script exits without requiring a restart. If the installation requires restarting the computer, it is generally better to suppress the restart from the application. Commands outside the script evaluate the status upon exiting (REBOOT variable) and either restart or execute the next script.

Listing 1. Sample of a Custom Response File for Application Installation

            :// Phase: NetIQOpsMgr330
            ://  Installs NetIQ Operations Manager 3.3 Agent
            :// Parameters:
            ://  LogFile - Path to logfile
            ://  APFDir    - Root of application directory
            ://  NQInstType - Type of install (NetIQOMAgent or BuildAgentINI)
            ://  TargetDir
            ://  ConfigurationGroup
            ://  Consolidator
            ://  RedundantConsolidators
            ://  TCPPort
            ://  TCPPortEncrypted
            ://  CommunicationsType
            ://  AgentManagerControl      
              (echo Running NetIQ Operations Manager Install.) >> %LogFile%
            Call :%NQInstType%
              (echo Exit NetIQ Operations Manager Install.) >> %LogFile%
            Goto :NQEXit
            : // Install Operations Manager Agents
            (echo Running NetIQ Agent Install.) >> %LogFile%
            :// The file will be created in the %APFDir%\NQOMInst directory
            :// Operations_ManagerInstall.ini must be in \I386 directory
            :// Create OMAgentInstall.ini file
            Call :BuildAgentINI
            start /wait %Fdrv%\NetIQ\OM33Agent\setup /s
                       /Input:%APFDir%\OMAgentInstall.ini >>%LogFile% 2>>&1
            %UtilsDir%\sleep 30
            call %ScriptsDir%\LibRoutines.cmd WaitForProg AgentI~1.exe
            del %APFDir%\OMAgentInstall.ini
            Goto :NQExit
            :// Build the Agent Portion of INI file for the Setup program.
            (echo Building OpsMgr INI file.) >> %LogFile%  (echo [vars])>>
            (echo TargetDir=%NQdir%) >> %APFDir%\OMAgentInstall.ini
            (echo ConfigurationGroup=%NQCfgName%) >> %APFDir%\OMAgentInstall.ini
            (echo Consolidator=%NQPrimCons%) >> %APFDir%\OMAgentInstall.ini
            (echo TCPPort=%NQTCPPort%) >> %APFDir%\OMAgentInstall.ini
            (echo TCPPortEncrypted=%NQTCPPortEnc%) >>
            (echo CommunicationsType=%NQCommType%) >>
            (echo AgentManagerControl=%NQAgentMgrCtrl%) >>
            goto :EOF
            End BuildAgentINI
            :// Set return status
            set RETSTS=0
            goto :EOF
            :// Set reboot status
            set REBOOT=No
            goto :EOF
Windows Script (SendKeys)

Starting with Microsoft Windows 98, Microsoft included a tool with the operating system called Windows Script Host (WSH—Wscript.exe). WSH processes scripts written in a variety of languages, but the most common language is Microsoft Visual Basic® Scripting Edition (VBScript). To see VBScript in action, save the script shown in Listing 2 to a text file named calc.vbs.

Listing 2. VBScript Example Script

            set WshShell = WScript.CreateObject("WScript.Shell")
            WshShell.Run "calc"
            WScript.Sleep 100
            WshShell.AppActivate "Calculator"
            WScript.Sleep 100
            WshShell.SendKeys "2*2{+}2="

Now, double-click Calc.vbs to run it. The script launches Calculator, and then submits the keys 2, *, 2, +, 2, =. Calculator displays the result: 6. Table 9 examines the script line by line.

Table 9. Description of Calc.vbs



set WshShell = WScript.CreateObject("WScript.Shell") 

Creates an object of type WScript.Shell, which is required for simulating keystrokes. Start all scripts with this same line.

WshShell.Run "calc"

Launches the executable file named calc. Provide the full path to executable files that are not in the default path.

WScript.Sleep 100

Waits 100 milliseconds (1/10 of a second) to allow the application to start.

WshShell.AppActivate "Calculator"

Switches focus to the Calculator application. To view the title of an application, open Windows Task Manager and click the Applications tab.

WScript.Sleep 100

Waits another 100 milliseconds.

WshShell.SendKeys "2*2{+}2="

Sends the keystrokes 2, *, 2, +, 2, = to the Calculator application.

This simple script includes most of what is necessary to automate an interactive setup process. One of the more complex elements of these scripts is identifying the special codes required to simulate keystrokes. In the example script, the sequence “{+}” simulates a single key—PLUS SIGN. However, the asterisk (which causes Calculator to perform multiplication) is represented by simply “*”. This is because the SendKeys method uses some characters as modifiers of characters (instead of using their face values). This set of special characters consists of parentheses, brackets, braces, and the following characters:

  • PLUS SIGN (+)

  • Caret (^)

  • Percent sign (%)

  • Tilde (~)

Application Management feature team members can send these characters by enclosing them within braces ({}).For example, to send the percent sign (%), send the string argument “{%}”. Because the PLUS SIGN (+) is a special character, it had to be enclosed in brackets in the example script.

Some keystrokes (such as ENTER and TAB) do not generate characters, and some keystrokes (such as BACKSPACE and BREAK) represent actions. To send such keystrokes, send the arguments shown in Table 10.

Table 10. Special WScript.Shell.SendKeys Characters
















{ENTER} or ~



























































To send keyboard characters that are composed of a regular keystroke in combination with SHIFT, CTRL, or ALT, create a compound string argument that represents the keystroke combination. Do so by preceding the regular keystroke with one or more of the special characters shown in Table 11.

Table 11. WScript.Shell.SendKeys Character Modifiers


Special character







Note   When used this way, these special characters are not enclosed within braces.

To specify that any keys other than SHIFT, CTRL, and ALT should be held down while pressing other keys, create a compound string argument with the modified keystrokes enclosed in parentheses. For example, to send the keystroke combination of the SHIFT key held down while:

  • E and C are pressed, send the string argument +(ec).

  • E is pressed followed by a lone C (with no SHIFT key), send the string argument +ec.

Use the SendKeys method to send a pattern of keystrokes that consists of a single key pressed several times in a row. To do this, create a compound string argument that specifies the keystroke to be repeated followed by the number of times it should be repeated. Do so using a compound string argument of the form {keystroke number}. For example, to send the letter X 10 times, send the string argument {x 10}. Be sure to include a space between keystroke and the number.

Consider the installation of Microsoft Visual FoxPro® 3.0. The installation requires the following steps in sequence:

  • Run Setup.exe.

  • Switch to Visual FoxPro Setup.

  • Press ENTER.

  • Type your user name.

  • Press TAB.

  • Type the organization name.

  • Press ENTER.

  • Press ENTER (again, to confirm).

  • Press ENTER.

  • Press ENTER.

  • Press ALT+C.

  • Press ALT+C.

  • Press ALT+Y.

  • Press ALT+Y.

  • Wait four minutes.

    Note   When required to wait for an installation to finish, it is better to wait too long than not long enough. If the script waits only two minutes but the installation takes three minutes on a slower computer, the following ENTER keystroke would press the Cancel button rather than pressing OK to complete the installation.

  • Press ENTER.

  • Switch to Visual FoxPro.

  • Press ALT+F4 to close the window.

This information is everything necessary to create an installation script. For Visual FoxPro 3.0, the installation script could look like Listing 3.

Listing 3. Example Visual FoxPro 3.0 installation script

            set WshShell = WScript.CreateObject("WScript.Shell")
            Rem Replace the path in the following line.
            Rem Path must be trusted by client.
            WshShell.Run "\\\Software\FoxPro\Setup.exe"
            WScript.Sleep 10000
            WshShell.AppActivate "Microsoft Visual FoxPro Setup"
            WScript.Sleep 100
            WshShell.SendKeys "{ENTER}"
            WScript.Sleep 500
            Rem Tab forward, then tab back to select the username contents.
            WshShell.SendKeys "{TAB}+{TAB}"
            Rem Replace the username in the following line,
            Rem or remove to accept default.
            WshShell.SendKeys "Username"
            WScript.Sleep 500
            WshShell.SendKeys "{TAB}"
            WScript.Sleep 500
            Rem Replace the company name in the following line,
            Rem or remove to accept default.
            WshShell.SendKeys "Company Name"
            WScript.Sleep 500
            WshShell.SendKeys "{ENTER}"
            WScript.Sleep 5000
            WshShell.SendKeys "{ENTER}"
            WScript.Sleep 5000
            WshShell.SendKeys "{ENTER}"
            WScript.Sleep 5000
            WshShell.SendKeys "{ENTER}"
            WScript.Sleep 5000
            WshShell.SendKeys "%c"
            WScript.Sleep 5000
            WshShell.SendKeys "%c"
            WScript.Sleep 5000
            WshShell.SendKeys "%y"
            WScript.Sleep 500
            WshShell.SendKeys "%y"
            Rem Wait 4 minutes while setup installs files.
            WScript.Sleep 240000
            WshShell.SendKeys "{ENTER}"
            Rem Close the window that shows the shortcuts.
            WScript.Sleep 3000
            WshShell.AppActivate "Microsoft Visual FoxPro"
            WScript.Sleep 100
            WshShell.SendKeys "%{F4}"

With that script written, an Application Management feature team member could install Visual FoxPro by saving the script to a central location, and then either running the script when a user logs on or launching it automatically after the operating system is deployed.

Follow these guidelines to avoid security problems on Windows XP clients:

  • When launching setup procedures from shared folders, add the server to the list of trusted servers on the client computer.

  • To avoid having to prompt the user to confirm permission to run a script, sign the scripts and add the certificate to the list of trusted certificates on the client computer.

Interim Milestone: Application Package Complete

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

This milestone, shown in Table 12, measures the team’s progress on identifying application-installation details and packaging applications for automated installation.

Table 12. Application Package Complete Milestone Deliverables

Deliverable ID


Applications Packaged

The applications’ installation and configuration have been automated (if possible).

Integrating Core Applications with BDD 2007

After the Application Management feature team configured and manually tested the core applications, incorporate them into the BDD 2007 imaging process and the BDD 2007 deployment process. Figure 19 illustrates the integration steps involved.

Figure 19. Detailed tasks for integrating core applications with the BDD 2007 image

Figure 19. Detailed tasks for integrating core applications with the BDD 2007 image

Integrate Core Applications into Imaging Builds

After the team has created application packages for core applications, the team can integrate them into the operating system images that the Computer Imaging System feature team creates using Deployment Workbench. For information on how to add an application package to an image using the Deployment Workbench, read the “Appendix B: Configuring the Distribution Share” in the Computer Imaging System Feature Team Guide.

Milestone: Scope Complete

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

At this milestone, shown in Table 13, the Application Management feature team has created all the necessary packages to deploy core and supplemental applications to Windows Vista computers.

Table 13. Deliverables for the Scope Completion Milestone

Deliverable ID


Core Applications’ Feature Sets Defined

The core applications’ features and settings to be included in the package have been defined.

Core Applications’ Packaging Created

The custom core applications have been created and manually tested.

Core Applications Integrated into BDD

The custom core applications have been integrated into the BDD 2007 imaging process and the BDD 2007 application servers.


Get the Microsoft Solution Accelerator for Business Desktop Deployment 2007

Update Notifications

Sign up to learn about updates and new releases


Send us your comments or suggestions