Endpoint Management Community Blog

R-Vijay | 03 Dec 2007 | 5 comments

This tip will (hopefully) shine some light on the concept of performing a "Gap Capture".

Let's start with a simple equation:
GAP CAPTURE = SOURCE APPLICATION - CAPTURED MSI.

So, basically, a Gap Capture is the difference between a Source Application and Captured MSI.

When do we do This?

You have done the setup capture but your MSI fails in Functionality Testing. One reason could be that some files or registry is missing in your package.

To capture the LEFT OUT entries, we need to do GAP capture.

How to do Perform a Cap Capture

Install Captured MSI of the Application on your system.
RUN Setup Capture and take the SnapShot.
Install Source Application over it.
Now finish the Capture (SnapShot of OS+MSI+Source Application)

What you've captured in the WSI is now a GAP Capture.

How to go About with These Entries

First re-build the machine and install your earlier...

Removing Files that Remain After Un-Installation

R-Vijay | 12 Nov 2007 | 7 comments

If a file that should have been removed from the user's computer remains installed after running an uninstall, the installer may not be removing the component containing the file for one or more of the following reasons:

The msidbComponentAttributesPermanent bit was set for the component in the Attributes column of the Component table.
No value was entered for the component in the ComponentId column of the Component table.
The component is used by another application or feature that is still installed.
The key file for the component has a previous reference count under HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDlls.
The component is installed in the System folder and any file in the component has a previous reference count under HKLM\Software\Microsoft\Windows\CurrentVersion\SharedDlls.

The installer does not remove any files that are on the Windows File Protection (WFP) list. If a component's...

"Files in Use" and "Restart Manager"

R-Vijay | 09 Nov 2007 | 0 comments

Files in Use and Restart manager are two big features of Windows Installer 4. These features provide excellent support to MSI packagers when customizing an application which needs a restart for optimal functionality.

Files in Use:

Files-In-Use functionality is among the countless services that Windows Installer exposes for setup authors to leverage for their application install/maintenance. This functionality lets setup authors display the processes that hold on to files that would be updated by this install. The user would want to shut those processes before continuing with the install to ensure that the install wouldn't require a reboot.

The current Files-In-Use mechanism involves enumeration of the HKEY_PERFORMANCE_DATA key using registry API for information on processes and the PE images that they have held in-use. This works well in scenarios where the process holding the file in use has a visible window that the user can shut down.

These...

Troubleshooting MSIs Using the Log File

R-Vijay | 07 Nov 2007 | 0 comments

When a vendor MSI installation fails on deployment, many a times it may be because of the Custom action present in it. Here are some steps to take if you suspect your failure is related to such an action.

Generate the MSI log and search for RETURN VALUE 3. This will identify the problem in some cases.

Further, the possible Return Values for CAs are:

0 Action not invoked; most likely does not exist.
1 Completed actions successfully.
2 User terminated prematurely.
3 Unrecoverable error occurred.
4 Sequence suspended, to be resumed later.

If there is a problem still with advertising a package then check the property ProductState in the log file.

The ProductState property can be any of these values:

-1 The product is neither advertised or installed
1 The product is advertised but not installed
2 The product is installed for a different user
5 The product is installed for the current user.

...

Sequence in Which Windows Installer Evaluates Properties

WiseUser | 02 Nov 2007 | 1 comment

You've heard the adage that "timing is everything". With application packaging, timing (or the sequence of events) really is everything. If you're having trouble with a package the problem might be related to conflicts caused by the order of events. He're a quick reference to help you stay in step.

ADDLOCAL
REMOVE
ADDSOURCE
ADDDEFAULT
REINSTALL
ADVERTISE
COMPADDLOCAL
COMPADDSOURCE
FILEADDLOCAL
FILEADDSOURCE
FILEADDDEFAULT

Remember too that feature names listed in properties are case-sensitive.

Source Resiliency, A.K.A. Package Self-Repair

R-Vijay | 01 Nov 2007 | 5 comments

Software packages should not automatically repair data (local- or server-based data) on launch. Such an automatic repair could overwrite data changes made by the user. Therefore, components in the MSI that include data files (e.g. Access MDBs) will not contain a key path (thus disabling self-repair), even if this breaks the Windows logo.

The Self-repair (Source Resiliency) process will be reserved to repairing locally installed application executables, registry keys, shortcuts and system files. The package will never be able to repair to a server path (since the application is Run from Source and it is read-only), and under no circumstance should the package repair Data (User or Shared) even if the data resides locally.

In order to support roaming users or more specifically, multiple users using the same application on the same workstation, user data needs to be installed for each user using the application on the workstation.

In order to do this, a HKCU key...

Merge Modules: A Little Background, Please

WiseUser | 01 Nov 2007 | 0 comments

Merge modules provide a standard method by which developers deliver shared Windows Installer components and setup logic to their applications. Merge modules are used to deliver shared code, files, resources, registry entries, and setup logic to applications as a single compound file. Read on to learn more.

About Merge Modules

A merge module is similar in structure to a simplified Windows Installer .msi file. However, a merge module cannot be installed alone, it must be merged into an installation package using a merge tool.When a merge module is merged into the .msi file of an application, all the information and resources required to install the components delivered by the merge module are incorporated into the application's .msi file.

Merge modules are essentially simplified .msi files, which is the file name extension for a Windows® Installer installation package. A standard merge module has an .msm file name extension.

A merge module cannot be...

Can a corrupted file be repaired by the Windows Installer?

WiseUser | 31 Oct 2007 | 0 comments

A corrupt file will not trigger Windows Installer to perform a self-repair. This is because the Windows Installer checks only for file existence when checking a component that uses a file for its keypath. Read on to learn more.

Although a corrupted file may not function properly, as long as Windows Installer can verify that the file exists at that location a self-repair will not be triggered. However, if another missing keypath causes a self-repair the corrupted file will be replaced with a functioning copy from the installation source if the file is in the same feature as the component with the missing keypath.

Corrupted files can be repaired by performing a manual repair of the .MSI using the maintenance dialog or by running the MSI via command line with the switch /focmus. Additionally, the following information must be true for the repair to correct the corrupt file:

The file must have a internally provided checksum provided. This is...

Initiating Self-Repair and Advertising Features with Entry Point

WiseUser | 31 Oct 2007 | 0 comments

With Microsoft Windows Installer, an application's entry points play a major role in installing advertised features and initiating the self repair of an application. When a user uses an entry point to launch an .MSI-based application, Windows Installer performs an integrity check by verifying:

All key paths (files or registry entries).
All a feature's components where the entry point resides.
The components of all features in parent-child relationship.

Application entry points are generally one of the following:

COM Activation

Internal components, known as COM objects, in COM applications can be shared and used by other applications. Example of a COM application: Macromedia Flash plug-in for a Web browser.

Advertised Shortcut

These are shortcuts for an uninstalled application and generally do not have configurable properties when viewed. If the shortcut has a Target Type of Application, rather than the ....

How to Prevent Windows Installer From Removing a File on Uninstall

WiseUser | 30 Oct 2007 | 5 comments

Here are a couple of approaches that'll keep that pesky Windows Installer away from files you don't want uninstalled when an uninstall script is run. Hope you find this info useful.

To modify the Component Table, follow these steps:

Select the Component Table from the Tables tab in Setup Editor, and highlight the Attributes column of the component that is to be left on the machine during the uninstall.
Change the value in the Attributes column to 16 for the component to keep during the uninstall. Press the Tab key to update the field.

To modify the Component details, follow these steps:

Determine which component contains the file in question; go to the Setup Editor and click on the Components tab.
Locate the appropriate component, right-click on it and select Details.
In the Component Details dialog mark the "Leave installed on uninstall" check box.

Both of...