InstallAware

Hi guys,

Hoping someone can help with an issue I'm facing with one of our MSI installs. Please excuse the log description below, but I wanted to try and get all the background information down.

We have an install written in IA9 (I know this is an old version but until now its always worked so there was no need to upgrade). For every new version we release we rebuild the install with the same Product code and a different revision code. When we run the newly built install it detects the old version, removes it and installs the new version. This has been working for a while with no problems.

However we have a customer who is now having issues. They are on version 5 of our product and want to update to version 12, however they want to be able to "roll-back" to version 5 if something goes wrong. They have 100+ machines to install and are unable to take an image of the version 5 before they upgrade. We tested this in our environment - you run version 12 of the install, it detects version 5 is installed, removes it and then installs version 12. We then tested the rollback - ran version 5 install, it detects version 12, removes it and installs version 5. Everything worked perfectly. However at the customer site it did not go smoothly.


Version 5 installed
Ran version 12 install and machine is upgraded as expected
Ran Version 5 - install fails with error about unable to install MSXML42 Application Runtime (1 both the original V5 and the new V12 both had this Application Runtime and installed with no problems - so no idea why this is now throwing an error)

So - we rebuilt the version 5 install without the MSXML42 Application Runtime and gave this to the customer - they then start getting errors about unable to register files. We then told the customer to remove the install altogether and we will install from scratch again. However they were unable to uninstall correctly (I don't know exactly what went wrong here). The customers machine was now left in a state where they couldn't install or remove using the MSI files.


So - I had to write a program that went through the registry and deleted all the registry keys for the MSI's - this is what I have deleted:

For every revision of the install I deleted:

HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Installer\\UserData\\<user-id>\\Products\\<revision-code-id>
HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Installer\\UpgradeCodes\\<upgrade-code-id>
HKLM\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\<un-install-code-id>

HKU\\<user-id>\\Software\\Microsoft\\Installer\\Features\\<revision-code-id>
HKU\\<user-id>\\Software\\Microsoft\\Installer\\Products\\<revision-code-id>
HKU\\<user-id>\\Software\\Microsoft\\Installer\\UpgradeCodes\\<upgrade-code-id>



I then also deleted the following for the main product:

HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Installer\\UserData\\<user-id>\\Products\\<main-product-code-id>
HKLM\\SOFTWARE\\Wow6432Node\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\<main-product-un-install-code-id>
HKU\\<user-id>\\Software\\Microsoft\\Installer\\Features\\<main-product-code-id>
HKU\\<user-id>\\Software\\Microsoft\\Installer\\Products\\<main-product-code-id>

I then looped through all the keys under:

HKLM\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Installer\\UserData\\<user-id>\\Components

If they had the value name <main-product-un-install-code-id> then the component was deleted


HKU\\<user-id>\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\<product-name>
HKU\\<user-id>\\Software\\Microsoft\\Windows\\CurrentVersion\\Uninstall\\<main-product-un-install-code-id>
HKU\\<user-id>\\MimarSinan\\InstallAware\\Ident.Cache\\<main-product-un-install-code-id>



On our test environments this wiped the installs from our machines are we were able to re-install any version we wanted as a new install.

The customer ran this on their machine and it appeared to wipe the installs from the machine. They could now run the version 5 install and the program reacted as if it was a new install (asked all the questions it needed to ask that the upgrades do not ask). However when it tried to Apply the Install it gives the following error:

Error 1316. The specified user already exists.


I believe we are getting this error because there is something in the registry we haven't removed or some files on the machine. Does anyone have any ideas?


Many thanks in advance

Paul

Dear Paul,

for what you are reporting, the problem seems to be caused by a system issue and for what I understand, this seems to be replicable with a single machine only.

As first, you may try to use the "Microsoft FixIT tool".
http://support.microsoft.com/fixit/en-us

It's an on-line service tool that addresses a wide range of system issues. I used the same in the past and in most cases, I was able to fix Windows installer engine issues very similar to the one you are having.

For what concerns the "1316" error, this should refer to a network issue.
https://msdn.microsoft.com/en-us/library/windows/desktop/aa372835(v=vs.85).aspx

Regards

Thanks Francesco - I'll ask the customer to run the FixIT Tool on their server.

Can I ask a question or two regarding the MSI and the install keys in the registry - the more I've been looking at this problem the more I'm understanding

My understanding is:

When you build a compressed setup you get a MSI wrapped in an exe.
When you use the Group Policy tool you end up with the original product MSI compressed inside a wrapper MSI.
When you run the MSI it unpacks the original product MSI and then runs that.

When I look in the registry I can see multiple keys in the Uninstall key - 1 for the product and another one which is the packed GUID for what I think is the wrapper MSI. When I do a new build and install it I then have 3 keys - 1 for the product, 1 for the initial wrapper MSI and 1 for the new wrapper MSI.

When I do an uninstall using the shortcut on the start menu (START -> Programs -> Product -> Uninstall Product) it removes the product uninstall key but leaves behind the wrapper keys as these were actually created by a different MSI

Is my understanding correct? I want to understand as much as I can so I can change our un-install program incase this happens again.

Thanks,

Paul

Dear Paul,

that GUID is generated by the MSI automatically and it's not possible to skip this behavior, unless you decide to distribute a compressed EXE.

Anyway, that key left under registry doesn't cause any problem.

Regards

FIxIT Tool failed with an error that points to corrupt registry keys

I am getting access to another server that has similar problems with installation / uninstallation that hopefully I can figure out - this had different errors when trying to install that we've not been able to replicate in our environment.

Expect some more questions

Paul