Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.
Endpoint Management Community Blog
Showing posts tagged with Basics
Showing posts in English
R-Vijay | 13 Nov 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:

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

  1. Install Captured MSI of the Application on your system.
  2. RUN Setup Capture and take the SnapShot.
  3. Install Source Application over it.
  4. 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...

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 key file is on...

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.


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.


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

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...

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...

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:

  1. The file must have a internally provided checksum provided. This is done at compile...
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:

  1. 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.
  2. 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:

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

Both of these approaches will leave the...

BRING | 29 Oct 2007 | 1 comment

We all know that there are big Software Delivery packages in the world. We also know that sometimes network infrastructure lets us down. So what do you do when you have this monster of a software delivery package to get to clients, and the network hiccups in the middle. Well ... it depends!


Is there anyway to get Software Delivery to resume a package download from an intermediate state, rather than restarting the package download over completely, when the package delivery mechanism is UNC? What about HTTP?


If you are using UNC, then the bad news is NO. This is called package checksumming and Checksums are only available via HTTP downloads, not UNC. There are two other things to note here.

  1. Once a solid network connection is restored,if your package contains multiple files, the download will resume at the end of the last file successfully delivered, but only via HTTP. This is not supported on UNC deliveries.
  2. ...
R-Vijay | 26 Oct 2007 | 0 comments

This technique can be used when more than one version of a component needs to exist on a workstation and the two components are binary compatible.

In this case, one of the components can be placed in the same directory as the application, and a file created with the same name as the application executable, with an extension .LOCAL. Then the local component will be used by preference by this application (other applications will use the non-local component, or their own local components).

Because the same registry entries are used for both copies of the component, the components need to be binary compatible for this to work. Hence these registry entried components are given a shared count under properties.

This technique should be used only as a last option when the conflict management techniques does not resolve a problem.