Vista ARP maintenance vs Full version of program

[jstevenco]

Hello AI-ers,

I'm currently puzzled by behavior I see on Vista in Programs and Features (previously Add/Remove Programs). I have configured our package so that the only functionality exposed thru ARP is maintenance mode as we have some dialogs we wish to present interactively everytime the user uninstalls (see http://www.advancedinstaller.com/forums ... php?t=4962).

Here's the problem: our basic statement to our users is that our package must be installed with admin privilege. If I set the package to install with Security='highest available' in the bootstrapper, then users with admin privilege will be able to install, repair and uninstall the package without problems (they still get consent prompts but that's fine). This behavior only occurs when using the original executable package however; invoking Change in ARP for the package does not appear to run the Repair or Remove action with proper elevation. Is there a way to achieve this?

On another note, when I use the first (non-ARP) method described, I am presented with the MSIRMFilesInUse dialog listing two applications that are part of our package. In the latter case, I get an Installer Information dialog stating "the setup must update files or services that cannot be updated while the system is running. If you choose to continue, a reboot will be required to complete the setup". Is this normal or a function of the elevation failure?

Thanks in advance,

Steve

[Cosmin]

Hi,

You are encountering this behavior because Windows caches the only the MSI package when performing an installation (it doesn't cache the bootstrapper). Therefore, when you run the bootstrapper the installation uses an execution level, but when you use the "Add or Remove Programs" applet the cached MSI is used and the default execution level is used.

In order to make sure that the Uninstall process uses Administrator privileges you need to use the "Per user only (with administrator rights required)" or "Per machine only (fails if user is not administrator)" option in the "Install Parameters" page.

when I use the first (non-ARP) method described, I am presented with the MSIRMFilesInUse dialog listing two applications that are part of our package.

This is a normal behavior shown by Windows Installer when it needs to upgrade or remove files that are currently in use. The user can either close the application (so the files are not in use anymore) or reboot the machine (the applications will be closed by the reboot).

Regards,
Cosmin

[jstevenco]

Hi Cosmin,

Thanks for the reply.

In order to make sure that the Uninstall process uses Administrator privileges you need to use the "Per user only (with administrator rights required)"

That did the trick as far as getting the process started correctly. Now that the uninstall is elevated correctly, I also now see the correct (AI) MSIRMFilesInUse dialog as well, rather than the (system generated) Installer Information dialog. Oddly, if I select the default option (auto-close and attempt to restart) I get an error message using the ARP approach but don't get one using the non-ARP approach.

However, I still have other problems.

Because of some internal dependencies I have to manually register a COM object using a custom action, so therefore I need to manually unregister the DLL during uninstall (also using a custom action). The registration works fine, but the unregistration fails. In each case the CA is a simple "EXE with path given by a property" call to regsvr32. I have taken the extra step on the uninstall call to ensure that the action is deferred with no impersonation.

Any ideas as to why this step appears to be running without proper elevation?

Repair mode also will not work -- the process starts up okay, but gets to the point where the first custom action is invoked (after WriteRegistryValues), and then rolls back.

Again, both remove and repair work flawlessly when invoked using the full version of the package.

Thanks again,

Steve

[Cosmin]

Hi,

Now that the uninstall is elevated correctly, I also now see the correct (AI) MSIRMFilesInUse dialog as well, rather than the (system generated) Installer Information dialog.

Note that you can suppress this dialog by using the "Reboot Prompts" combo in the "Install Parameters" page. In your case, you can set this combo to Suppress all Reboots and Reboot prompts.

The registration works fine, but the unregistration fails. In each case the CA is a simple "EXE with path given by a property" call to regsvr32. I have taken the extra step on the uninstall call to ensure that the action is deferred with no impersonation.

I'm not sure why you are encountering this behavior. Can you please send us the AIP to support at advancedinstaller dot com so we can investigate it? Also, please attach the log of the installation that fails. You can generate a log by running this command line:

Code: Select all

msiexec /x GUID /L*V C:\package.log

where "GUID" is the Product Code of your package (you can get it by opening the AIP with a text editor). This command can be used in "cmd.exe" or in the "Run" applet in the Start menu and it will launch the uninstall of the package by using the cached MSI (just like the "Add or Remove Programs" applet).

Regards,
Cosmin