 |
The Stories of My Life | Gallery | Projects | Friends and Family | Web Log | Contact |
Repackaging Applications for Windows Installer
Created 2001
Last Updated 3/6/2003
Contents
Chapter 1 Introductory msi-information………………………..3
Chapter 2 Using WinInstall LE to Package Applications………8
Chapter 3 Using IPWI to Repackage an Application…………..19
Chapter 4 Installing the MSI package……………………………….
Chapter 5 Removing applications installed from MSI files………………………..
Chapter 6 Repackaging NAL Objects as MSI files………………………..
Chapter 7 Transform (*.mst) Files………………………………………………….
Appendix A: Windows Installer Terminology ………………………………………
Appendix B: Windows Installer Resources…………………………………………..
Chapter 1
Introductory msi-information
Why should applications be repackaged as MSI files?
- Software resiliency
Software packaged as MSI files has the ability to repair itself should a file or registry location become damaged. Another form of resiliency is that the Windows Installer service can look for the MSI source file in several locations (specified by the creator of the MSI package).
- Remote management
With Active Directory, MSI applications can be remotely installed on all computers or for all users in any group. This means that, when properly configured, a user who needs a certain set of applications has those applications available no matter wherever he or she logs in. It also means that applications can be added, removed, or updated for a given group of computers or users.
- As a replacement for NAL objects
In the past, legacy applications have been packaged as NAL objects using ZenWorks SnAppShot. However with the future of Novell on the UMR campus uncertain, the desktop group has decided to eliminate dependancy on Novell file and print services in our future projects. With this comes a need for legacy applications to be repackaged. With the coming of Active Directory, MSI files seemed to be the natural choice.
· Rollback capability
If the installation of a product doesn’t complete successfully, the Windows Installer service can roll-back the installation, undoing everything it has done during the installation. This is another form of resiliency in that if an installation fails, the user can continue to use the aapplications installed before the failed install takes place. Failed installs don’t break other working applications since everything that takes place during an install can be undone until the app install completes successfully.
When not to repackage applications as MSI’s
- When the application install files include an MSI file
If the application does include an MSI file, you’re better off creating a silent install using the provided MSI file and specifying command-line parameters to choose the appropriate actions during install.
- When the application install files were created with InstallShield Pro ver 5/6
If the installation package provided with the application was created with InstallShield Pro ver 5 or 6, a silent install of that application can be performed using a setup.iss file which contains information about the choices the installer should make during the install.
- When a silent setup can be performed using command-line parameters
Many applications can be installed in a silent or unattended fashion using command-line parameters. An example of this type of installation is Service Pack 1 for Windows 2000.
Note: This method does not allow for the software resiliency, remote management or removal features inherent with MSI files.
- When an updated version of the product is available
Many software manufacturers are now providing updated software in the form of an MSI product. Check for updates before repackaging an application.
Applications that should be repackaged as MSI’s
- Legacy applications
If the manufacturer doesn’t provide an MSI file or self-install capability in the install script included with the application, repackaging the application is necessary.
- When software resiliency is required
So long as a connection to the MSI install file(s) remain available to all users, applications packaged as MSI’s have the ability to perform an integrity check of the application and if necessary, restore missing files and repair damaged files, all without user or technician intervention.
- When an app installs a necessary entry in the HKCU portion of the registry
The software resiliency feature of Windows Installer can potentially eliminate the need for a login script that places registry entries into the users (HKCU) portion of the registry. This requires that all HKCU entries be contained within a single component, and that the keypath for that component be unique to this application installation.
Notes about Cross-platform compatibility with Repackaged Applications
The snapshots are not always platform-independent as are applications natively packaged as MSI files. If the repackaged application includes a service, a registry key specific to a single OS, or excludes files needed for Operating Systems other than the one used to create the package, the package will only run on the same OS as the machine where the app was packaged. In practice, MSIs which are installed on an OS other than the one used
MSI Shortcuts
As part of the self-repair features of the Windows Installer service, Shortcuts (on the desktop, within folders and on the Start Menu) that are installed as part of an MSI package aren’t really shortcuts. These links point to the cached portion of the install on the local hard drive. This cached information contains information about the keypath file or registry entry for every component contained in the installed features of an application as well as information about where to find install files should the install become damaged.
A side-effect of the special shortcuts is that the self-repair features will not work if the user launches the application by browsing for the application executable or via a shortcut to the application that isn’t a part of the MSI package.
Shortcuts created to these special shortcuts are also discouraged. If the shortcut wasn’t installed as part of the MSI application package, it cannot be repaired if the user deletes it.
If a shortcut is desired after the time of the MSI creation, a new MSI or transform (MST) file can be quickly created to apply this shortcut, and this will preserve functionality of the self-repair.
Permissions associated with MSI files
Permissions required for creation of MSI files
· Administrator permission is required on whatever machine you’re using to create the MSI file.
· Login to Client Service for Netware Networks with permissions to write to wherever you wish to store this application.
· Permissions to read the install source files (if they’re stored on a server).
Permissions required for installation of MSI files
· Users with admin permissions and read rights to the MSI files can install applications. Installs on locally managed systems (not part of a Domain) occur at the privilege of the logged-in user.
· The MSI file can be installed by a user if it has been assigned to the user or machine by a system administrator. Again, the user requires read permissions to the MSI file. In this case, the install occurs with system privilege.
· If the AlwaysInstallElevated user AND system policies have been set, users can install MSI apps. This exposes users to the same risks as email attachment viruses and defeats any and all desktop lockdown measures.
Permissions required for self-repair of MSI files
Once an application has been installed (or advertised), the self-repairing feature runs at system level, meaning that it will work for all users whether or not they’re adnimistrators. The user needs to have read permissions to the MSI install file for this to work.
From the Windows Installer Help on Privileges
How do I install a package with elevated privileges as a non-admin?
An application is called a "managed application" if elevated (system) privileges are used to install the application. There are three methods by which an administrator can enable a non-administrator user to install managed applications.
· On Windows NT 4.0 or Windows 2000, an administrator can set the AlwaysInstallElevated registry keys for both per-user and per-machine installations on the computer. Note that this method can open the computer to a security risk because once an administrator with elevated privileges has set these registry keys, non-administrator users can run installations with elevated privileges and access secure locations on the computer, such as the SystemFolder or HKLM registry key.
· On Windows NT 4.0 or Windows 2000, an administrator can install or advertise the package on the computer for a per-machine installation. The Windows Installer always has elevated privileges while doing per-machine installations. The administrator uses elevated privileges to advertise the package. If a non-administrator user then installs the application the installation can run with elevated privileges. Non-administrator users still cannot install unadvertised packages that require elevated system privileges.
· On Windows 2000, an administrator can advertise an application on a user's computer by assigning or publishing the Windows Installer package using application deployment and Group Policy. The administrator uses elevated privileges to advertise the package for per-machine. If a non-administrator user then installs the application, the installation can run with elevated privileges. Non-administrator users still cannot install unadvertised packages that require elevated system privileges.
MSI Package Validation
MSI Package Validation Overview
Microsoft strongly recommends that authors run validation on every new, or newly modified, installation package before attempting to install the package for the first time. Package validation includes the following three parts.
· Internal Validation
· String Pool Validation
· Internal Consistency Editors
Windows 2000 Logo certification
Package validation is necessary for a product to be Windows 2000 Logo certified. This is only for software manufactrers who wish to display the “Windows 2000 Certified” logo on their product and isn’t necessary for repackaged application products.
Methods of Validation
MSI packages can be validated in one of two ways – either using the command-line tool msival2 supplied with the Microsoft SDK for Windows Installer, or through the Application packaging tool used to create the MSI. The output from both will be the same.
Real-world experience with Product Validation
Due to strict Microsoft requirements for the validation process, most or all repackaged software products will have validation reports that contain errors and warnings. This doesn’t seem to be a problem – applications can fail validation and still install and function correctly. Many products by major software manufacturers that ship with MSI install files will produce hundreds of warning and error messages when validated, yet the product is still functional.
Application repackagers can ignore (most) warning and error messages contained in validation reports. However warning and/or error messages received at build-time (when the product is released as an MSI file) are a sign of a major problem with the product and an install of the product will likely fail.
Chapter 2
Using WinInstall LE to Package Applications
1) Prepare a machine with a “Clean” install of Windows 2000
Clean Installation: This typically means no applications installed or running other than Windows 2000 and the WinInstall LE application.
a) Install Windows 2000 from the Windows 2000 Pro CD.
b) Install the WinInstall LE from the source files on the Windows 2000 Pro CD (they’re in the ValueAdd/3rdParty/mgmt/winstle directory).
c) Download and install the WinInstall LE patch available from the www.veritas.com website.
d) Replace the “files.xcp” and “reg.xcp” which are located in c:\winnt with the ones available in the following location: \\umr-cc-images\images\Windows installer stuff\Veritas WinInstall LE\WinInstallLE Install Script.
e) Make a backup of this machine using Norton Ghost.
f) Reboot and login with a userID with admin rights. This should be the same userID that you used to install WinInstall LE.
2) Run the “Discover” script to image the machine before installing the application to be packaged.
a) Start the Discover application
b) Click “Next”.
c) Provide a name for the application and a name for the .msi file you want to create. This can be stored in a location on the network or in a folder you specify on the local drive. Click “Next”.
d) WinInstall LE will create a set of temporary files during the discover process. Click “Next” to allow these files to be stored on the local drive.
e) Now Windows Installer needs to know which drives you expect the application you’re installing to modify. If you’ll be installing the application to the C: drive, hilight the C: drive and click next. If you’re installing the app to a drive other than the C: drive, add the C: drive and the drive where you’ll be installing the app. Click “Next”.
f) This is a list of files to be excluded from the discover process. Make sure it contains the directories “C:\DISCOVER.WRK” and “C:\DELETED.SAV”, as well as the directory where you chose to save the .msi file.
g) Click “Next” to perform the first Snapshot of the machine.
3) Install the application you wish to package into an MSI file. If the application calls for a reboot, reboot the machine.
4) Perform any additional configuration you wish to have packaged into the install. This can include adding desktop or start menu shortcuts, choosing default settings in the application, etc.
5) Run the “Discover” process again to complete the .msi product.
a) Start the “Discover” application.
b) Choose “Perform the ‘After’ Snapshot now” and click Next. Windows Installer performs the second snapshot and creates the .msi file (and several others) in the location you specified. Note: Warnings about unavailable UNC paths and protected file replacement are common and can usually be ignored.
6) Files in the directory specified in the discovery program:
a) <Application>.msi - This is the executable file for the application you created. It does not contain files needed for the install – those are saved in a folder named for the location where the install occurred. It does contain information about the registry changes - simply altering the <application>.reg file will not change the registry changes the application makes at the time of install.
b) <Application>.NAI - This is the WinInstall script file created at the time of the discovery process. Along with the app files and registry settings, this can be used to generate an MSI file.
c) <Application>.reg - This is a reg hack containing the list of registry additions captured at the time of the discovery process.
d) <Application>.rg0 - This is a reg hack containing the list of registry deletions captured at the time of the discovery process.
e) <Application Folder> - This contains files required by the .msi file at the time the app is installed. Note: The WinInstall LE program does not have the capability of compressing these files into the .msi file, but other applications such as InstallShield Pro for Windows Installer can create a self-extracting .msi file.
7) Editing the .msi file
The .msi file sometimes captures settings that should not be distributed as a part of the application package you’re installing. These should be edited from the .msi package before distributing it to other machines.
a) Right-click the .msi file and choose “Edit with WinInstall LE”. This starts the Veritas WinConsole application and opens the msi file in this application.
b) In the top left window, highlight the highest occurrence of the application name. This will ensure that the changes you make are to the entire package and not just one of its components.
c) Choose the “Install Only Per Machine” radio button in the bottom of the right window. This will install the application for all users, not just the current user.
d) Fill in the optional info in the Summary window. This step is optional.
e) Highlight the “Files” entry in the bottom left window. This displays a list of files that the application will install. Check to be sure that there are no unnecessary files being installed by the msi file. Next click the “Remove” tab to make sure no files are being unnecessarily removed.
f) Click the “Shortcuts” entry in the bottom right panel. Delete any unnecessary shortcuts and add any additional desired shortcuts. Then click the “Remove” tab in the left window to be sure no shortcuts are being unnecessarily deleted.
g) Click “File/Save” to save the changes you’ve made so far.
h) Click the “Registry” tab in the bottom right panel. This displays a list of registry keys that are being added by the .msi file. Expand all keys and delete any entries which shouldn’t be distributed by this application, such as cache entries, McAfee keys, etc. Don’t worry if you make a mistake here, just exit the WinConsole application without saving your results.
i) Assuming that your application doesn’t require Hkey Current User registry settings, delete all HKCU reg settings. If a message appears that mentions that you’re deleting a necessary keypath, don’t delete that particular HKCU registry key. Next switch to the “Remove” tab and make sure nothing is being unnecessarily deleted from HKCU.
j) Because of a major bug in WinInstall LE, it is necessary to perform one additional step. WinInstall LE replaces some references to files in the registry with variables. These can take on the forms [!WIFILE0001], [#WIFILE00001], [WIPROD00002], etc. In the instances where it replaces something with a [#WIFILE000???] variable, it is necessary to replace that change with the actual registry entry. To do this, start at the top of the expanded registry list and look for values in the registry key that contain the [#WIFILE000???] entry. In the example shown below in figure 4, the value win32 has been replaced by a reference to [#WIFILE000000233]. To find its actual value, we need to open the <application>.reg file and browse for the value Win32 in the HKLM\Software\Microsoft\Jet\3.5\Engines\Jet 2.x key. To do this, find the <application>.reg file, right-click it and choose “Edit”. This will open the file in a text editor. Browse for the specified key and highlight and copy its value. Double-click the same value in WinConsole and paste its contents into the String field of the String Editor window that appears. Click “OK” to save this updated data value in the MSI file. Repeat this process until you’ve replaced all the occurrences of [#WIFILE00000???].
k) If you feel confident with the changes that have been made to the registry, click “File/Save” to save these changes to disk.
l) Click the “Services” tab in the bottom left window. Check to make sure that the application isn’t adding or removing unnecessary services and that they’re set to the appropriate startup values.
m) Click the “INI Edits” tab in the bottom left window. Check to make sure that the application isn’t adding or removing unnecessary INI Files (or changes to files).
n) Click the “Advertising” tab in the bottom left window. Check to make sure that the application isn’t adding or removing unnecessary Advertising. Advertising is the ability for an application to appear to be available to a user, when in fact the application hasn’t been installed yet and is set to install the first time the app is run. For applications used with the Unattended install, to maintain a base install set across multiple computers, we will assume that the MSI file will always distribute all possible components, so advertising is meaningless.
o) Click “Save” to save all changes to the MSI file to disk.
8) Save the folder of files the discover process created onto a remote server location.
9) Restore the Ghost Image of the “Clean” machine to eliminate all traces of the application.
10) Testing the MSI file:
a) Map to the server where you stored the Folder created by the discovery process.
b) Double-click the MSI file to distribute the application.
c) In most cases, it is necessary to reboot the machine after installing the application.
d) Test the application, and make any necessary changes to the MSI file to make the application perform as desired.
Advantages of WinInstall LE
- The WinInstall Console edits MSI files in their native format
It is not necessary to convert the MSI file into a project file format before editing the file, nor is it necessary to create a release version of the product after editing. This allows for much quicker edits to the MSI file.
- It’s free with every copy of Windows 2000 Professional
It’s in the \\ValueAdd\3rdParty\mgmt\winstle directory.
Disadvantages of WinInstall LE
- Software bugs
WinInstall LE should only be used for small applications, drivers, etc as the registry edits necessary for large applications can be quite tedious. When Veritas fixes this bug in their program, this may not be an issue, but for now, we recommend other application packagers (such as WinInstall 2000 or InstallShield for Windows Installer v2.0.3) for large application packaging.
- Distributions contain multiple files and folders
WinInstall LE can’t compress application files into the MSI file that it creates. WinInstall LE Console application can’t show or edit files that contain compressed application files.
· Default Exclusion files
The default registry and file exclusion files prevent creation of a driver product as well as any other application that makes use of the files and/or registry locations included in these files.
Figure 1 – The WinInstall LE Console, Summary View
Figure 2 – Console file view
Figure 3 – Console Registry View
Figure 4 – An example of a problematic registry entry
Figure 5 – The Norton Utils 2001.reg
Chapter 3
Using IPWI to Repackage an Application
The application discovery process
1) Start the process with a clean installation of Windows 2000. This means that the OS and InstallShield Pro for Windows Installer (IPWI) version 2.03 are the only products installed.
2) Run the “Spy” application. This is the IPWI equivalent of the Discover process used by WinInstall or the SnAppShot process for creating NAL objects.
3) Choose “Analyze the initial system status” to start the first snapshot process and click Next.
4) Check the “Change link analysis options” box. If you know you need to change the default file or registry exclusions, check the appropriate boxes and click Next.
5) Check the box marked “The installation to be analyzed will probably require system-level modifications.” and click Next.
6) Delete all folders listed in the “Drives/Paths:” window.
7) Click the New button and add the “C:\” path to the “Drives/Paths:” window. Click “Next”.
8) The Link Analysis box will appear. Click the “Analyze shell links” radio button and check the “Include Desktop, system folders and path list” checkbox. Click Next.
9) Click “Start” to create a snapshot of the current Windows system configuration.
10) Click “Ready” when the “Initial status analysis completed.” Window appears.
11) Install the application with the desired options. Skip the “Register the product” option if present. If possible, avoid rebooting before running the “Spy” process for the second time.
12) Configure the app by adding and/or removing any desired shortcuts. Avoid starting the application if possible.
13) Run the “Spy” application again. Choose the “Analyze system status changes.” radio button and click “Next”.
14) In the “Project path to store files to:” window, select the location the MSI file will reside (on the app install server) and click “Next”.
15) Click “Next” on the “Change Preferences” dialog box.
16) Click “Start” to begin the process of creating the second snapshot of the machine.
17) When the “New Files Found” dialog box appears, check the “Disk/CD” radio button unless the application was installed from an administrative install of the application. Click “Continue”.
18) When the “Analysis conpleted successfully!” dialog box appears, click the “Finish” button. This completes the application discovery process by copying all necessary files to the location specified during the Spy process.
19) Click “OK” twice to close the NetInstall Spy window.
Creating a release version of the MSI file
1) Rename the “Script.inc” file in the Application directory to reflect the name of the application. When the project is opened in IPWI, it will choose the name of this file as the name of the project. This needs to be as close to the name of the application as possible to make the “Add/Remove Application” process as user-friendly as possible. If you fail do do this, all applications will appear as “Script” in the Add/Remove Programs” window, making it impossible for the user to know which one to install or uninstall to add or remove the desired application.
2) Start the IPWI program. Click “File/Open” and browse for the location where you stored the application. Click “Netinstall Script / *.inc file” in the File type window and double-click the name of the
3) Choose the application directory in the “Enter the project name and location for the converted Netinstall script:” window and click “OK” to import the *.inc file into IPWI as a *.ism project file. When the line “NetInstall script conversion complete” appears, close the “Build/Validate/Results” window at the bottom of the screen.
4) Click “General Information” line. Information about the project appears.
5) Click “Project Properties”. Enter the Setup Author Name. This information is not referenced by anything other than the IPWI application.
6) Click “Summary Information Stream”. This is the information that will be displayed to end users in the Summary Panel of the setup package’s “Properties” dialog box. Enter a Title and subject information. Enter Author information and any appropriate keywords. If you wish to limit the languages and/or processor types the application supports, choose them here. Enter any comments about the application in the Comments window.
7) Click the “Windows 2000” line in the center panel.This is information provided to users in the Add/Remove Programs applet. Choose a Display Icon. Change the publisher information to reflect the contact info of the installer.
8) Click the “Product Properties” line in the center panel. Change the Destination Folder to reflect where the app will install.
9) Click “Files” under the #2 blue circle. Browse through the list and delete any files that were not intentionally included by the application install. Add any files you wish the product to install that aren’t included in the Spy discovery process.
10) Click “Shortcuts / Folders” under the #3 circle. Delete any shortcuts you do not wish for the application to install. Suggested values are any shortcut that will uninstall the application and anything that shouldn’t run from the startup folder. Add any shortcuts you want the app to install that weren’t included in the Spy process. Suggestions are a desktop shortcut – this can be deleted after installation, but can’t be (easily) added after the MSI has been generated.
11) Click the “Registry” tab. Browse the list of components looking for anything that installs an entry in HKCU or HKLM. Check to make sure that only necessary registry keys are being added when the application installs. Delete any non-essential HKCU and HKLM entries.
12) Click the “INI File Changes” tab under the #3 circle. Check to make sure that only necessary changes are made.
13) Click the “Path” tab under the Advanced Views setting. Add any necessary path variables and make sure that only necessary path additions are made.
14) If changes to components are necessary, or if you wish to add a component (perhaps one that includes a product key addition to the registry), this can be done in the Advanced Views/Components tab. Changes to resource keypaths can also be done here.
15) Advanced Views/PowerEditor can accomplish removal of files, registry settings, make deletions to ini files, etc.
16) When all changes to the release version of the product, click the Release Wizard Icon on the toolbar. Click “Next”.
17) Check the “New Product Configuration” window and enter a name for the product name. Click “Next”.
18) Click “New Release” and accept the default version of the product release. Click “Next”.
19) Click “Next” to skip the multi-lingual step.
20) Choose “Network Image” to allow the MSI file to expand to fill available space (as needed) on the application server. Click “Next”.
21) Click the “Compress all files” radio button to compress the application files into the cab file in the MSI file. Click “Next”.
22) Click “Next” at the “Setup Languages” dialog box.
23) Uncheck the “Create install launcher (Setup.exe)” box. In the “Release Location” location window, choose the folder where the application files are stored. Make sure the “Use long file names” box is checked and that all the others are unchecked. Click “Next”.
24) Click “Build” at the summary window to begin the MSI file creation process. Warch the “Build” window for error messages. When the “<Project Name>\Release 1 build completed with 0 errors, 0 warnings line appears, close the IPWI application
25) Move the files in the application directory to a folder marked “Creation files”. These are compressed into the MSI file and are therefore no longer needed. In case the MSI file doesn’t work, we’ll save these files so the Spy process doesn’t need to be run again if we need to build another release.
26) Browse for the MSI file and copy the MSI file to the application directory.
27) Uninstall the product from Windows 2000 using the Add/remove Programs feature of the control panel.
28) Reboot (if necessary) and install the product from the MSI file. Test the application to determine if it works correctly. When it does, add the wrapper files to make the product a silent install and to add registry keys necessary for login scripts.
Advantages to IPWI
· CIS experienced a higher success rate than with competing products such as Wise and WinInstall LE/2000
· Software bugs inherent in IPWI are more easily overcome than with competing products
· Industry standard packaging product, and therefore lots of support for the product.
· Excellent online documentation and help provided with the product.
Disadvantages to IPWI
· Price ($999 for a single-user license).
· Extremely complicated design interface
·
Known issues with IPWI
1) Quotation marks in target path of application shortcuts should be excluded, esp ones that reference services. Be careful that NAL objects repackaged as MSIs don’t have these quotation marks in the target paths of shortcuts.
2) (expand on the reg_sz_expand issue)
Chapter 4
Repackaging NAL objects as MSI files
Why repackage Nal objects as MSIs?
· When original application installer files are unavailable
· When significant modifications have been made to the manufacturers install
Disadvantages of repackaging NAL objects as MSI apps
· Mistakes, errors and omissions in NAL objects will also be included in the MSI product
· Modifications to the clean install test image are necessary
Procedure for repackaging NAL objects as MSI files
1) Prepare a test machine for use with your choice of application repackaging software.
2) Install the latest Novell Client 32 software on the test machine.
3) If the OS you’ll be installing on is Windows 2000, download and install the latest version of Zenworks 3, then run the NALEXPLD.EXE file to start Application Explorer. If the OS is other than Win2000, skip to the next step.
4) Login to W
