WiX MSI behaves differently before and after removing CRT MSM

Question

I've got an MSI built with WiX. It performs the following custom action:

     <CustomAction Id='StartTray'
                   Directory='INSTALLDIR'
                   ExeCommand='[INSTALLDIR]\myapptray.exe'
                   Return='asyncNoWait'
                   Impersonate='no'
                   Execute='deferred' />

It is scheduled like so:

        <Custom Action='StartTray' After='StartServices'>NOT Installed OR (TRAYWASRUNNING AND NOT REMOVE~="ALL")</Custom>

myapptray.exe happens to use impersonation to relaunch itself from its starting context of Local System (running from MSI context) as the user currently active on the desktop. This is not in my control and Impersonate='yes' does not work because the MSI may be invoked for an upgrade from the context of the system service, meaning Impersonate='yes' would still end up running the app as Local System.

I recently moved from including the VC9 CRT as a MSM in this MSI, to including it in a bootstrapper exe.

Doing this prevents the myapptray.exe custom action from running successfully. The impersonation fails in WTSQueryUserToken which returns ERROR_PRIVILEGE_NOT_HELD. This seems to imply that removing the MSM actually changed the user context in which the MSI runs, but that seems ridiculous. The only lines I removed from the wxs file are the <Merge> and <MergeRef> tags for the MSM, nothing else has changed.

What am I doing wrong?

Answer 1

I figured it out.

The CRT MSM was setting ALLUSERS=1 and the installer's behavior changed because it was not present in our base installer. The MSM's setting of ALLUSERS was inherited into the base installer as a result.

Setting ALLUSERS=1 in our wxs file fixed the problem!

Answer 2

I'd look more at what versions of the CRT your EXE was built against and if there are any policy rules saying what it can run against. Moving from an MSM to an EXE run before your MSI should generally be a good thing.

BTW, I did something really hacking like this once upon a time. We had to push an MSI out under the SYSTEM context using MSI. If a user was logged on we had to relaunch the application using the users desktop login session. I had a DCOM server installed configured to impersonate the interactive user to accomplish this. Really wierd, but there was a valid reason.

This was all before Restart Manager though.