This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: UAC in Maintenance(Change) Mode
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎May 18, 2010
09:40 AM
UAC in Maintenance(Change) Mode
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:
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.
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'.
(10) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 12, 2010
03:35 AM
InstallShield 2010 :mad:
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 12, 2010
03:38 AM
And did you implement any workaround?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 12, 2010
03:45 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 12, 2010
04:53 AM
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:
I think it is quite dirty to do it that way, but it seems to work so far.
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]
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 20, 2010
03:06 PM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 22, 2010
11:55 PM
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
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
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 23, 2010
11:43 AM
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 24, 2010
06:08 AM
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.
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.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 27, 2010
05:56 PM
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).
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).
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Aug 30, 2010
12:10 AM
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
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