Upgraded Installer Package doesn't uninstall correctly

[vault]

Hi AI,

I have an installer created from an Advanced Installer 9.9 project file (64-bit AMD64; Requires Elevated privileges; Single MSI output) that was upgraded to AI 22.

Took a little bit of tweaking, but everything now builds and I have a single msi file which installs and runs a few of the custom actions to "Launch a file" before completing.

Logging in and using an account of the "Administrators" group, everything seems to be somewhat fine (Registry entries created, files copied, a post installation custom action run and modified some program .config files, registered to Uninstall, etc.)

However, for the Uninstallation of EITHER the 9.9 's .msi and AI 22's .msi, ( launched from Settings (or Control Panel) -> Programs -> Uninstall), it will start up, prompt for elevated rights to make modifications to the system (which is affirmed), then begins the uninstallation dialog, but eventually errors out with:
----
There is a problem with this Windows Installer package. A script required for this install to complete could not be run. Contact your personnel or package vendor.
----

However, if I launch a command prompt with Admin privileges and run "msiexec /x my-installer.msi", the uninstallation runs just fine.

I'm hoping someone can provide some direction on what the issue may be that elevating privileges from the uninstall doesn't seem to do something correctly.

TIA
-Corey
SourceGear

[Liviu]

Hello Corey and welcome to our forums,

Unfortunately, I'm not sure why this happens.

To facilitate a more in-depth investigation of this issue, could you kindly email the following resources to support at advancedinstaller dot com?

1. the .AIP (setup project) file.
2. a download link for your setup package.

Best regards,
Liviu

[vault]

HI there,

Just a follow up. This might have been VM related. The installer was only having problem on a Windows Server 2019 Standard installation, but wouldn't behave that way on a Windows Server 2022 as well as Windows Server 2016.

We set up a new virtual machine with a fresh installation of Windows Server 2019, and could NOT recreate the behavior. We're going to consider the matter closed unless customers start complaining, but for now our own internal testing shows it is a problem within a VM, and not the installation itself.

Apologies if this wasted anyone's time.

-Corey
SourceGear

[Liviu]

Hello Corey,

Thank you for the update.

No worries at all, these things happen. I'm glad the matter is resolved.

Best regards,
Liviu