The Top 10 Myths of Windows Installer Repackaging

Published September 2004

Abstract

Ten common misconceptions regarding Windows Installer packages and the repackaging process are debunked in this technical review of some of the challenges faced by systems administrators and desktop engineers. The main issues relating to Windows Installer expertise, Windows Installer repackaging tools, auto-repair, advertising (install-on-demand), secured user environments, file conflicts, and repackaging MSI files are discussed.

Table of Contents
1. Myth: Specialized Knowledge Isnt Required 2. Myth: Knowing How to Build an MSI File is All You Really Need to Learn 3. Myth: All Repackaging Software is Created Equal 4. Myth: Repackaging for Windows Installer is Straightforward 5. Myth: All Windows Installer-Based Applications Support Auto-Repair 6. Myth: All Windows Installer-Based Applications Support Advertising 7. Myth: All Applications Packaged as MSIs Will Run in a Secured User Environment 8. Myth: The Windows Installer Service Will Manage All Potential File Conflicts 9. Myth: You Should Repackage MSIs for Customized Deployment 10. Myth: All MSIs Are Created Equal 2 2 2 4 5 5 5 6 6 6

THE TOP 10 MYTHS OF WINDOWS INSTALLER REPACKAGING

1. Myth:

Many resourceful engineers have waded into the realm of Windows Installer with the notion that all they need is a simple repackaging utility to convert their applications to the Windows Installer format. However, it is easy to underestimate both the power and complexity of Windows Installer. Plus, the sharp learning curve can exceed the time that most administrators have to learn a new set of APIs, syntax, and various software idiosyncrasies. Fortunately, a desktop engineer who is properly equipped with advanced repackaging technology, a complete installation development environment, and a degree of Windows Installer knowledge will be able to generate world-class Windows Installer packages from even the largest and most complicated setup programs.

Specialized Knowledge Isnt Required to Convert Setup Packages to Full-Featured and Reliable MSIs.

2. Myth:

Beyond simply generating an MSI, every systems administrator who deals with Windows Installer should, at a bare minimum, know how to: Validate an MSI against Microsofts Internal Consistency Evaluators (ICEs) Bundle the Windows Installer Service with your Installation file. Run an MSI silently Build and apply Transforms

Knowing How to Build an MSI File is all You Really Need to Learn About the Windows Installer Service.

Build a full-featured MSI that supports Auto-Repair, Advertising, and all other Windows Installer features.

3. Myth:

A consistently reliable repackaging technology must handle a number of issues correctly to successfully convert setup executables and other legacy package formats into full featured Windows Installer packages. Three of the software repackaging disciplines that must be skillfully treated include file exclusions, Windows Installer syntax, and MSI tablemapping. Traditional InstallShield setup executables have been written with as many as 20,000 lines of script. There can be an enormous amount of activity going on under the covers of your installation that even the best repackaging software will be hard-pressed to adequately capture. The software installation may perform numerous operations using Windows API calls, file transfers, conditional logic, and custom actions. At the same time, the system account on the workstation is constantly adjusting operating system settings under the covers. All of these processes can generate data that must be excluded from the Windows Installer package. As always, bad data causes bad output. Most repackaging software will provide some level of exclusion support, and a superior repackaging tool will provide a basic exclusion list that also allows you to edit the captured legacy data and weed out garbage.

All Repackaging Software is Created Equal.

File Exclusions

Failing to properly exclude unwanted data from a repackaging snapshot can lead to a vast array of problems with the application, many of which will lurk unknown until the administrator or user attempts to remove the application. The following examples are just a few of the files and directories that must be excluded in order to properly generate a fully functional and removable application.

THE TOP 10 MYTHS OF WINDOWS INSTALLER REPACKAGING

 Uninstall shortcuts With MSI, the Windows Installer Service handles the uninstallation functions. Uninstall shortcuts included by an installation will fail to start the uninstall wizard.

Schedl*.txt file If this file is not excluded, the application will install cleanly, but will not allow itself to be removed. Temp directories Stray temp files can cause unpredictable behavior in your application. In many cases, installing these files will cause the Operating System to crash. Log Files Captured log files can mislead you, your application or the operating system about the true state of your application.

NT USER.DAT Including the current user registry file in your package will cause your installation to either fail due to insufficient permissions, or will (if it successfully installs) overwrite the existing user registry on the target system and cause serious damage to the operating system. WINNT Many of the files from the system directory are designed for use only by the system account. Pulling certain system files into your application can lead to either installation failures due to improper permissions or operating system crashes.

Windows Installer Syntax

Registry Data Capturing more registry data than necessary can lead to an installation that goes in cleanly, but pulls out critical registry data on uninstall.This can result in broken applications and system failures.

This seemingly obvious requirement is, however, frequently a stumbling block for repackaging software, especially when dealing with inexpensive or free utilities. This before and after MSI conversion data is a classic example of registry syntax that is often mistranslated by repackaging software. Configuration\Query\Initialization] "AgentDll List"=multi_sz( s, ) "kagtdac.dll" "$kagtldb.dll$cube50.dll$" "kagtuser.dll" "kagtres.dll" [HKEY_LOCAL_MACHINE\SOFTWARE\Company Name\Product Name\5.0\Data Obj

The registry values captured by the repackaging software must be properly formatted and converted to the proper syntax for the Windows Installer package to function properly.

"kagtsess.dll" "kagtsbo.dll" "#kbus.dll#kgtrep50.dll#REPOSITORY#Agent Reposit#"

"!kbus.dll!kagtunv.dll!UNIVERS!Universe!UNVRES!UniverseResource!USEROBJECTS!Universe User Objects!" "#kbus.dll#kagtux50.dll#UX#Universe Export#" "#kbus.dll#kagtdp.dll#DP#|rsc_dp|#" "*kagtdps.dll*cube50.dll*" "!kagtdpqt.dll!cube50.dll!"

"#kbus.dll#kagtdpc.dll#DPC#|cli_dp#" "#kbus.dll#kagtda.dll#DA#Data Access#""#kagtdas.dll#cube50.dll#""#kagtdap.dll#cube50.dll#" "*kagtdpp.dll*cube50.dll*" "*kagtdpsp.dll*cube50.dll*"

THE TOP 10 MYTHS OF WINDOWS INSTALLER REPACKAGING

"@kagtuum.dll"

"#kbus.dll#kagtlov.dll#LOV#List Of Values#" "$kbus.dll$cube50.dll$DM$Data Manager$"

"#kbus.dll#report50.dll#DX#Document Exchange#" "$kbus.dll$cube50.dll$GDM$General Data Manager$" "#kbus.dll#kagtbx.dll#BX#Document Exchange#". After proper Windows Installer conversion, the registry data will use the following syntax.Note that the multi-string registry data has been parsed out with the append, prepend, orreplace multiple strings syntax [~] required by Windows Installer. This syntax will replace multiple strings with a null-delimited list of new registry string data. [~]kagtdac.dll[~]$kagtldb.dll$cube50.dll$[~]kagtuser.dll[~]kagtres.dll[~]kagtsess. dll[~]kagtsbo.dll[~]#kbus.dll#kgtrep50.dll#REPOSITORY#Agent Resource!USEROBJECTS!Universe User Reposit#[~]!kbus.dll!kagtunv.dll!UNIVERS!Universe!UNVRES!Universe Objects![~]#kbus.dll#kagtux50.dll#UX#Universe

Export#[~]#kbus.dll#kagtdp.dll#DP#|rsc_dp|#[~]*kagtdps.dll*cube50.dll*[~]#kb us.dll#kagtdpc.dll#DPC#|cli_dp#[~]!kagtdpqt.dll!cube50.dll![~]#kbus.dll#kagtda .dll#DA#Data

Access#[~]#kagtdas.dll#cube50.dll#[~]#kagtdap.dll#cube50.dll#[~]*kagtdpp.dll* cube50.dll*[~]*kagtdpsp.dll*cube50.dll*[~]@kagtuum.dll[~]#kbus.dll#kagtlov.dll# LOV#List Of Values#[~]#kbus.dll#report50.dll#DX#Document Exchange#[~]$kbus.dll$cube50.dll$DM$Data Manager$[~]$kbus.dll$cube50.dll$GDM$General Data

Manager$[~]#kbus.dll#kagtbx.dll#BX#Document Exchange#[~] At the heart of a Windows Installer package is a relational database structure that includes tables for all of the typical events, custom actions, user interactions and sequences for installing and uninstalling software. As with most technologies, there are many different ways to generate a Windows Installer package. The best repackaging tool will follow Microsoft's guidelines (established by the Windows 2000 logo program) for populating the correct tables and setting key paths to generate a full-featured Windows Installer package.

Windows Installer Table Mapping

4. Myth:

Although the process for creating a Windows Installer package appears to be very straightforward (using a clean machine, run the repackaging tool to create before and after snapshots of the installation) creating a package that functions properly, uninstalls correctly, and supports all of the capabilities of the Windows Installer Service is an intensive discipline. One important measure of Windows Installer package quality is whether or not it meets the Windows 2000 Logo requirements. These requirements are somewhat stringent, and many IT shops consider the effort to be higher than the reward. Not following these guidelines, however, can cause a number of problems with your MSIpackage, including advertising (install-on-demand) failures, auto-repair failures, clean rollback failures, and secured user environment installation failures, to name a few. Formore details, see myths 5-7.

Repackaging for Windows Installer is Straightforward.

THE TOP 10 MYTHS OF WINDOWS INSTALLER REPACKAGING

5. Myth:

If a Windows Installer-based application package is built according to Microsoft best practices, each portable executable file (DLL, EX, OCX, HTM, HLP TLB, ) will be assigned to its own component and , the file will be used as the key path for the component. A component is a building block of the installer package that is associated with one or more of an applications features. A key path is used by the Windows Installer Service to detect if an auto-repair of the component is required. If more than one file is included in the component, and a file other than the one specified in the key path is later removed, then the auto-repair feature of the Windows Installer Service will not detect the file is missing and replace it. Therefore, only by following the Microsoft best practice of assigning each portable executable file to its own component and key path will the Windows Installers auto-repair feature be supported within your MSI.

All Windows Installer-Based Applications Support Auto-Repair.

Furthermore, a well-built MSI will have the auto-repair capabilities enhanced by listing additional copies of the MSI to use as backup sources for repair files in case the primary repair MSI cached on the machine is unavailable. This redundancy is designed to enable 99.999% reliable auto-repair of the application, but it is not activated by default. Additional sources must be designated in the Source List table of the Windows Installer package.

6. Myth:

Many MSI packages built are not properly configured to allow advertising (install-on-demand).This is because the repackaging software used did not properly parse the registry data into Windows Installers separate Extension, Program ID, Registry Verb,MIME type, and COM Class tables, and did not populate the Advertise table with the required shortcut information.

All Windows Installer-Based Applications Support Advertising (Install-on-Demand).

The best way to check for problems with advertising is to run the MSI through Microsoft's Internal Consistency Evaluators to look for ICE 33 warnings. If it passes these evaluators(which are also used for Windows 2000 logo compliance testing) then it has been properly configured for advertising.

7. Myth:

In a secured Windows 2000 or Windows XP environment, a user with standard permissions wont be able to make registry changes under HKEY_LOCAL_MACHINE or edit files in the application directory <Program Files>, which are common locations that programs written for Windows 9x/NT 4 use to store their application data and user-defined changes like resized windows and modified tool pallets. A good way to identify applications that have this problem is test them under both the administrator accounts and a standard user account. If the application works when logged in as admin, but fails under user privileges, then special configuration of the MSI package is required.

All Applications Packaged as MSIs Will Run Properly in a Secured User Environment.

Note that it is also possible to solve the problem by adding your users to the built-in Power Users group which was designed specifically to provide compatibility for legacy applications. However, this approach looses many of the benefits of locking down your workstation, as users are given back the right to install software on their workstations. The best approach is to identify the areas on the machine that the older application needs to be given access to, in order to run properly. AdminStudio allows you to modify your installation program to selectively open up only the parts of the workstation required to make the application work. With this approach the machine retains a high level of security.

THE TOP 10 MYTHS OF WINDOWS INSTALLER REPACKAGING

8. Myth:

The Windows Installer Service manages system wide the sharing of resources (files and registry data). The Windows Installer Service can also be configured to support component isolation in order to avoid potential conflicts when applications distribute different versions of the same shared file. This is not a default MSI configuration. The best way to truly manage potential file conflicts is using a third-party conflict database like AdminStudios ConflictSolver. A conflict database is used to store all the various MSIs, MSMs, MSTs, and base OS configurations used in your enterprise. It then checks each one against the others for a number of different conflicts that may arise when one application overwrites or removes a resource needed by another application.

The Windows Installer Service Will Manage All Potential File Conflicts.

Another approach to managing conflicts involves configuring an MSI package to isolate an application's dependencies from the system folder either by creating a Win32 manifest(Windows XP only) or .local files (for Windows 2000 Windows 98 2nd Edition). Advanced tools like AdminStudio guide you through a Wizard to easily setup thisApplication Isolation to avoid most potential file conflicts.Top 10 Myths of Windows Installer Repackaging

9. Myth:

If you need to customize an MSI for deployment within your organization, then a Transform should be created to modify the installation. Transforms (.MST files) allow you to input the variables that you need to set for the application, without loosing any of the original logic or hierarchy of the software vendors MSI. Tools like AdminStudio provide both simple Transform creation by stepping through the installation Wizard and recording the settings, plus an advanced capability for viewing and modifying any aspect of the MSI via a Transform.

Repackaging an MSI that you have received from a software company is neither desired nor is it necessary. Every vendor-supplied MSI contains some level of internal logic and internal hierarchy used to properly configure an application in many different environments. Repackaging an MSI strips out all the internal logic and places all of the components under a single feature.

You Should Repackage MSIs for Customized Deployment.

The difference between MSIs that will not support all Windows Installer features and MSIs that do support all Windows Installer features often amounts to whether or not the MSI passes the Microsoft Internal Consistency Evaluators (ICEs) used to test Windows logo compliance. Additionally, an accurate repackaging process with proper exclusions, syntax handling, and table mapping is vital to the producing quality MSI packages. Furthermore, its recommended that your MSI be fully tested for conflicts with the rest of your application portfolio to eliminate potential problems.

10. Myth:

All MSIs Are Created Equal.

There are advanced tools, such as AdminStudio, that can help you create high-quality and full-featured MSI packages. For more information visit www.installshield.com/isas.

THE TOP 10 MYTHS OF WINDOWS INSTALLER REPACKAGING

www.installshield.com
900 NATIONAL PARKWAY SUITE 125 USA SCHAUMBURG, IL 60173-5108 TEL: 1-800-809-5659

............................................ KINGS HOUSE 14 ORCHARD STREET BRISTOL, BS1 5EH UNITED KINGDOM

+1-847-466-6000

TEL: +44 (0) 117 903 0650

1990-2004 Macrovision Europe Ltd. and/or Macrovision Corporation. All Rights Reserved. AdminStudio is registered trademarks or trademarks of Macrovision Corporation in the United States of America and/or other countries. All other brand and product names mentioned herein are the trademarks and registered trademarks of their respective owners. Part No. ASMYTHWP01-1103