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


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

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

WiseUser | 26 Oct 2007 | 0 comments

Bootstrapping is nothing but a process. Until the Windows Installer Service is pervasive, any software that depends on the Windows Installer being present must first ensure that the Installer is in fact present. Here's some background and the logic behind the launch sequence.

  1. User launches setup.exe to begin a new installation.
  2. The setup.exe program checks to see whether the Windows Installer Service is present. If it is, the program skips to step 6. Note that if the program is running on Windows 2000, the Windows Installer Service will always be present because it's installed as part of the operating system.
  3. The setup.exe program determines what platform is being used.
  4. If the platform is Windows 95 or Windows 98, setup.exe launches the ANSI version of InstMsi.exe to install the Windows Installer.
  5. If...
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.

WiseUser | 25 Oct 2007 | 4 comments

A Windows Installer Transform (.mst) contains a set of alterations to a Windows installer package (.msi). In order to correctly view the changes a transform makes, the .msi package that served as the 'original' should be used as the base package. Read on to learn what the MST viewer is and how to get some mileage out of it.

The MST File Viewer is automatically installed on your computer when you install the Office Resource Kit (orktools.exe).

The MST File Viewer (MSTView.exe) enables you to view customizations a transform (MST file) makes to a user's computer. Transforms are created by using the Custom Installation Wizard.

To use the MST File Viewer, you must supply it with the path and file name of the MST file you created with the Custom Installation Wizard. The MST File Viewer is not a separate application — instead, it reads the MST file and creates a plain-text file containing readable content. The information is then displayed through the Notepad text...