InstallAware

Hello,

I'm having issues with configuring an .msi installation that should be used for packaging and deployment by SCCM.

The main issue is that the reinstallation of the package is currently not possible without fiddling with the registry. From what I found, when SCCM installs this .msi, two keys get created under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\[user sid]\Products\. The two keys there are both guids, both have been altered from their original versions, from 12345678-1234-1234-123456789ABC to 87654321-4321-4321-2143-21436587A9CB. I'm sad to say I do not understand why that is, but it's probably not important right now.
The original guids are the ProductCode as defined in InstallAware, and a random guid that gets embedded into the .msi as a different ProductCode in the Property table and that I can find using Orca (or even by just opening the .msi in notepad++ as plain text somewhere between all the binary data).
I've tested this kind of installation with some other products and my installation is one of the few that get registered in this way, and the only one that does so twice.

On an uninstallation, only the first key gets removed, the other, outer .msi ProductKey remains unchanged. Since SCCM seems to use these keys as a register of installed products, it will actively refuse to reinstall the package again while the outer .msi key exists. I have so far found no way to influence this behaviour, much less actually enabled the installation again. (without manually deleting the key or building a new .msi package)
Are there any pre-defined variables I'm missing, command line arguments that should be added or anything that would change this behaviour?

The .msi is currently created using the pgplwiz.exe (with the ALLUSERS=TRUE addition to the command line) because we still want the .exe in addition to the new .msi. I have tried using the Native Engine and building an .msi output from InstallAware directly, but I haven't noticed any significant changes regarding this behaviour (building the .msi directly does embed the correct Property,Manufacturer data in the .msi, there are a few more subtle changes, but that's about it).

Dear tkunaj,

Which IA version are you using?
http://www.installaware.com/forum/viewtopic.php?f=2&t=9316

if you are referring to the MSI product-code that gets generated at setup Runtime when running an msi install, this value is dynamically generated by the MSI engine directly and cannot be defined ... it's a random value generated at Runtime.

Anyway for what I know, this should not cause any problem when installing with SCCM.

Regards

I'm not at my work computer right now so I can't be 100% sure about the exact version, but it should be the newest one or very close to it.

I am aware that the secondary product code is random.
Strictly speaking, yes, the secondary guid is not a problem on it's own when installing with SCCM. The issue I'm having is that I do not seem to be able to remove all the registry keys the SCCM and .msi package create during the deployment with a simple uninstall.
The user on the linked thread has been using the psexec command, which I have not thought to do. That's something I could look into and maybe test tomorrow.

I've been playing quite a bit these past few days with the .msi installation, logs, deployment, etc. and wanted to update this post with some information I've gathered (mostly through trial and error). Since there is very little info around on how InstallAware packages work with SCCM, I'm hoping it might help someone in the future who'll have similar headaches:


Firstly, the solution to my original problem posted here, not being able to fully uninstall the application and therefore unable to reinstall it using SCCM. Software Center will be able to fully uninstall both .msi's. It's not a great solution since it adds another unnecessary action to remember for any user deploying via SCCM, but it works reliably.

In case the user uninstalls the application using the Control Panel or whatever else, he'll nevertheless need to run the uninstall from Software Center to be able to reinstall the same package again with SCCM. The process will be odd because the first .msi will run the uninstall normally, the second (of the actual application) will be started without having anything to uninstall, so errors are possible.

In case the user wants to upgrade the installed application, the outer .msi won't be touched, the inner one (the actual application) will get upgraded. Both entries will be visible in the Software Center.
I would propose that in the case of upgrades, users uninstall the old version themselves before installing the new one, because it might get confusing to have multiple application of the same type marked as installed on the machine. It might get even more so if the user for some reason decides to use Software Center to uninstall the old version. If it's anything like mine, it will attempt to upgrade the existing installation again because of the different rev number, only in this case downgrading the current installation.
This will mostly result in various kinds of messes that I know to expect as a result of testing this behaviour.

One other thing that I wanted to mention: a faulty command line I've found on these forums while researching everything SCCM and MSI related, and that has never been corrected anywhere to my knowledge. To install the application for all users using the .msi: The ALLUSERS=TRUE in this command is a flag that will be set to the outer .msi and will not be propagated to the inner .msi (although /quiet or /qn will). This makes the flag useless for most purposes, as you usually want the application to be installed for all users. Settings the command line with pgplwiz will also not be of much use. The correct form is This is true for the current X3 version, possibly for earlier versions as well. You can force the outer .msi with ALLUSERS=TRUE, but since it is invisible to users, it doesn't really matter, Software Center will not be able to see the outer .msi when viewed with a different user in either case.