InstallAware

This is sort of long, but hopefully somebody can shed some light...

Does anybody know how I can determine programmatically whether my app was installed using the compressed .exe or if it was installed using an MSI created by the Group Policy Wizard?

I'm having trouble removing the previous version during an upgrade if it was installed using the GP MSI, because it looks like the add/remove programs information for my product is different if I install using an MSI created with the Group Policy Wizard than if I install using the compressed setup EXE. This is because the ARP registry information is different between the two.

If I install using the EXE, I get two registry keys full of info:
I'm not sure why there are two entries, and I can't tell which ARP is using. My installer adds NoModify, NoRemove, and NoRepair values to the $TITLE$ key, but these values show up in the $PRODUCTCODE$ one as well even though I'm not putting them there specifically.

When performing an upgrade, I read the value
into a variable, $OLDINSTALLER$, then uninstall the old one during prerequisite processing by calling:
This works great, but if the old version was installed with the MSI from Group Policy, $OLDINSTALLER$ is blank. This is because that registry value does not exist. Instead, if I install using the Group Policy MSI, I get the two registry keys mentioned above as well as a third:
In this case, the only registry key under "Uninstall" that has an "UninstallString" value for my product is the third one with a GUID that means nothing in the context of my project. Furthermore, this UninstallString is an msiexec call to uninstall the GUID that has nothing to do with my application and not the setup.exe file that was archived for later uninstallation.

I guess the simple way of summing all this up with by asking, "How can I programmatically uninstall my application if it was installed using a Group Policy MSI?"

Thanks for reading!

The UninstallString should not be empty for the uninstall entry under $TITLE$. Did you check both the current user and local machine registry keys? In fact, since the install might have happened under another account, you should check all keys with $TITLE$ to see if you can get to the bottom of this one.

Thanks for replying, Michael.

If I install using the compressed EXE, there are no entries under HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall for my product - neither by $PRODUCTCODE$ nor by $TITILE$. But if I install using the GP MSI, two keys are added there for my product, one for $PRODUCTCODE$, one for $TITLE$, and they both have UninstallString values.

So I think the solution to my problem is to look for the UninstallString in HKLM first, but if I don't find it there, then enumerate through the entries under HKEY_USERS until I do find it. If the installer is being run by an admin, this should work.

Hi again, Michael. Here is what I have discovered. The built-in variable, ALLUSERS, seems to be set to the wrong value when the installer is wrapped in an MSI using the Group Policy Wizard. If I install my setup EXE, ALLUSERS=TRUE when I check it at the start of my MSIcode. But if I install the MSI generated from running the Group Policy Wizard on that same setup EXE, ALLUSERS=FALSE when I check it at the same place in the MSIcode.

According to the "Pre-Defined Variables" section of the InstallAware help, ALLUSERS is "Initially TRUE if platform is NT, FALSE if not." I am running on XP (NT 5.1) and have found that ALLUSERS is initially TRUE if I run the EXE, but initially FALSE if I run the GP MSI.

I think this is a bug in the Group Policy Wizard. When I started my project, in the new project wizard I told it not to allow the user the option to install for "just me." I want it to always install for all users. It works great, until I use the Group Policy Wizard to wrap the setup in an MSI, then it defaults to install for the current user. This is why UninstallString was blank under HKLM, as I mentioned in the first post of this thread.

I can work around this issue by hard-coding ALLUSERS=TRUE at the start of my MSICode script, but I do think it is a bug in the Group Policy Wizard. Also, it looks like it's been discussed or mentioned before:

http://installaware.com/forum/viewtopic.php?t=2622

http://installaware.com/forum/viewtopic.php?t=3354

http://installaware.com/forum/viewtopic.php?t=3303

http://installaware.com/forum/viewtopic.php?t=3043

http://installaware.com/forum/viewtopic.php?t=2631

I do hope this can be fixed in a future release, but for now I just wanted to document my findings here for posterity. I'm sure others will run into the same issue.

Actually, this is not a bug, but a feature

When parameters are set from the command line, they cannot be overridden in MSIcode. And the Group Policy Wizard sets the ALLUSERS variable on the command line as a feature.

How does it set this variable? It reads the ALLUSERS property in the Group Policy Wizard generated MSI file, and then accordingly sets the ALLUSERS command line parameter in the InstallAware installer.

So actually, this really is not a bug, but the Group Policy Wizard generated MSI is really passing forward the actual property passed into it verbatim into the InstallAware setup contained within.

Thanks for clarifying, Michael. I figured that was what was happening, but...

If the default value for ALLUSERS is TRUE, and if the GP Wizard doesn't give an explicit input option for changing this value save for the "Command Line Parameters" field, doesn't it follow that if I do not specify ALLUSERS=FALSE in the command line params then it should maintain the default value of TRUE? I feel the default should not flip to the opposite value unless I specify for it to do so.

I'm not asking you to defend this design decision here on the forum, only that you pass this along to product management (or whomever) to consider for a future release. To me, as a developer, this seems to be broken by design.

I appreciate your feedback. The default is indeed true, but the GP MSI is reading the actual value at runtime as set by the Group Policy/Active Directory deployment tool. So it is being explicitly set to false!

Older versions of the GP wizard only permitted setting this from the command line whereas newer versions make this redundant by automatically reading the property from the GP MSI so software that set it work seamlessly.

That looks like better by design to me, but you can certainly continue this discussion and make a case for your perspective, R&D might roll back these changes in light of how convincing your information is.