1 reply to this topic

[EricPhx]

Background:

A few years ago, we built an MSI using InstallShield (a version previous to InstallShield Developer 2008) that utilized the MSXML 3 merge module
--This MSI did not have the ALLUSERS flag defined (as was default behaviour in basic msi’s created through older InstallShield versions), but the MSXML 3 merge module installed its COM registration settings to HKLM
--From our investigation, we understand that in the absence of this flag, it behaves as a per user installation

We now have built an MSI using InstallShield 2010 that is configured to perform a major upgrade of the original MSI (complete uninstall)
--This MSI now uses the MSXML 4 merge module
--This MSI has the ALLUSERS flag set to 1 so that the MSXML 4 merge module COM registration settings are installed to HKLM

The new MSI works well when:
--Used as an initial install
--Used as an upgrade install when the install is performed interactively (i.e.: not silently)

Problem
When we silently install our new MSI (eg by calling: msiexec /i "msi name" /q /l*v logname.log) on a machine that has the previous MSI installed, the MSXML 4 merge module COM registration settings are installed to HKCU instead of HKLM (we need these COM registration settings written to HKLM)
-It appears that when a silent install is performed, the original MSI’s ALLUSERS default value (for current user) is used instead of the value in the new MSI (for all users)

Question
What is the best way, for a silent upgrade, to get the MSXML 4 merge module’s COM registration settings written to HKLM?

[Stefan Krueger]

A major upgrade cannot switch from a per-user to a per-machine (ALLUSERS=1) installation. Therefore InstallShield includes a custom action that will read the ALLUSERS value from the existing install and set it to the same value in the new install. So I would expect that this will never work, not even in interactive mode.