UAC in Maintenance(Change) Mode

[Reureu]

Hi folks,

I am working on a Basic MSI project with IS 2010 SP1.
The project output is a single MSI file... No setup.exe is generated.

The installation requires administrative privileges, so I have set the "Require Administrative Privileges" setting to "Yes".

At installation on Vista and Win7, everything is fine, a UAC dialog pops up at the very beginning of the InstallExecute sequence, then the installation works fine if the user manages to get elevated privileges.

The problem occurs when performing a maintenance to, let's say, change the installed features.
A normal user (ie without administrative privilege) can perform the maintenance without being asked for administrative privileges.
During such a maintenance(change), no UAC dialog pops up, and it seems that the installation sequence is already executed with elevated privileges, according to the log file below.

Two more points:

• All my custom actions that modify the target system are set to "Deferred execution in system context".
  
• I used to build this MSI package with IS 2008, and this scenario worked fine.
  

So I am looking for ideas to make sure the maintenance takes the user rights into account, and that a UAC dialog pops up if required.

MSI (s) (68:18) [13:29:38:304]: Using cached product context: machine assigned for product: 6E99C946597A73D4EB4632B7B4AE2836
MSI (s) (68:18) [13:29:38:304]: Machine policy value 'AlwaysInstallElevated' is 0
MSI (s) (68:18) [13:29:38:306]: User policy value 'AlwaysInstallElevated' is 0
MSI (s) (68:18) [13:29:38:306]: MSI_LUA: Credential prompt is not required at this point, product is managed and deployment compliant
MSI (s) (68:18) [13:29:38:306]: Note: 1: 2205 2: 3: MsiPackageCertificate
MSI (s) (68:18) [13:29:38:306]: Note: 1: 2205 2: 3: MsiDigitalCertificate
MSI (s) (68:18) [13:29:38:306]: PROPERTY CHANGE: Adding ProductState property. Its value is '5'.
MSI (s) (68:18) [13:29:38:306]: PROPERTY CHANGE: Adding ProductToBeRegistered property. Its value is '1'.
MSI (s) (68:18) [13:29:38:306]: Using cached product context: machine assigned for product: 6E99C946597A73D4EB4632B7B4AE2836
MSI (s) (68:18) [13:29:38:306]: Using cached product context: machine assigned for product: 6E99C946597A73D4EB4632B7B4AE2836
MSI (s) (68:18) [13:29:38:306]: Note: 1: 1402 2: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer 3: 2
MSI (s) (68:18) [13:29:38:307]: Entering CMsiConfigurationManager::SetLastUsedSource.
MSI (s) (68:18) [13:29:38:307]: User policy value 'DisableMedia' is 0
MSI (s) (68:18) [13:29:38:307]: Machine policy value 'AllowLockdownMedia' is 1
MSI (s) (68:18) [13:29:38:307]: Using cached product context: machine assigned for product: 6E99C946597A73D4EB4632B7B4AE2836
MSI (s) (68:18) [13:29:38:309]: Specifed source is already in a list.
MSI (s) (68:18) [13:29:38:309]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (68:18) [13:29:38:309]: Machine policy value 'DisableBrowse' is 0
MSI (s) (68:18) [13:29:38:309]: Machine policy value 'AllowLockdownBrowse' is 0
MSI (s) (68:18) [13:29:38:309]: Using cached product context: machine assigned for product: 6E99C946597A73D4EB4632B7B4AE2836
MSI (s) (68:18) [13:29:38:309]: Using cached product context: machine assigned for product: 6E99C946597A73D4EB4632B7B4AE2836
MSI (s) (68:18) [13:29:38:309]: Using cached product context: machine assigned for product: 6E99C946597A73D4EB4632B7B4AE2836
MSI (s) (68:18) [13:29:38:309]: Using cached product context: machine assigned for product: 6E99C946597A73D4EB4632B7B4AE2836
MSI (s) (68:18) [13:29:38:310]: Using cached product context: machine assigned for product: 6E99C946597A73D4EB4632B7B4AE2836
MSI (s) (68:18) [13:29:38:310]: Machine policy value 'AlwaysInstallElevated' is 0
MSI (s) (68:18) [13:29:38:310]: User policy value 'AlwaysInstallElevated' is 0
MSI (s) (68:18) [13:29:38:310]: Using cached product context: machine assigned for product: 6E99C946597A73D4EB4632B7B4AE2836
MSI (s) (68:18) [13:29:38:310]: Product {649C99E6-A795-4D37-BE64-237B4BEA8263} is admin assigned: LocalSystem owns the publish key.
MSI (s) (68:18) [13:29:38:310]: Product {649C99E6-A795-4D37-BE64-237B4BEA8263} is managed.
MSI (s) (68:18) [13:29:38:310]: Running product '{649C99E6-A795-4D37-BE64-237B4BEA8263}' with elevated privileges: Product is assigned.
MSI (s) (68:18) [13:29:38:310]: Adding new sources is not allowed.
MSI (s) (68:18) [13:29:38:310]: Using cached product context: machine assigned for product: 6E99C946597A73D4EB4632B7B4AE2836
MSI (s) (68:18) [13:29:38:310]: Using cached product context: machine assigned for product: 6E99C946597A73D4EB4632B7B4AE2836
MSI (s) (68:18) [13:29:38:310]: Package name retrieved from configuration data: 'Bernafon OASIS.msi'
MSI (s) (68:18) [13:29:38:313]: Note: 1: 2262 2: AdminProperties 3: -2147287038
MSI (s) (68:18) [13:29:38:317]: Machine policy value 'AlwaysInstallElevated' is 0
MSI (s) (68:18) [13:29:38:317]: User policy value 'AlwaysInstallElevated' is 0
MSI (s) (68:18) [13:29:38:317]: Using cached product context: machine assigned for product: 6E99C946597A73D4EB4632B7B4AE2836
MSI (s) (68:18) [13:29:38:317]: Product {649C99E6-A795-4D37-BE64-237B4BEA8263} is admin assigned: LocalSystem owns the publish key.
MSI (s) (68:18) [13:29:38:317]: Product {649C99E6-A795-4D37-BE64-237B4BEA8263} is managed.
MSI (s) (68:18) [13:29:38:317]: Running product '{649C99E6-A795-4D37-BE64-237B4BEA8263}' with elevated privileges: Product is assigned.
MSI (s) (68:18) [13:29:38:317]: Machine policy value 'EnableUserControl' is 0
MSI (s) (68:18) [13:29:38:317]: PROPERTY CHANGE: Adding RestrictedUserControl property. Its value is '1'.
MSI (s) (68:18) [13:29:38:317]: PROPERTY CHANGE: Adding MARKET property. Its value is 'SE'.
MSI (s) (68:18) [13:29:38:317]: PROPERTY CHANGE: Adding CURRENTDIRECTORY property. Its value is 'D:\'.
MSI (s) (68:18) [13:29:38:317]: PROPERTY CHANGE: Adding CLIENTUILEVEL property. Its value is '2'.
MSI (s) (68:18) [13:29:38:317]: PROPERTY CHANGE: Adding CLIENTPROCESSID property. Its value is '244'.
MSI (s) (68:18) [13:29:38:317]: Machine policy value 'DisableAutomaticApplicationShutdown' is 0
MSI (s) (68:18) [13:29:38:318]: PROPERTY CHANGE: Adding MsiRestartManagerSessionKey property. Its value is '577ca2b3ca31d14e8c40c321690ad99a'.
MSI (s) (68:18) [13:29:38:318]: RESTART MANAGER: Session opened.
MSI (s) (68:18) [13:29:38:318]: TRANSFORMS property is now:
MSI (s) (68:18) [13:29:38:318]: PROPERTY CHANGE: Adding PRODUCTLANGUAGE property. Its value is '0'.
MSI (s) (68:18) [13:29:38:318]: PROPERTY CHANGE: Adding VersionDatabase property. Its value is '200'.
MSI (s) (68:18) [13:29:38:322]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\AppData\Roaming
MSI (s) (68:18) [13:29:38:323]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\Favorites
MSI (s) (68:18) [13:29:38:324]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\AppData\Roaming\Microsoft\Windows\Network Shortcuts
MSI (s) (68:18) [13:29:38:325]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\Documents
MSI (s) (68:18) [13:29:38:326]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\AppData\Roaming\Microsoft\Windows\Printer Shortcuts
MSI (s) (68:18) [13:29:38:327]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\AppData\Roaming\Microsoft\Windows\Recent
MSI (s) (68:18) [13:29:38:328]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\AppData\Roaming\Microsoft\Windows\SendTo
MSI (s) (68:18) [13:29:38:329]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\AppData\Roaming\Microsoft\Windows\Templates
MSI (s) (68:18) [13:29:38:329]: SHELL32::SHGetFolderPath returned: C:\ProgramData
MSI (s) (68:18) [13:29:38:330]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\AppData\Local
MSI (s) (68:18) [13:29:38:331]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\Pictures
MSI (s) (68:18) [13:29:38:332]: SHELL32::SHGetFolderPath returned: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Administrative Tools
MSI (s) (68:18) [13:29:38:333]: SHELL32::SHGetFolderPath returned: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Startup
MSI (s) (68:18) [13:29:38:334]: SHELL32::SHGetFolderPath returned: C:\ProgramData\Microsoft\Windows\Start Menu\Programs
MSI (s) (68:18) [13:29:38:335]: SHELL32::SHGetFolderPath returned: C:\ProgramData\Microsoft\Windows\Start Menu
MSI (s) (68:18) [13:29:38:337]: SHELL32::SHGetFolderPath returned: C:\Users\Public\Desktop
MSI (s) (68:18) [13:29:38:339]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Administrative Tools
MSI (s) (68:18) [13:29:38:340]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
MSI (s) (68:18) [13:29:38:341]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\AppData\Roaming\Microsoft\Windows\Start Menu\Programs
MSI (s) (68:18) [13:29:38:342]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\AppData\Roaming\Microsoft\Windows\Start Menu
MSI (s) (68:18) [13:29:38:343]: SHELL32::SHGetFolderPath returned: C:\Users\Normal User\Desktop
MSI (s) (68:18) [13:29:38:344]: SHELL32::SHGetFolderPath returned: C:\ProgramData\Microsoft\Windows\Templates
MSI (s) (68:18) [13:29:38:344]: SHELL32::SHGetFolderPath returned: C:\Windows\Fonts
MSI (s) (68:18) [13:29:38:345]: Note: 1: 2898 2: MS Sans Serif 3: MS Sans Serif 4: 0 5: 16
MSI (s) (68:18) [13:29:38:349]: MSI_LUA: Setting AdminUser property to 1 because the product is already installed managed and per-machine
MSI (s) (68:18) [13:29:38:349]: PROPERTY CHANGE: Adding AdminUser property. Its value is '1'.
MSI (s) (68:18) [13:29:38:349]: MSI_LUA: Setting MsiRunningElevated property to 1 because the install is already running elevated.
MSI (s) (68:18) [13:29:38:349]: PROPERTY CHANGE: Adding MsiRunningElevated property. Its value is '1'.
MSI (s) (68:18) [13:29:38:349]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'.

[peterpeng]

InstallShield 2010 :mad:

[Reureu]

And did you implement any workaround?

[peterpeng]

I have not find a good solution for that. I am not sure I can detect the privilege via windows API in a custom action.

[Reureu]

Glad to hear that I am not the only one who faced this bug. Unfortunately, nobody from Flexera has bothered to reply to this thread.

Using the properties like "AdminUser" and "Privileged" did not lead me anywhere: they are both set to "1" when the user is performing the maintenance because of the privilege elevation.

What I did was
[LIST=1]

Set the MSIUSEREALADMINDETECTION property to 1 in the Property Manager

Detect if the current user has got the admin rights using the following InstallScript code:

MsiGetProperty( hMsi,"AdminUser",szAdminUser );
StrToNum( iAdminUser, szAdminUser )
iUserInAdminGroup = Is( USER_INADMINGROUP, szTmp );

bAdminRightsOk = iAdminUser || iUserInAdminGroup;

if( !bAdminRightsOk ) then
    // IF THE USER DOES NOT HAVE THE ADMIN RIGHTS, THEN DO SOMETHING TO STOP THE INSTALLATION
endif;

I think it is quite dirty to do it that way, but it seems to work so far.

[joshstechnij]

This is expected behavior built into the Windows Installer service that ships with Windows. Since a per-machine (managed) installation required admin privileges to be installed, a successful install of such a package indicates it was approved by an administrator on the machine. Therefore, subsequent maintenance operations (except for a full uninstall) will not present a UAC prompt (MSI always runs in the LocalSystem context, and therefore can perform any modification to the system as needed; it impersonates a launching user when user privileges/context are needed).

Changing this behavior would require changing the Windows Installer service itself on Vista and newer versions of Windows. You may try submitting a feature request to Microsoft through msiwish@microsoft.com to request some method to disable this in future versions of MSI.

[Reureu]

Hi Josh,

Thanks for your answer.
I understand that this behaviour might have been due to Windows Installer itself, but why was it working differently with IS 2008?

Regards

[joshstechnij]

All things being equal, there should be no change in behavior between an MSI package built with IS 2008 or IS 2010. The UAC behavior that is implemented by MSI has been around since Windows Vista/MSI 4.0. InstallShield cannot influence, beyond the settings exposed in an MSI package, how or when UAC prompts occur at runtime.

[Reureu]

Hi Josh,

Once again, thank you for your answer.
There must be one difference somewhere, as this issue appeared after we upgraded our Basic MSI project from IS 2008 to IS 2010.

I have tried the IS diff tool to see the difference between the MSI packages, but could not find anything relevant in the MSI database itself.
There might be some differences in the execution of the InstallScript custom actions though.

[joshstechnij]

InstallScript custom actions contained a bug in IS 2008 that would cause the ALLUSERS property to be cleared (deleted) at runtime. This would have the effect of installing an MSI package per-user instead of per-machine (the default). However, MSI will still prompt for UAC in a per-user install if the "Require Admin Privileges" setting in the summary information stream was set. On maintenance operations, because the package was not managed (per-machine), UAC prompts would be necessary to indicate the operation could continue.

A hotfix was released for this issue for IS 2008 (Q113652: HOTFIX: InstallScript Initialization Code Modifying ALLUSERS Property) and has been resolved in all IS versions since 2008.

The behavior you are now seeing is expected based on a per-machine installed MSI package. In IS 2008, if you were using InstallScript custom actions and the above hotfix had not been applied, your MSI package would have been installed per-user and not per-machine, thus the difference between IS 2008 and newer versions.

You can still obtain the previous behavior by installing the package you are building with IS 2010 in a per-user context. This can be done by deleting the ALLUSERS property from the Property Manager, and anything else in the package that might set the ALLUSERS property to a value of 1 or 2 (the CustomerInformation dialog's Next button behavior will also need to be changed to not set ALLUSERS).

[Reureu]

Hi Josh,

Thanks a lot for your very detailed answer.
Glad to read that it wasn't me having missed something there!
Being realistic, I don't think that I will ever be able to convince Microsoft to change that behaviour in Windows Installer.
So, I will live with my workaround.

Regards