Packaging for Windows Vista™ means preparing an installation to install properly on a computer that is running Vista.

With the introduction of Windows Vista, organizations are challenged with migrating large numbers of applications to the new operating system. Several of the features that were introduced with Vista, especially User Account Control (UAC), can affect how existing installations run. The packaging phase of the Vista migration process helps you determine which applications will work on Vista and ensures that those applications will install successfully.

This section discusses how to use Altiris® tools to package applications as part of your Vista migration and provides best practices and instructions for performing the packaging. As a result of following this process, you will produce packages for core applications that are ready for introduction into your organization's Vista environment.

The packaging process cannot fix applications that are not coded to support Vista. However, if the problem is related to the application's installation, you might be able to resolve Vista compatibility issues by customizing the package.

Topics include:

• Before You Start
• Vista Features That Affect Installations
• Overview of the Vista Packaging Process
• Preparation for Packaging
• Core Application Analysis and Review
• Application Repackaging
• Vista Compatibility Testing
• Reference: Vista-Related Package Validation Errors

Before You Start

Before you start the process of packaging applications for Windows Vista, we assume that:

You will follow the recommendations made in earlier phases of the Vista migration process. In particular, you will perform a clean installation of Vista on the client computers, rather than updating existing operating systems.

• You understand the features of Vista that will affect your migration. See Vista Features That Affect Installations.
• You have completed the previous phases of the Vista migration process, specifically:
  • Defining the end user environment and creating a standard image to use for installing Vista.
  • Identifying the core applications to migrate.
  • Defining the set of applications that will be installed on each group of computers in your organization.
  • Deciding whether to use virtualization technology to manage applications.

What You Need

To perform the packaging phase of a Vista migration, you need:

• Wise Package Studio® Professional Edition
• Wise Package Studio Quality Assurance module

This configuration contains the features and tools that are required for complex packaging and thorough testing.

See Setting Up a Packaging Environment.

Vista Features That Affect Installations

According to Microsoft, most applications will function properly on Windows Vista because the application compatibility in Windows Vista is very high. However, several new features in Vista can affect how applications and their installations perform. Some of these issues can be resolved by packaging while others cannot.

Following are the most common problems that application installations can encounter when run on Vista. For detailed information, search for "Windows Vista Developer Center" in the MSDN library (msdn.microsoft.com).

User Account Control (UAC)

Under earlier versions of Windows, users frequently logged on as administrators, leaving their computers vulnerable to security breaches. User Account Control requires that all users run in standard user mode. This limits the risk of users making changes that could harm their computers. It also prevents malware from attempting to infect computers undetected. Administrators can run most applications with limited privileges, but can temporarily elevate their privileges when they need to perform an administrative task.

Making sure that applications run as a standard user is an important issue for administrators. According to Microsoft, if an application works well as a standard user on Windows XP, then it will work well as a standard user on Windows Vista. Nonetheless, some applications will require changes to their installation, function, and update processes to work under UAC.

Some UAC-related issues can be resolved by packaging:

• Custom installers, uninstallers, and updaters may not be detected and elevated to run as administrator. Therefore, Microsoft recommends using Windows Installer (.MSI) format for application installations.
• If an application has been written to be installed and run by standard users without elevation, you can customize the package to disable UAC prompting. However, if the installation tries to install to a protected area, it will fail without any indication to the user.
• Custom actions within the installation that run programs, install .MSI files, or run WiseScripts may not run with the correct privileges. You can customize the package to change the user context in which the custom action runs. The success of this solution depends on whether the custom action can run in the other context.

Windows Resource Protection (WRP)

Windows Resource Protection (WRP) prevents the replacement of essential system files, folders, and registry keys that are installed as part of Windows Vista. System components can be updated only by a Microsoft-approved installation package.

When an application package is installed, Windows Installer skips the installation of any resource that is protected by WRP, enters a warning in the log file, and continues the installation without displaying an error. This can cause the application to fail if it requires a different version of the protected resource than what is already on the computer.

To avoid this problem, you can do one of the following:

• Customize the package to isolate the system files that it installs. The success of this solution depends on whether the application still works after you make the changes.
• Install the package into a virtual software layer, which eliminates any attempt to overwrite protected resources. The application uses the resources that are installed in the layer, so it always uses the correct versions.
• If the resource that the application requires is already on the destination computer, you can remove it from the installation. However, if you do this, your application can fail if the protected resource is updated or changed in the future.

Windows Vista 64-bit

Windows Vista fully supports the 64-bit architecture processors from AMD and Intel. The 64-bit version of Windows Vista can run all 32-bit applications; however, it does not support any 16-bit code or rely on any 16-bit component.

Edit the package in Windows Installer Editor to remove 16-bit features, if they are not part of the application's primary functionality. If the application depends on the 16-bit features, the application developer must resolve this issue.

Restart Manager

Installations and updates often require computer restarts when files that are being updated are in use by a running application or service. On Windows Vista, Restart Manager can detect processes that have files in use and stop and restart them without requiring a restart of the computer. Applications that are written to take advantage of Restart Manager can be restarted and restored to the same state and with the same data as before the restart.

Edit the package in Windows Installer Editor to set options that control how Restart Manager behaves for a specific package.

Windows Vista Logo Requirements

The Windows Vista Logo Requirements outline the technical requirements an application must meet in order to become Certified for Windows Vista. Use the Package Validation tool to validate a package against these requirements. Although these requirements are intended for application developers, the validation provides an indicator of whether the package will install successfully on Vista.

For information on Windows Vista Logo Requirements, refer to the document Requirements for the Windows Vista Logo Program for Software. Search for "Windows Installer and Logo Requirements" in the MSDN library (msdn.microsoft.com) and follow the links to download this document.

Windows Vista Internal Version Number

The internal version number for Windows Vista is 6. Installations that check for a specific version number might fail on Vista. To fix this, edit the package in Windows Installer Editor, unless the application is coded for a specific Windows version, or if its End User License Agreement prohibits use on future operating systems.

Overview of the Vista Packaging Process

The Vista packaging phase is divided into the following steps:

Preparation for Packaging.	Develop standards for packaging and define the configuration file to use with the SetupCapture® tool.
Core Application Analysis and Review.	Decide which applications need to be repackaged.
Application Repackaging	Analyze the installation to determine what changes you need to make. If necessary, convert the installation to .MSI format. Customize the package to optimize it for Vista.
Vista Compatibility Testing	Perform thorough testing to ensure that the installation and the application work properly on Vista.

For details, see Packaging for Vista Process Flow.

What Decisions Will You Make in the Packaging Phase?

• Your organization's standards for packaging, if you do not have them. These consist of:
  • SetupCapture standards, which determine how captures are performed and what information is captured.
  • A standard packaging process.
  • How to customize packages to meet organizational standards that are not related to Vista.
• Whether you will use virtualization technology to:
  • Run SetupCapture within a layer, which facilitates restoring the capture computer to its original state.
  • Install the package into a virtual software layer for running installation tests in Test Expert, which facilitates restoring the test computer to its original state.
• Which of your core applications need to be repackaged for Vista.
• How to customize each package for Vista.
• Which tests you will perform during the testing step.
• What to do if an application is not compatible with Vista and the problems cannot be resolved by packaging. Options are to wait until the vendor provides a version that is Vista compliant or find an alternate application.

Packaging for Vista Process Flow

Preparation for Packaging

Typically, you perform this step once when you first begin packaging. You do not need to repeat it for each package.

This step consists of the following tasks:

1. Developing Standards for Packaging
2. Setting Up a Packaging Environment
3. Setting Up Wise Package Studio
4. Populating the Software Manager Database

Developing Standards for Packaging

This task is part of the packaging preparation step.

In this task, you develop a standard packaging process. If your organization already has a packaging process, review it and add any Vista-specific standards that are necessary.

Some standards to consider are:

Suggested standard	Details
Installation format	Microsoft recommends using Windows Installer (.MSI) format for application installations on Vista.
Standards for how installations run	Level of user interaction Do packages need to install silently (with no dialogs or user interaction) or quietly (no user interaction is desired but indication of the installation’s progress is necessary)? Destination directories Other requirements that might require customization of the installation Example: Should packages be allowed to contain hard-coded paths?
Packaging tasks	In Wise Package Studio, you can define process templates that list the packaging tasks and run the appropriate packaging tools. Using standard processes provides consistency in your packaging and ensures that all packaging is performed according to your standards.
Whether to use software virtualization technology to facilitate packaging	Wise Package Studio can use software virtualization to: Run SetupCapture within a layer, which facilitates restoring the capture computer to its original state. Install the package into a virtual software layer for running installation tests in Test Expert, which facilitates restoring the test computer to its original state. Note As of version 2.0, the Altiris® Software Virtualization Solution™ software is not completely compatible with Vista. This will be resolved in a future release; however, you currently cannot install into a virtual software layer.

Setting Up a Packaging Environment

This task is part of the packaging preparation step.

For full system requirements and installation instructions, refer to the Wise Package Studio Getting Started Guide.

A proper packaging environment contributes to the success of your packaging efforts. When you standardize the packaging hardware and software, you eliminate variables that can affect the success or failure of packages and make troubleshooting difficult.

We recommend that you designate specific, separate computers for different packaging activities. Each of these computers has different configuration requirements.

• Packaging computer
  Except where noted otherwise, use this computer for packaging tasks (example: customizing packages). You also use the packaging computer for certain testing tasks. See Setting up a Packaging Computer.
• Capture computer
  The capture computer is a clean machine that contains only the operating system and its service packs. Use this computer to convert packages. See Setting up a Clean Capture Computer.
• Test computer
  The test computer contains a base build, which represents the minimum software that is installed on every computer or group of computers in the organization. Use this for testing packages in a lab environment. See Setting Up a Test Computer With a Base Build.

Because Wise Package Studio is licensed per user, you can install one license of Wise Package Studio on multiple computers, provided only one user accesses that license at any given time. For details, see the Wise Package Studio End User License Agreement.

Setting up a Packaging Computer

This task is part of the packaging environment setup.

Use the packaging computer for most tasks in the packaging process.

To set up a packaging computer

1. Designate a packaging server and install Wise Package Studio Server.
   For full system requirements and installation instructions, refer to the Wise Package Studio Getting Started Guide.
2. Designate a packaging computer. Install Wise Package Studio Client and the Quality Assurance module.
   Except where noted otherwise, use this computer for packaging tasks (example: customizing packages).

Setting up a Clean Capture Computer

This task is part of the packaging environment setup.

Using a clean machine to capture applications creates more robust repackaged installations by making them less dependent on the existence of other applications. A clean machine is a computer with only the minimum software installed as determined by an organization's standards. The emphasis is on minimum-a clean machine does not contain business applications.

In general, a clean machine should contain the following software:

• An operating system other than Vista, preferably the lowest common operating system. (If an installation does not run on Vista, you cannot capture it on a computer that is running Vista.)
• The version of Internet Explorer that is used in your organization.
• Wise Package Studio. Installing Wise Package Studio on a clean machine does not compromise the repackaging process because Wise Package Studio files and registry entries are not included in captured packages.

The clean machine will be restored frequently between packaging projects. Your options for restoring the clean machine are:

• Create an image of each clean machine configuration and use it to reimage the computer between captures.
• Run SetupCapture within a layer, which facilitates restoring the capture computer to its original state.

To set up a capture computer

1. Designate a computer for capturing packages.
2. Install the operating system and its service packs.
3. Install Internet Explorer.
4. Install Wise Package Studio Client.
   For full system requirements and installation instructions, refer to the Wise Package Studio Getting Started Guide.
5. Create an image of this computer so you can reimage it after each capture. Store the image in a location that is accessible to all packaging team members
   If you will run SetupCapture within a layer, skip this step.

Setting Up a Test Computer With a Base Build

This task is part of the packaging environment setup.

Some testing tasks are performed on the packaging computer and others require a separate test computer. The test computer should contain a base build, which represents the minimum software that is installed on every computer in the organization. If your organization supports multiple base build configurations, create a separate base build or image for each one.

Your organizational standards should define the base build contents. In general, a base build should contain the following software:

• The operating system that is used in the organization or the group, in this case, Windows Vista
• The version of Internet Explorer that is used in the organization or group
• Wise Package Studio
• Antivirus software
• Network software
• Distribution client software

The test computer will be restored frequently to ensure consistent testing results. Create an image of each base build configuration and use it to reimage the test computer between tests.

To set up a test computer

1. Install the operating system and Internet Explorer.
2. Install the additional software that is required for this base build.
3. Install Wise Package Studio Client and the Quality Assurance module.
   For full system requirements and installation instructions, refer to the Wise Package Studio Getting Started Guide.
4. Create an image of this computer so you can reimage it after each test. Store the image in a location that is accessible to all packaging team members
   If you will use Test Expert for testing, and if you will install the package into a virtual software layer during testing, skip this step.

Setting Up Wise Package Studio

This task is part of the packaging preparation step.

In this task, you set options and create configurations in Wise Package Studio that reflect your organization's standards for packaging.

This task consists of the following subtasks:

1. Defining the SetupCapture configuration file
   In this task, you run SetupCapture Configuration to edit and create a configuration file that controls how SetupCapture works. SetupCapture uses this configuration file when it converts an application to Windows Installer format.
2. Capturing the standard operating environment
   The standard operating environment (SOE) consists of the files, registry keys, and so on that comprise the operating system. It also can include basic system software and the applications that are installed for every user or every group of users. Use SOE Snapshot to scan a computer for this information and then save it as an .SOE file, which you can import into the Software Manager database to represent a baseline machine in your organization. This lets the ConflictManager® tool detect and resolve conflicts between the SOE and the applications you package.
   The Altiris software virtualization technology eliminates the typical file and registry conflicts that ConflictManager resolves. Therefore, if you plan to run applications in a virtual environment, skip this task.
3. Customizing the Windows Installer template
   When you create a new Windows Installer installation, it gets its configuration from a template file that contains logical defaults and commonly used settings. Customizing the Windows Installer template to meet your organization's requirements eliminates the need to make the same changes for each new installation that is created.
4. Defining ConflictManager settings
   To optimize ConflictManager, you can:
• Refine the conflict detection so that it finds only the kinds of conflicts that concern you.
• Use conflict resolution rules to resolve conflicts automatically and consistently. Using conflict resolution rules saves time, reduces errors, and produces consistency in conflict resolution.
5. Setting preferences
   Set preferences to control the behavior of the Workbench interface in Wise Package Studio, as well as of Windows Installer Editor and Software Manager.

These subtasks correspond to tasks in the Initial Workbench Setup project in Wise Package Studio. Using this project ensures that you do not skip any important steps and helps you become familiar with the interface and its process-oriented approach. For details, refer to the Wise Package Studio documentation.

Populating the Software Manager Database

This task is part of the packaging preparation step.

In this task, you import base packages into the Software Manager database to simulate the environment on the destination computers as closely as possible for conflict detection.

For conflict detection to be most effective, you need to compare the contents of the package to:

• The operating system or standard operating environment (SOE)
• Configuration information that is associated with device drivers and Group Policy Objects that will be on the destination computers
• The applications in the base build
• All other applications that will be installed on the destination computers

To make these comparisons, you must add the above information to the Software Manager database.

When to Import Packages into the Software Manager Database

You import packages into the Software Manager database at various times during the packaging process.

Type of Package	When to Import
Operating system or SOE	After you create the SOE snapshot.
Device drivers and Group Policy Objects	At the beginning of the packaging process and whenever you add a new driver or Group Policy Object to the destination computers.
Application packages	After you have customized the package. See Importing the Package into the Software Manager Database.

If you change a package that is in the Software Manager database, re-import it.

To import base applications

1. On the packaging computer, open Wise Package Studio.
2. Run Software Manager.
3. If certain groups of users require different applications, then create corresponding groups in Software Manager. Assign the applications to the appropriate groups either during or after the import.
4. Import the SOE Snapshot (.SOE) that you created during the Wise Package Studio setup.
5. If the SOE Snapshot does not contain the base build applications, import them.
6. Import any other applications that will be on the destination computers. Include any associated transforms, patches, and Microsoft Hotfixes.
7. Import the .INF files for any device drivers that will be on the destination computers.
8. Import the .POL files for any Group Policy Objects that will be on the destination computers.

Core Application Analysis and Review

In this step, you become familiar with the application that you need to package so that you can develop project-specific standards to guide the packaging team.

This step consists of the following tasks:

1. Obtaining the Application
2. Deciding Whether to Repackage an Application for Vista
3. Analyzing the Vendor Installation

Requirements

Before you begin this step, complete the tasks in Preparation for Packaging.

Obtaining the Application

This task is part of the analysis and review step.

In this task, you verify that you have the correct installation file for each application that you will test and package for Vista.

Ask the vendor if the application supports Vista or if a Vista compliant upgrade is available. If not, then obtain the items listed below.

What to Obtain

• The application's installation file from the original media or from the vendor's Web site.
• Any additional applications or resources that you might need to install with the application. Example: To create Adobe® PostScript® files, an application might require a specific PostScript driver.
• If the application has already been packaged, identify the location of the approved package file and any associated files.
• If the application is developed internally, ensure that the installation and its source files are in a shared location.

Deciding Whether to Repackage an Application for Vista

This task is part of the analysis and review step.

In this task, you review the core applications that you identified earlier in the migration process and determine which ones require repackaging. You also decide what to do if an application does not run on Vista and the problems cannot be resolved by packaging. Your options for such applications are:

• Wait until the vendor provides a version that is Vista compliant. This might delay your migration.
• Find an alternate application. This might not be possible if it is a critical application.

When to Convert an Installation to Windows Installer Format

• The installation is not in Windows Installer format. Microsoft recommends Windows Installer (.MSI) format for application installations on Vista.
• The installation does not run on Vista and you think you can resolve the problems by customizing the installation.
• The installation must be changed to comply with organizational standards that are not related to Vista.

When to Customize a Windows Installer Installation

• You have converted it from a non-Windows Installer format.
• You encounter errors during testing on Vista that can be resolved by customizing the installation.
• The installation must be changed to comply with organizational standards that are not related to Vista.

What to Do if the Application is Already Vista Compliant

• You should still perform your usual tests to verify that the application installs and runs properly in your environment.
• If you will use virtualization technology, you might create an SVS enabled package to install the application into a layer.
• Depending on the format of the installation, you might need to convert and customize it, for the reasons stated above.

Analyzing the Vendor Installation

This task is part of the analysis and review step.

In this task, you become familiar with the application's installation so that you can:

• Decide how to customize the installation for Vista. Example: Do you need to isolate files that are installed in a protected area?
• Understand how to install the application. Example: Which components of the application need to be installed? Does the installation require a restart?
• Determine whether the package meets your organization's standards, especially those for Vista packages.
• Help determine why installation tests fail. Example: Are files installed to restricted locations?

To gather information about a Windows Installer installation

Do this when the package is already in Windows Installer format. Even if you do not plan to customize the package, the reports can help you troubleshoot problems during the testing step.

1. On the packaging computer, open Wise Package Studio.
2. Run Windows Installer Editor and open the vendor package.
3. Select Reports > Package Contents > Summary, or Reports > Package Contents > By Feature.
   This generates a report that lists detailed information for every resource in the installation, including merge modules, files, registry keys, .INI files, shortcuts, and more. Save or print the report.
4. Still in Windows Installer Editor, click the Test button in the lower right of the Window.
   This runs the installation without making any changes to the computer.
5. As you step through the installation, review and document the installation sequence and your responses to the installation dialogs.

To gather information about a non-Windows Installer installation

If the package is not in Windows Installer format, perform the analysis when you run SetupCapture to convert the installation. See Converting an Installation to Windows Installer Format.

To analyze the installation

Use the information that you gathered about the installation above.

• Review your documentation of the installation sequence. Use this information to determine:
• What installation logic to add to the package. Examples: What files are installed? What registry keys are created? Are shortcuts installed on the desktop? How is the program named in the Program group? Are certain user rights required to install the program successfully?
• What user interface elements, if any, to add to the package.
• Review the reports that list the changes that the installation makes. Save these reports as part of the package documentation.

Application Repackaging

This step consists of the following tasks:

1. Converting an Installation to Windows Installer Format
2. Customizing a Windows Installer Package for Vista
3. Importing the Package into the Software Manager Database
4. (Optional) Enabling a Package for SVS

Requirements

Before you begin this step, complete the tasks in Core Application Analysis and Review.

Converting an Installation to Windows Installer Format

This task is part of the repackaging step.

In this task, you capture the application's installation into Windows Installer format. Microsoft recommends Windows Installer (.MSI) format for application installations on Vista. Other formats might not be fully supported on Vista.

Skip this task if any of the following is true:

• The installation is already in Windows Installer format.
• You previously repackaged the application.
• You captured the application as part of the evaluation step and saved the resulting package.

About SetupCapture

SetupCapture is the primary tool in Wise Package Studio for converting installations to Windows Installer format. It records all the changes that an installation makes and saves that information to a new package. SetupCapture can also capture the first-use changes that an application makes to a computer, which can be applied to the base .MSI that originally installed the application to simulate the changes made during the first launch. (Example: Acceptance of a license agreement.)

SetupCapture does not monitor any internal logic within the installation and it does not replicate the user interface of the original installation. You must add that information to the new package during the customization task.

You also can use SetupCapture to gather information that helps you analyze the installation. See Core Application Analysis and Review.

SetupCapture Guidelines

• Run SetupCapture on a clean machine or within a virtual software layer.
• Do not capture an .MSI-based installation. Instead, edit the .MSI directly in Windows Installer Editor or create a transform to customize it.

For additional SetupCapture guidelines, refer to the Wise Package Studio documentation.

To capture the application's installation

1. 1 On a clean image on the capture computer, open Wise Package Studio.
2. Exit all other applications, including background services or applications. (Example: Norton AntiVirus.)
3. Run SetupCapture.
4. Step through the initial wizard dialogs to specify information about the package that will result from the capture and the capture method to use.
   Note: Capturing to a .WSI (Windows Installer project) instead of an .MSI provides more options for customizing the installation. The .WSI compiles to an .MSI.
5. On the Execute Installation dialog, specify whether to perform the capture within a virtual software layer.
6. With the Execute Installation dialog still displayed:
1. Specify the installation .EXE and execute it.
   The changes that are made by the installation are captured.
2. As you step through the installation, review and document the installation sequence and your responses to the installation dialogs. Use this information to analyze the installation.
3. On the Execute Installation dialog, restart the computer.
   The changes that are made to the computer after the restart are captured.
   When the computer restarts, the Execute Installation dialog reappears.
4. Start the newly installed application and make any changes to the application that are necessary to meet your organization's standards.
   Examples: Dismissing license agreement messages that appear the first time the application is started; turning off tool tips; and anything else that should not be included in the final package.
   When you finish, close the application.
5. Make any environmental changes that are necessary to meet your organization's standards.
   Examples: Renaming the shortcut that was created by the original installation; renaming the application's title from the default name; moving information that was installed under a specific user's profile (example: Administrator) to the All Users profile so that any user running the application can access it.
7. Click Next on the Execute Installation dialog.
8. On subsequent dialogs, review and edit the items (files, registry keys, .INI files, and shortcuts) to include in and exclude from the new package.
9. Finish the capture and save the resulting package.
10. When the capture process finishes, view or print the Installation Sequence and Installation Changes reports, which are in the same directory as the new package.
    Use this information to analyze the installation.
11. If you performed the capture within a virtual software layer, delete or deactivate the layer to restore the computer to its original state.

Customizing a Windows Installer Package for Vista

This task is part of the repackaging step.

In this task, you edit a Windows Installer package so that it will run on Vista.

• If you converted the original installation to Windows Installer format, see Customizing a Newly-Captured Package.
• If the .MSI was supplied by the vendor or is one that you previously repackaged, see Customizing an Existing .MSI With a Transform.

You might need to repeat this task if you find errors during testing. If you make additional changes to a customized package that was imported to the Software Manager database, you must re-import it after recompiling. If the package was enabled for SVS, you must re-enable it.

What Changes Do You Need to Make?

The following list is not comprehensive; it suggests typical changes. Determine which changes are necessary by analyzing the installation (see Core Application Analysis and Review) or by reviewing errors you encounter during testing.

• Add installation logic that was not captured by SetupCapture. Example: Launch conditions that check for system requirements.
• Add support for Vista-specific features:
• Disable the User Account Control (UAC) prompting for standard user installations.
• Set options for Restart Manager.
• Create and edit user interface elements that were not captured by SetupCapture. (Example: Installation dialogs.) This depends on your deployment environment and whether you want to expose the installation interface to end users.
• Disable the user interface for silent installations.
• Change the installation's system requirements to run on Windows Vista.
• Remove 16-bit features from packages that will run on the 64-bit version of Windows Vista, if they are not part of the application's primary functionality.
• If the installation installs a file that would otherwise be installed to an area that is protected by Windows Resource Protection (WRP), you can do one of the following:
• Delete it from the installation and test the application with the version that is on the destination computer. However, if you do this, your application can fail if the protected file is updated or changed in the future.
• Isolate the protected file so it is installed to a different location. See Isolating Files in a Windows Installer Package.
• Set Windows Installer logging options to provide verbose output. The installation log can provide valuable information about why an installation fails.
• Fix errors that are reported by Package Validation during testing. For information on which errors you can resolve, see Reference: Vista-Related Package Validation Errors.
• Fix installation-related errors that you find while performing installation and functionality tests.
• Make other changes that are not related to Vista but are required by your organization's standards. Example: Create a command line to run the installation in silent mode.

Windows Installer Editor Quick Reference

For detailed instructions on using Windows Installer Editor, refer to the Windows Installer Editor documentation. You also can obtain context-sensitive help by pressing F1 from any window or dialog in the product.

Use the following quick reference to learn where to edit different aspects of the package.

To edit or create	Use this area of Windows Installer Editor
Common installation tasks, including the installation of files, registry keys, and shortcuts	Pages in the Installation Expert view
Options for supporting User Account Control (UAC)	Installation Expert > Windows Installer Options page
Options for supporting Restart Manager	Installation Expert > Windows Installer Options page
Installation dialogs	Installation Expert > Dialogs page or Setup Editor > Dialogs tab
Components	Setup Editor > Components tab
Features	Setup Editor > Features tab
Custom actions	MSI Editor view
Properties	Setup Editor > Product tab > Properties icon
System requirements, including the required operating system	Installation Expert > System Requirements page
Launch conditions	Setup Editor > Product tab > Launch Conditions icon
Logging options	To set options within the installation: Installation Expert > Windows Installer Options page To set options with a command line: Installation Expert > Command Line page
A command line to run the installation	Installation Expert > Command Line page
A file isolation	Instead of using Windows Installer Editor, use one of the following Wise Package Studio tools: Application Isolation isolates files in a specific package. See Isolating Files in a Windows Installer Package. ConflictManager can isolate files as part of the conflict resolution process. See Resolving File and Registry Conflicts.

Customizing a Newly-Captured Package

In this task, you use Windows Installer Editor to edit the package directly. Do this when you have converted the installation to Windows Installer format.

If the vendor installation was already in .MSI format, see Customizing an Existing .MSI With a Transform instead.

You might need to repeat this task if you find errors during testing. If you make additional changes to a customized package that was imported to the Software Manager database, you must re-import it after recompiling. If the package was enabled for SVS, you must re-enable it.

To customize a package

1. From Wise Package Studio, open Windows Installer Editor.
2. In Windows Installer Editor, open the package.
3. Edit the package as needed.
4. Save and compile the package.

Customizing an Existing .MSI With a Transform

In this task, you use Windows Installer Editor to customize an .MSI that was supplied by the vendor.

Often, the vendor license agreement prohibits you from editing the vendor-supplied .MSI. Instead, create a transform (.MST) that can be applied to the .MSI at run time to customize the installation. To create the transform, you must have access to the original (base) .MSI.

If the installation was not originally in .MSI format and you converted it, see Customizing a Newly-Captured Package instead.

You might need to repeat this task if you find errors during testing. If you make additional changes to a customized package that was imported to the Software Manager database, you must re-import it after recompiling. If the package was enabled for SVS, you must re-enable it.

To customize an .MSI with a transform

1. On the packaging computer, open Wise Package Studio.
2. Run Windows Installer Editor.
3. Select File menu > New.
   The New Installation File dialog appears.
1. From the Categories list, select Other Templates.
2. In the Templates/Tools list, select the Transform icon and then click OK.
4. Specify the .MSI on which the transform should be based.
   The transform opens with the same settings as the base .MSI.
5. Change the installation as needed.
6. Save the transform in .MST format.
   The Transform Details dialog appears.
7. Complete the Transform Details dialog and click OK.

When you distribute the package, include both the .MST and the base .MSI. To install the package, you use a command line that applies the changes in the transform to the .MSI.

Isolating Files in a Windows Installer Package

In this task, you use the Application Isolation® tool in Wise Package Studio to isolate files that would otherwise be installed to an area that is protected by Windows Resource Protection (WRP).

You can isolate files in the following types of packages: Windows Installer installations (.MSI, .WSI), merge modules (.MSM, .WSM), and transforms (.MST). If the package is not in one of these formats, skip this task.

You also can isolate files during the conflict resolution process in ConflictManager. See Resolving File and Registry Conflicts.

About Windows Resource Protection and Application Isolation

Windows Resource Protection prevents the replacement of essential system files, folders, and registry keys that are installed as part of Windows Vista.

When an application package is installed, Windows Installer skips the installation of any resource that is protected by WRP, enters a warning in the log file, and continues the installation without displaying an error. This can cause the application to fail if it requires a different version of the protected resource than what is already on the computer. To prevent this problem, you can isolate certain protected files.

Example:

Your program file, Application.exe, is installed in the application directory, but it depends on certain versions of the shared files abc.dll and 123.ocx, which are installed in the System32 directory. However, Windows Resource Protection prevents you from overwriting those shared files. Application Isolation isolates those files by placing them in the application directory or in the WinSxS directory. When the package is installed, the protected files are installed to their isolated locations, and your application can use the versions of those files that it requires.

To isolate files

1. From Wise Package Studio, run Application Isolation.
2. Specify the package .MSI.
3. Select the method to use for isolating files: .NET manifests or Windows Installer isolated components.
4. Select the files to isolate.
5. Specify whether to save the results as an .MSI or .MST.
6. Complete the isolation process.

Importing the Package into the Software Manager Database

This task is part of the repackaging step.

In this task, you import the new package into the Software Manager database so you can perform conflict resolution or enable the package for SVS.

If you change a package that is in the Software Manager database, re-import it.

To import a new package

1. On the packaging computer, open Wise Package Studio.
2. Run Software Manager.
3. Import the new package.

If you created a transform (.MST) to customize the package, then verify that the base .MSI has been imported. When you import the .MST, specify the base .MSI to associate it with.

Enabling a Package for SVS

This task is part of the repackaging step.

In this task, you enable the package for the Altiris® Software Virtualization Solution™ (SVS). If you do not plan to use virtualization technology to manage applications in your environment, skip this task.

When to Perform This Task

• Enable the package for SVS after you have validated it. (See Validating a Windows Installer Package) If you find errors during the validation, it is easier to fix them before you have enabled the package.
• Repeat this task if you make additional changes to the package to fix errors you found during testing. After you recompile the package, re-import it to the Software Manager database and then re-enable it for SVS.

About SVS Enabled Packages

Enabling a package creates a WiseScript™ wrapper that contains the package and the instructions for its installation. To install the package, you deliver and run the wrapper .EXE instead of the .MSI or .MST.

When an enabled package is installed on a computer where SVS is present, the enabled package can create a virtual software layer, install the package into the layer, and save and activate the layer. If the SVS agent is not present, the package is installed normally. Installing a package into a virtual software layer can eliminate many Vista compatibility issues. Example: Because all files that are installed by the package are in a virtual layer, they will not conflict with files that other applications have installed.

To enable the package for SVS

1. On the packaging computer, open Wise Package Studio.
2. Run Software Manager.
3. Import the package to the Software Manager database, if you have not already done so. See Importing the Package into the Software Manager Database.
4. If the package is not in .MSI or .WSI format, create a package definition file. If you created a transform (.MST) to customize the package, create the package definition for the base .MSI and add the .MST file, any associated .CAB files, and any associated command lines.
5. Enable the package in Software Manager. You cannot enable an .MST; instead, enable its base .MSI. A WiseScript wrapper is created in the form of a WiseScript project (.WSE) and its compiled .EXE.
6. (Optional) Open the .WSE in WiseScript Package Editor or WiseScript Editor to customize the installation further. Example: To add SVS script actions that manage and update the layer. When you finish editing the wrapper, recompile the .EXE. For details, refer to the WiseScript Package Editor documentation.

In subsequent steps, you test and distribute the .EXE file, not the .WSE.

Vista Compatibility Testing

In this step, you test the package thoroughly to ensure that it runs in your Windows Vista environment.

This step consists of the following tasks:

1. Validating a Windows Installer Package
2. Testing in a Lab Environment With Test Expert , for Windows Installer packages
3. Testing in a Lab Environment Without Test Expert, for non-Windows Installer packages
4. Assessing the Package’s Impact
5. Resolving File and Registry Conflicts
6. Troubleshooting Test Results

Every time you edit the installation, repeat these tasks to ensure that your changes do not cause problems.

When you complete all tests successfully, the package is ready for introduction into your Vista environment.

Validating a Windows Installer Package

This task is part of the testing step.

In this task, you use the Package Validation tool in Wise Package Studio to determine whether the package complies with requirements for Microsoft’s Windows Vista Logo Program certification.

Although many of the validation checks identify important issues that should be addressed prior to deploying a package, some of the other issues should be regarded as informational. Very few commercially available applications fully comply with the Windows requirements. Your organization’s standards should specify whether this is important.

You can validate the following types of packages: Windows Installer installations (.MSI, .WSI), merge modules (.MSM, .WSM), and transforms (.MST). If the installation is not in one of these formats, skip this task.

To validate the package

1. On the packaging computer, open Wise Package Studio.
2. Run Package Validation.
3. Specify the package to validate and select the option to perform the Windows Vista Compatibility Checks.
Note: We recommend that you validate the package’s .WSI instead of the compiled .MSI. If you correct a .WSI, it is recompiled to an .MSI at the end of validation. If you correct an .MSI errors are not corrected in the corresponding .WSI.
4. If no critical issues are found, go to the next task in the testing step.
5. If critical errors are found, fix them. See To fix validation issues.
6. Rerun Package Validation to confirm that the critical issues were fixed. If critical issues remain, repeat this process until they are fixed. If you cannot resolve all errors, perform the remaining testing tasks anyway to determine whether the package will install on Vista.

To fix validation issues

After Package Validation checks the package, it displays the View / Correct dialog, which lists the issues it finds.

1. Review each issue by selecting it in the upper list and viewing its description in the Details list.
• If an ICE error is displayed, open Windows Installer Editor and access the Windows Installer SDK Help. Search for the specific ICE error to display details about the issue and learn how to fix it.
  Example: An ICE08 error appears if two or more components have the same GUID. To fix the error, change one of the duplicate GUIDs.
• If the issue is not an ICE error, read its description to determine its cause.
2. Decide which issues to fix. See Reference: Vista-Related Package Validation Errors. Also, use your organization’s packaging standards as a guide.
   Examples:
• If you do not need to meet Microsoft’s logo requirements, you can skip any logo-related issues that are not critical.
• If you will run the installation silently, you can skip any issues that are related to the installation’s user interface.
3. Fix the issues.
• If the Correct button is enabled when you select an issue on the View / Correct dialog, click it to correct the issue.
• If the Correct button is not enabled when you select an issue, the issue cannot be corrected from within Package Validation. Mark Add to Task List to add the issue to the Task List in Windows Installer Editor.

When you finish Package Validation, open the package in Windows Installer Editor and fix the issues that appear in the Task List. For guidelines on editing the installation, see Windows Installer Editor Quick Reference.

Testing in a Lab Environment With Test Expert

This task is part of the testing step.

In this task, you use the Test Expert tool in Wise Package Studio to thoroughly test the package in a consistent, structured manner. Test Expert helps you perform installation, functionality, uninstall, and other tests.

You can use Test Expert with the following types of packages: an .MSI with or without a transform (.MST), an .EXE that has been compiled from a Windows Installer project, and groups of packages from the Wise Software Repository. If the installation is not in one of these formats (example: an SVS enabled package) skip this task and go to Testing in a Lab Environment Without Test Expert.

If the tests fail, your options are:

• Wait until the vendor provides a version that is Vista compliant.
• Find an alternate application.
• If you think that the failure is caused by the installation and not the application, try to fix the problems by customizing the package. See Application Repackaging.

About Test Expert

Test Expert reads the package contents and generates a Master Test Plan that contains test cases based on the contents. (Example: If the package contains a launch condition that requires Vista, a test case is created to test that launch condition.) Generated tests are run within Test Expert. Some tests run automatically, some tests start a process but wait for you to visually confirm results, and some tests must be run manually.

When you run an installation test, you can:

• Install as a user other than the logged on user. This lets you test the installation with a different privilege level.
• Install the package into a virtual software layer, which facilitates restoring the test computer to its original state.

Testing Transforms

To test an .MSI with one or more associated transforms, do one of the following:

• In Text Expert, after you specify the .MSI, specify the transforms to apply to it.
• Create a Software Manager group that contains the .MSI and its transforms. Then, in Test Expert, specify the group to open.

To test with Test Expert

1. On the base build image on the test computer, open Wise Package Studio.
2. Run Test Expert.
3. In Test Expert, open the package or group.
   Test Expert generates a Master Test Plan, which contains test cases based on the contents of the package. You can add custom test cases for tests that you will run outside of Text Expert.
4. Prepare the test computer. Depending on what you are testing, this might include:
• Installing the application
• Uninstalling the application
• Setting display or other options to match or fail launch conditions
5. Run the test cases:
1. Select a test case.
2. If a Run column with checkboxes appears in the lower-right pane, mark the test items to run.
3. To start the test, click one of the buttons at the top of the window: Install, Uninstall, Execute, or Run. Not all buttons appear for all tests; only relevant buttons appear. During installation tests, if SVS is installed on the test computer, you can install the application into a virtual software layer.
4. When the test finishes, set the status of the test items to Pass or Fail. Some tests set this automatically. Then set the overall status of the test case to Pass or Fail.
6. When you have run all the test cases, testing is complete.
• If all the tests are successful, go to Resolving File and Registry Conflicts.
• If one or more critical tests fail, see Troubleshooting Test Results.

Testing in a Lab Environment Without Test Expert

This task is part of the testing step.

Do this for packages that are not in Windows Installer format (example: SVS enabled packages). Otherwise, use Test Expert instead. (See Testing in a Lab Environment With Test Expert)

In this task, you determine whether the installation runs on Vista. If this test fails, your options are:

• Wait until the vendor provides a version that is Vista compliant.
• Find an alternate application.
• If you think that the failure is caused by the installation and not the application, try to fix the problems by customizing the package. See Application Repackaging.

To test the application’s installation and functionality

1. Install the base build image on the test computer.
2. Log on as a user with rights that are similar those of end users in the organization.
3. Install the package.
• If the installation succeeds, go to step 6.
• If the installation fails and no installation permission prompts were displayed, then right-click the installation file in Windows Explorer and select Run as administrator.
4. Rerun the installation.
• If the installation succeeds, go to step 6.
• If any errors appear (example: OS version, CLSID registration, or file copy):
1. Right-click the installation file in Windows Explorer.
2. Click the Compatibility tab.
3. Select Run this program in compatibility mode for and Windows XP (Service Pack 2).
5. Rerun the installation.
• If the installation succeeds, go to step 6.
• If the installation fails, you cannot run this application on Vista. Your options are listed above.
6. Start the application.
• If the application launches successfully, go to step 7.
• If the application does not launch successfully or if errors appear:
1. Right-click the application’s .EXE file in Windows Explorer.
2. Click the Compatibility tab.
3. Select Run this program in compatibility mode for and Windows XP (Service Pack 2).
4. Re-start the application.
7. Perform all tests that you typically use to test the application’s functionality.
• If all the tests are successful, see To test the uninstall.
• If one or more critical tests fail, see Troubleshooting Test Results.

To install as an administrator

Do this when you cannot install or run the package correctly as a user with limited rights.

1. Restore the base build image on the test computer and log on as a user with administrative rights.
2. Rerun the installation.
• If the installation succeeds, continue with the next step.
• If the installation fails, the problem probably is not caused by security rights. See Troubleshooting Test Results.
3. Perform all tests that you typically use to test the application’s functionality.
• If all tests are successful, then elevated rights are required to install successfully. Review your organization’s standards. Is it permissible to give the end user elevated rights for this package? If not, ask the vendor if there are other options for installing the application.
• If one or more critical tests fail, the issue is probably not related to security rights. Try to fix it by editing the package. See Customizing a Windows Installer Package for Vista.

To test the uninstall

In this task, you verify that the package’s uninstall removes all items cleanly.

1. On the test computer, uninstall the package. If you installed an SVS enabled package, simply delete the virtual software layer and skip the remaining steps.
2. Referring to the reports that you generated during the installation analysis task, determine the following:
• Did the package create files or registry entries that were not removed?
• Did the uninstall remove files or registry entries that were not installed by the package?
• Did the package install files or registry entries that were not uninstalled?
3. If the uninstall tests were successful, go to Assessing the Package’s Impact.
4. If the uninstall tests were unsuccessful, see Troubleshooting Uninstall Problems.

Assessing the Package’s Impact

This task is part of the testing step.

In this task, you use the Impact Assessment tool in Wise Package Studio to assess the potential impact of installing the package in your environment. Whereas conflict detection focuses on files that are installed by the package, Impact Assessment focuses on files that are not installed by the package but are used by files in the package.

When you import a package into Software Manager, executable files (.EXE, .DLL, and .OCX) within the package are scanned for dependencies on files that are outside the package. (Example: An executable in the package uses the file user32.dll, which is a system file.) Impact Assessment uses this information to help you find problems that might occur if you install a package that updates the dependency files.

Impact Assessment is most typically used to assess patches and hotfixes. However, it also is useful for finding potential problems with other types of packages. Example: Applications that are run in a virtual environment might depend on files that are outside the virtual layer. Installing a package that changes one of those dependency files can break the dependent application, even though it is installed in a virtual layer.

Requirements

• .. The Software Manager database must be populated with all or most of the packages that will be installed on a given computer or group of computers. See Populating the Software Manager Database.
• .. The package you are testing must be imported into the Software Manager database. See Importing the Package into the Software Manager Database.

To perform an impact assessment

1. On the packaging computer, open Wise Package Studio.
2. Run Impact and Risk Assessment.
3. Specify the package to assess.
4. Mark Impact on Dependencies.

Packages that are affected by the current package are displayed.

You cannot resolve the issues within Impact Assessment; however, you can use the impact information to target your testing of the package in a lab or production environment that contains the dependent applications.

Resolving File and Registry Conflicts

This task is part of the testing step.

In this task, you use the ConflictManager® tool in Wise Package Studio to detect and resolve potential conflicts between the current package and the other packages in the Software Manager database, which represent the other packages that will be installed in your environment. ConflictManager also finds conflicts that are related to the operating system and to configuration information that is associated with device drivers and Group Policy Objects. Resolving these conflicts before you deploy the package can reduce postrollout costs and decrease end user downtime.

The Altiris software virtualization technology eliminates the typical file and registry conflicts that ConflictManager resolves. Therefore, if you plan to run applications in a virtual environment, skip this task.

Requirements

• The Software Manager database must be populated with all or most of the packages that will be installed on a given computer or group of computers. See Populating the Software Manager Database.
• The package you are testing must be imported into the Software Manager database. See Importing the Package into the Software Manager Database.
• If you decide to use conflict resolution rules to resolve conflicts automatically, review the predefined rule sets and decide which one to use, or customize them to meet your organization’s requirements.

To find and resolve conflicts

1. On the packaging computer, open Wise Package Studio.
2. Run ConflictManager.
3. Select Conflicts menu > Detect.
   ConflictManager compares the resources each package installs. When it finds resources that conflict, it populates the Software Manager database with conflict information.
4. Resolve file conflicts.
   Resolving a conflict involves looking at each file that is installed by multiple packages and selecting the version to install on the destination computer. You also can isolate, or change the location of, conflicting files so that each package can use its version of the file.
5. Resolve registry conflicts.
6. Export resolved packages.
   After you resolve conflicts, export the changes to the original Windows Installer installation and recompile it to produce a package that does not conflict with other packages.
7. If the package contained conflicts that you could not fix through ConflictManager, then virtualize the package to eliminate conflict issues. See Enabling a Package for SVS.

Troubleshooting Test Results

If you encounter errors during testing, refer to the following table for possible solutions.

Problem	Possible Solutions
Validation errors are reported.	See To fix validation issues.
Installation fails when run as a user with limited rights.	Run the installation as a user with administrative rights. If elevated rights are required to install successfully, review your organization’s standards. Is it permissible to give the end user elevated rights for this package? If not, ask the vendor if there are other options for installing the application.
Installation fails when run as a user with administrative rights.	The issue is probably not related to access rights. Try to fix it by editing the package. See Customizing a Windows Installer Package for Vista.
The package does not function correctly.	If you think the problem can be fixed by editing the package, do so. See Customizing a Windows Installer Package for Vista. If you think the problem might be caused by a conflict, go to Resolving File and Registry Conflicts.
A package that you converted to Windows Installer format does not install or function correctly, and you cannot fix the problems.	Repeat the tests with the original vendor package. If it installs and functions correctly, consider packaging it as is without converting its format. Otherwise, contact the vendor.
Errors are reported during the Preflight tests or during user acceptance testing.	Determine whether they are caused by the package or the environment and take steps to fix them, if possible.
A conflict cannot be resolved.	Virtualize the package to eliminate conflict issues. See Enabling a Package for SVS.

Troubleshooting Uninstall Problems

If you encounter problems during uninstall testing, open the installation in Windows Installer Editor and check the following:

• If the uninstall removes files or registry keys that should be left on the computer, it might mean that the files were captured in error. If that is the case, remove them from the package and consider adding them to the SetupCapture exclusion list so they are not added to captured packages in the future.
• If the package overwrites an existing registry value, the uninstall does not remove the registry key, but it also does not revert the registry key back to its original value. If possible, perform a conflict resolution to avoid the overwrite.
• If the uninstall does not remove changes that were made by a custom action that calls a WiseScript, use WiseScript Editor to edit the WiseScript to install Unwise32.exe. In Windows Installer Editor, use a custom action to call the Unwise32.exe.
• Verify that custom actions are run during the correct installation modes.
• On the Component Details dialog, check whether a component is marked to be left installed.
• On the Registry Details dialog, check the uninstall settings for registry keys.
• On the Service Control Details dialog, check the uninstall settings for services
• If the package contains a custom action to install or download a file, verify that it also contains a custom action to remove the file during uninstall.
• On the Remove File Details dialog, check the setting that determines when the file is removed.
• If the package installs a virtual directory, check the uninstall setting on the virtual directory’s Details dialog.
• If the package contains SQL statements for creating or configuring a SQL Server database, the uninstall won’t roll back changes made by the SQL statements.

For information on the settings mentioned above, refer to the Windows Installer Editor documentation.

Reference: Vista-Related Package Validation Errors

The Package Validation tool in Wise Package Studio lets you check a Windows Installer package for compliance with the requirements for the Windows Vista Logo Program certification. You do this by running the Windows Vista Compatibility Checks, which finds and displays errors that will prevent the package from running on Vista.

The table below lists which errors you can resolve by editing the installation in Windows Installer Editor. (See Windows Installer Editor Quick Reference.) The errors that cannot be resolved in the installation must be resolved in the application itself. If the application that you are testing is developed internally, work with your organization’s developers to fix it.

In the following error messages, the numbers in [] indicate information related to the error from the specific instance of the error in the installation.

Vista validation error	Can you resolve this in the installation?
CustomAction: [1] is a nested installation type custom action that is not supported on Windows Vista.	Yes
CustomAction: [1] uses impersonation. Impersonation should not be used when running setups on Windows Vista.	Maybe Edit the custom action and change its In-Script Options property to Deferred Execution - System Context. Test to verify that the custom action runs in this context. If you can create a transform that performs the same function as the custom action, then you can delete or comment out the custom action in the installation.
Property: [1] begins with reserved characters. MSI property names cannot start with “MSI” (caseinsensitive).	Yes Rename the custom property so that it does not begin with “msi”.
Table: [1] begins with reserved characters. Custom MSI table names cannot start with “MSI” (caseinsensitive).	No
Component: [1] has a null ComponentId. All components must have a valid ComponentId for proper installation and uninstallation. If this is left null, justification must be documented.	Yes Edit the component details and generate a GUID for the component ID.
Registry Key: [1] is a Windows Protected Resource. Key: [2]	Yes If the registry key that the application requires is already on the destination computer, you can remove it from the installation. However, if you do this, your application can fail if the protected registry key is updated or changed in the future.
File: [1] is a Windows Protected Resource. Target Path: [2]	Yes Customize the package to isolate the system files that it installs. Install the package into a virtual software layer, which eliminates any attempt to overwrite protected resources. If the file that the application requires is already on the destination computer, you can remove it from the installation. However, if you do this, your application can fail if the protected file is updated or changed in the future.
The MSI does not contain an MsiPatchCertificate table entry. An MsiPatchCertificate table entry is required for User Account Control (UAC) patching.	No You cannot add a digital signature to a vendor’s installation.
Component: [1] contains multiple files that are the target of a Desktop or StartMenu shortcut.	Yes Edit the shortcuts so that only one file per component is specified as a target for the Start menu or a Desktop shortcut.
Component: [1] contains multiple files and contains COM information. Only one COM server is allowed per component.	Yes Edit the component so that it contains only one COM file.
Action: [1] is sequenced in the InstallUISequence table with a condition that contains the AdminUser property, the Privileged property should be used.	Yes Edit the custom action’s condition so that it does not contain the AdminUser property.
Launch Condition: “[1]” uses the AdminUser and/ or Privileged property. Use a Type 19 custom action in the InstallExecuteSequence instead. LaunchCondition Description: [2]	Yes Edit the launch condition so that it does not use the AdminUser or Privileged property, or replace the custom action with a Terminate Installation (Type 19) custom action.
Feature: [1] does not install under Program Files or the users Application Data folder by default. Target Directory: [2]	Yes, if you can redirect where to install the files. Change the default directory for this feature. However, if the application is hard-coded to look in a different directory for this feature, then it might fail.
File [1] in Component [2] is not digitally signed. All .dll and .exe files distributed to Windows(R) Vista are required to be signed.	No You cannot sign files in the vendor’s application.
Custom Action: [1] is not documented. The intended behavior of all custom actions must be documented.	Yes Edit the custom action to add a description. The Windows Installer Editor documentation contains information you can use to document Wise custom actions.

Also see:

Vista Compatibility Testing
Validating a Windows Installer Package