set fixed msi product id?

[ttcn2k4]

Hi:

Is there any way to set a fixed Product ID for msi (as we did for exe)? or is there any way that we can get the msi product id from IA (not using orca)?

I post this question because (as I mentioned in my other post) my setup always creates 2 registry keys with different uninstall string:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{msi product id}
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Product_Title

and only the one with Product_Title is removed when uninstall (since it's showed up in ARP). The msi product id is always stayed there, which pollutes the registry key since we have newer version every week. Also, I read in previous posts, search in registry is not "possible in a straight forward way".

Thanks
Nhan

[FrancescoT]

Dear Nhan,

I am not quite shure if this could help, but sometime ago I was facing with a similar issue in one of my project and I solved in the following way.

Could it helps you?

I have added the following code in Install setup pre-requisites, in the "if Variable PREREQ not Equals FALSE" and just before of "Install/Remove MSI Package $PRODUCTCODE$[REMOVE=ALL] (get result into variable REMOVEOLD)"


Comment: Removes prevoius application version entry in ADD REMOVE list
Set Variable OLDAPPTITLE to
Read Registry Key HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$PRODUCTCODE$\DisplayName into OLDAPPTITLE
Delete Registry KEY HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\$OLDAPPTITLE$\*.*

Let me know

[ttcn2k4]

Hi Francesco:

Thanks for the reply. However, I don't see it applies for my case. I meant the "msi product id" that IA create when I use Group Policy. Not a third party msi product id.

IA always assigns new product id for the msi it creates and for that reason, I have problem to locate it for uninstall.

Thanks
Nhan

[FrancescoT]

Let me check.

[FrancescoT]

Dear Nhan,

I have checked carefully the registry keys as you reported.
To do this I have just replicated on a test machine, an Install of an msi setup generated via Group Policy.

Finally, as you told the reg keys are created twice. For what I see, seems that the msi requires an extra key to complete successfully.
I have also tested any relation between those keys, but I have not found any.

I am not quite shure if it is Group Policy that create those double key or it is a thing related to msi creation excution itself.
Really I do not know.

I will check with dev team .... and I will tell you.

Regards

[ttcn2k4]

Thanks Francesco. Appreciate your help.

Could you please also ask them if there is any way I can set a fixed key for the msi product id? Since we could not search registry for that easily, it would help us a lot.

Thanks
Nhan

[FrancescoT]

Dear Nhan,

I will do it.

Anyway I am already waitng for an aswer.

Thanks

[ttcn2k4]

Hi Francesco:

Just wonder if you hear anything from your developpers?

I really get stuck here. We want to remove the "change" option in the ARP (add/remove program) and since we use silent installation for our msi, we have to add the "no modify" value to the uninstall registry key that uses the msi product code ... and since the product code is dynamic, no hand-on search option from IA nor reg.exe, I have to give up. I don't want to blow the whole registry away by using scripts or so ... too risky for a small change. Thus, I really hope IA can do something.

Thanks
Nhan

[FrancescoT]

Dear Nhan,

please excuse me for the delay!!

This is the answer I received;

There is no way to change the Product ID at runtime, to answer that part of the customer question. The value is burned into the MSI database. Transform Instance could be used though, but that is for multiple instance support.

However, these IDs MUST remain distinct, otherwise things will break. The Group Policy MSI MUST have a different GUID compared to the main InstallAware setup MSI. Otherwise, deployment will fail. The two values have to be different for both distinct packages to be recognized as such by the system.

Last but not least, if they right-click the MSI file and choose Uninstall, the ID they notice which pollutes the registry will be removed as well. I suspect it is remaining only because the uninstallation is being done by the setup.exe file which does not remove the Group Policy MSI ID.

Of course, with actual Group Policy MSI deployment, the uninstallation would actually be done by the Group Policy MSI - so this would not be an issue.

Hope this helps you.

Regards

[ttcn2k4]

Thanks Francesco. However, I don't quite get it, esp. the phrase "Of course, with actual Group Policy MSI deployment, the uninstallation would actually be done by the Group Policy MSI - so this would not be an issue."

According to that phrase, the uninstallation should be done by the Group Policy msi. Is there anyway that we have to configure it?

We use all defaults, ie. after compiling as single file, we create the msi using the Group Policy GUI, then double click the newly-created msi to install, then go to "Program and Features" to perform uninstallation. I don't think we instruct the uninstallation to be done by the setup.exe or Group Policy msi. (We don't know how!).

We never "right-click the MSI file and choose Uninstall" either. The first time I hear about it.

Also, since we could not set a fixed product ID for msi, we'll never be able to manipulate the appearence of the buttons (uninstall, change, ...) in ARP if we use the command "msiexec /i myProduct.msi /quiet", right?

Thanks
Nhan

[FrancescoT]

Dear Nhan,

refering to : "the uninstallation should be done by the Group Policy msi"
This is basically refered to Group Policy installation, using Actìve Directory to distribute software packages with a server on a domain.

Anyway I really think that you should be able to run the msi as follow:

- msiexec /i <msi> /quiet (install)
- msiexec /uninstall <msi> /quiet (uninstall)

Note that not all the switchs available with msiexec can be used with msi produced by InstallAware. This due the complete customization of command line parameters offered by InstallAware. The first that I recall it is: /a .

Regards

[ttcn2k4]

yes, we use those msiexec commands without any problem:

- msiexec /i <msi> /quiet (install)
- msiexec /x <msi> /quiet (uninstall)

The problems are with the registry keys used for uninstallation.

1) Because InstallAware changes the msi product code everytime we use the Group Policy to create a new msi, we could not do anything that is required a modification in the registry key (such as removing the "change" button in ARP, ...".

2) If we don't use the command to install, we double click on the msi file to install, there is an extra key for uninstall (which didn't exist if we use the msiexec command) - to serve the same purpose:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{msi product id}
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall\Product_Title

I haven't received the answer why there are 2 keys created for the same purpose and only one of them get removed during the uninstallation. And unfortunately, the one left behind is the one using "the msi product id", thus, again, due to its random value, we cannot explicitely add a command to remove it.

Thanks
Nhan

[FrancescoT]

Dear Nhan,

I have tested it and if you right-click the MSI file and choose Uninstall, the ID which pollutes the registry will be removed as well.
For what I know, it should be the same of using "msiexec /x <msi> /quiet (uninstall)"

I haven't received the answer why there are 2 keys created for the same purpose and only one of them get removed during the uninstallation. And unfortunately, the one left behind is the one using "the msi product id", thus, again, due to its random value, we cannot explicitely add a command to remove it.

You should have already received an answer in my previous post, anyway:

The Group Policy MSI MUST have a different GUID compared to the main InstallAware setup MSI. Otherwise, deployment will fail. The two values have to be different for both distinct packages to be recognized as such by the system.

Because of internal MSI install rules using an MSI setup file there no way to override this.

Then using the unistall command from ARP will execute the cached setup source of your install, that it is not anymore an MSI file, that's the reason why the MSI generated REG KEY it is not removed.

Regards

[ttcn2k4]

Thanks. I got it now. I will advise users not to do the uninstall from ARP to avoid left-over keys.

Hope that you can find a way to allow us set fixed product id for msi once day.

Nhan

[FrancescoT]