How to Silence the UAC Prompt for Per-Machine MSI Packages for Non-Admins Print E-mail
General
Written by Darwin Sanoy   
Friday, February 10, 2012 9:02am

How many times have I been asked if there is a way to silence or automatically approve the UAC prompt for non-admins?  I lost count a long time ago, but if I had a dime for each time – I’d be set!  Windows Installer, however, is a unique case – mainly because Windows Installer only uses the UAC prompt to approve it’s own internal privileges model IF AND ONLY IF it needs to.

Our $9.99 eBook/eClass Bundle brings you up to speed on all
the challenges of supporting applications on 64-bit Windows.
 
Check it out.

We explain in CSI-460 - MSI Packaging Update for Windows 7 that UAC prompts in Windows Installer work completely differently than they do for anything else in Windows.  In the rest of Windows the need for a UAC prompt is assessed as part of process startup - if it is approved EVERYTHING the EXE does is with full admin permissions.  Since UAC prompting happens before the EXE starts and it's results affect the entire period that the EXE is active - it is recognized that UAC has the highest role in determing what permissions are present.

In Windows Installer the roles are reversed. Windows Installer stays in control of security the entire time and it simply leverages the UAC prompting mechanism to either approve or deny it's own internal privileges model.  Why would it be done this way?  Simply because Windows Installer's elevated privileges model is more conservative and secure than UAC's process level elevation model.  When Windows Installer is in charge of privileges, only a small part of the MSI package is given administrator rights and even then, any custom actions in that segment of the package must be flagged correctly in order have elevated permissions.  When custom actions are flagged for elevation - they are run in a sandbox.

If you like what you are reading, you are an excellent candidate for our 5 day training "Application Provisioning Engineer ENG-55" where you can take 3-5 days of training designed to bring anyone who deploys or supports applications on Windows 7 up to speed in record time. Check it out.

A qualifier is necessary here - if the MSI is launched by a background service or a setup.exe (that prompts for elevation), then all MSIEXEC.EXE processes end up inheriting admin rights from the parent process (service or setup.exe) - so in EFFECT the entire package has admin rights - but these have not been given by MSI, but rather the calling process.  You can see all of these assertions in this demo video and or check them yourself with our MSI 5 test harness package.

By contrast UAC process level elevation gives admin permissions to any and all parts of an EXE for the entire time it is executing.

Since UAC is in the subordinate role in Windows Installer security - the UAC prompt is only required if MSI deems it necessary.

When does MSI deem a UAC prompt "unnecessary" ?

Circumstance #1 is when the package is indicated as a user profile isolated installation - one that will only install file resources to the user's profile and registry content the HKEY_CURRENT_USER.  There are two ways to make a package like this.  The first was introduced with Windows Vista (MSI version 4).  This method requires setting the Word Count Summary bit 3 on.  Described here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa372870(v=vs.85).aspx this method still requires that the package itself is coded to never install anything to machine locations or do anything that requires admin rights (like setting up a Windows Service).

The second way was introduced with Windows 7 (MSI version 5) to indicate a package is only installing resources to the user profile is to use the property MSIINSTALLPERUSER=1 along with ALLUSERS=2.  This is described here and here.

But what we really want to focus on is Circumstance #2 because it allows installation of packages that DO require admin rights by a standard user WITHOUT a UAC prompt.

Since the first version Windows Installer has supported a group policy which causes ALL MSI packages to be elevated.  It has such far reaching implications that it has to be turned on in both the User and Computer policies to actually activate (you know, just like two keys required to launch nuclear missles).

The policy is called "Always Install Elevated".  Although it is a very bad practice to enable this in your environment and leave it on, some IT departments (and even some big, unnamed desktop management systems - no not "SCCM") enable and disable these policy keys to trigger this mode.  You could enable the HKLM policy and in a script toggle the HKCU policy.  A more secure (but much more fussy) method is to enable the user policy and use a secure method to manipulate the HKLM policy as it does not rely on ignorance of malware to checking if this policy is on.

A safer method for leveraging the MSI Always Install Elevated policy is to implement it along with tight restrictions on what MSI files can be executed in your environment.  This can be accomplished through either Software Restriction Policies (available since XP) or Windows 7 AppLocker (available only in the "Enterprise" edition).

With Always Install Elevated on MSI determines that it will grant it's internal MSI Elevated Privileges (more limited than UAC process elevation, but enough to install standards compliant MSI files) - so it does not need to rely on UAC to obtain an authorization from the user.  The administrator has essentially "preapproved all MSI's to run with MSI Elevated Privileges".

The required policy key REG file is downloadable at the bottom of this article.

Here's how to test that what I am telling you is true:

  1. Run an MSI package that must have admin rights (writes to "Program Files") under a Standard User profile and verify that it prompts for UAC.  You must be directly running the .MSI, not starting it with a setup.exe for this to work.  You may run the package with a full UI or with the /QR switch.  Using /qn will cause the package to fail as it MUST have the UAC prompt answered - but /QN tells MSI "Under NO circumstance are you to put any UI elements on the screen - including the UAC prompt."
  2. Login as an admin and merge AIE_ON_MACHINE.REG from the below zip file to enable the Computer level "Always Install Elevated" policy.
  3. Log off and back on as the Standard User.
  4. Merge AIE_ON_USER.REG from the below zip file to enable the User level "Always Install Elevated" policy.
  5. Run the package again - this time it will run without a UAC prompt!  You could also now use the /QN switch to make the package COMPLETELY silent as the UAC prompt is no longer needed.
Attachments:
Download this file (AIE_ON.zip)AIE_ON.zip[Turn on MSI Always Install Elevated Group Policy]0.6 Kb
 

Add comment


Security code
Refresh