Add/Remove Programs Modify\Change do not prompt for Admin
Hi All
I mave a Basic MSI Installation which requires admin privileges to install and uninstall. This all works fine.
The problem i have is when the user opens up Add\Remove programs they can hit the Change button and this doesn't prompt for Admin privileges. (doesnt have the shield as part of the change icon)
This causes problems when we try and update a Configuration file during the modify process as the user is not granted access. We get a Fatal Error!
Does anyone know how to modify the install so Add/Remove programs will always prompt for Admin rights?
Uninstall prompts fine its just Change doesnt and i have been searching for hours through the web and help but I can't see anything.
This is expected behavior for any MSI installation and Add/Remove Programs on Vista and newer. Unfortunately, there isn't really any way to change this behavior since it's baked into the OS.
Are you making these changes with a custom action that runs deferred in system context?
Thanks so much for the reply this issue has been killing me.
When we install we prompt for a server URL and I use the XML File changes section of the MSI project to place this information into a Configuration file.
When we "change\modify" the user should be allowed to modify this string to point to a different server. The XML File changes were not kicking in during a modify so i have written a custom action which will update the XML file. I am executing the custom action after "WriteEnvironmentStrings". The issue is we must have admin writes to write to this file, so this works fine on XP but on Vista because of the UAC and the fact I cant get modify\change to run as adminstrator we get a fatal error.
Not sure where to look from here. If its not possible i am happy to accept that but it feels like i wouldnt be the first person wanting to do this which is why i have been trwaling the internet for days.
If your custom action has its in-script execution setting set to deferred in system context, the custom action should run with elevated privileges, even in maintenance/modify when MSI does not prompt for elevation (if the action is not deferred in system context, it will not run elevated). Windows Installer performs a sort of "silent" elevation since it knows the installation was originally elevated during first time install. A UAC prompt is shown only on remove to ensure the user has initiated this action.
