Knock, knock! Who's there?

Dealing with OS and Identity

Internet Explorer Protected Mode Elevation Policy and Administrative Templates

Internet Explorer Protected Mode Elevation Policy and Administrative Templates

  • Comments 2
  • Likes

You probably have run through the following popup when using Internet Explorer add-ons and extensions:


In this example, I clicked a link in an Internet web page that pointed to an XPS file.
This prompt is due to the fact that Internet Explorer is running in Protected Mode, and tries to open an application or extension outside of Protected Mode.

The IE behavior regarding this prompt is governed by the following registry keys:

  • HKLM\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy. Some software installation programs register themselves under this key (each with its own subkey GUID) to manage Protected Mode behavior. On the same hand, if Microsoft determines that an application has a vulnerability and presents a danger to end users, Microsoft reserves the right to remove that application at any time from the elevation policy.
  • HKCU\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy. When the user checks the “Do not show me the warning for this program again” in the prompt dialog, Internet Explorer writes a subkey GUID and associated values under this key to “register” Protected Mode behavior for a given application for that particular user.

You can check more details at and

If an administrator wants to deploy specific Protected Mode prompts for specific applications, can do two things:

  • Directly change HKLM\HKCU keys. This can be implemented through logon scripts (HKCU part) or PC imaging/software deployment (HKLM part). The caveat is that the setting is not enforced (users can override it) and leaves traces on the system that need to be tracked back.
  • Apply changes in Policies branches. This overrides the actual HKM\HKCU keys, enforces behaviors does not alter system configuration and cleanly disappear when the Group Policy settings are removed, so this is the recommended approach.

Managing Elevation Policy through Group Policy:
Using Group Policy infrastructure, you can actually change the Protected Mode behavior, to for example, always prompt for to allow an extension to run. Notice the greyed-out checkbox. This prevents the user to check it and override this prompt.


In the same manner, you can use Group Policy to hide prompts for trusted applications automagically, so if you are deploying an application you can transparently run it through Protected Mode (i.e. Microsoft Office Live Meeting) whenever it gets deployed to the managed desktop computer, without bothering the user with the security warning.

The problem here is that neither Windows Vista nor Windows 7 (or their server counterparts) include an Administrative template to manage these settings out of the box, so provides some guidance and templates to manage these configuration. However, the provided ADM/ADMX are not perfect. This is how it looks in GPEditor:


The problems of this ADMX include:

  • Hardcoding. The provided ADMX hardcodes registry values for the applications you want to manage in the ADMX itself, not through policy options. It actually behaves as an “configuration set” that applies elevation policies to applications as specified within the ADMX.
  • No customization point for administrators. Administrators only can set the policy to Enabled or Disabled, and does the registry changes included in the ADMX. If the ADMX includes three applications with specific elevation policies, administrators cannot configure just one of them or change the elevation policy from what is hardcoded in the ADMX. If there is need for delegated administrators to manage different policies or application sets, they need to generate separate ADMX files.

So I decided to give ADMX creation a try, and end up with the following:



The advantages of this custom ADMX include:

  • Information for administrators. ADML file includes details for administrators about what the policy does and how to configure it.
  • Allows to customize up to 15 applications (by default).  Administrators can specify executable names, paths, CLSIDs and policy levels. Actually, the ADMX file can easily be extended to support whatever number is needed beyond 15.
  • Provide a common GUID space for policies. ADMX file uses registry subkeys under Software\Policies\Microsoft\Internet Explorer\Low Rights\ElevationPolicy in the form of GUIDs like {DEADBEEF-CAFE-DEAD-BEEF-000000000001}, {DEADBEEF-CAFE-DEAD-BEEF-000000000002}, {DEADBEEF-CAFE-DEAD-BEEF-000000000003}, up to {DEADBEEF-CAFE-DEAD-BEEF-000000000015}. For lower OU levels GPOs to override higher level OU GPOs, you just need to customize a few and set the rest to “Disable”.
  • Support for variables in extension path. In the extension path textbox, administrators can specify %ProgramFiles%, %SystemRoot% or other variables to avoid hardcoding paths.

Here are the ADMX files. Just copy ADMX to “%SystemRoot%\PolicyDefinitions” and ADML to “%SystemRoot%\PolicyDefinitions\en-US”, or place them in Central Store.

Attachment: Elevation Policy
  • Thanks, your custom ADMX is a lifesaver.

    Is the implementation of this policy considered to be a workaround to deal with ActiveX that are not (yet) IE8/IE9 compatible on Windows 7?

    I have used your ADMX to account for an EXE which apparantly does not have a GUID - nothing gets written into HKCU-or-HKLM..(Software\Policies\Microsoft\Internet Explorer\Low Rights\ElevationPolicy).

    The maker of the ActiveX has acknowledged that their ActiveX needs updating but in the meantime, I'd like some form of workaround if that's even possible. Thanks for your valuable insight.

  • @Justine

    The elevation policy is typically about executable programs that are triggered to run due to some sort of IE mechanism, such as MIME type file.

    The LiveMeeting example is fairly complex though. An *.RTC file is downloaded by IE, that corresponds to "application/" MIME type (check HKEY_CLASSES_ROOT\.rtc key), that ends up running a DLL through RunDLL32: C:\Windows\system32\rundll32.exe "C:\Program Files\Common Files\Microsoft Shared\LiveMeeting Shared\RtcRouter.dll",RouteMIME %1. Then the "program" is the actual RtcRouter.dll that runs hosted under RunDLL32 process, and not the RunDLL32.exe itself.

    If what you are seeing are the dialogs described here, forget ADMX for a momment and inspect what is written by IE when the user checks the checkbox and hits "Allow" button under "HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Low Rights\ElevationPolicy".

    Then you just need to port that piece of information into the ADMX in the form of "AppName", "ApPath" and "Policy" values in the ADMX configuration.

    The actual GUID in the registry key is random. It does not have anything to do with the program itself, but is just a simple way to have unique subkeys under "\ElevationPolicy" key.

    So if you take an existing EXE file in there and change its name and try to trigger it again, you will get the prompt again and when acknoledge to always run elevated, it will generate the same "AppName/AppPath/Policy" tripplet under a new GUID.

    Once all these said ... I guess your problem is quite different though :)

    IE add-ons can be ActiveX Controls, but also Browser Helper Objects, Explorer Bars, Toolbars and Browser Extensions. You first need to figure out what kind of browser extension is your case about.

    All this stuff has generally nothing to ActiveX controls themselves directly, as they typically run within the IE process.

    The "Elevation Policy" is about letting a program (EXE or hosted DLL like the RunDLL32 example) run as if the user would interactively run it, instead of being triggered by Internet code.

    What the ADMX (both KB and mine) allow is to provide some kind of seamless experience to avoid well-known programs to prompt your users.

    Once the program is allowed to run, it still could fail trying to do its job, depending of what it tries to do and what priviledges the current user has.

    For example, if it tries to write files in C:\Windows or HKLM\Software, it is going to fail if the user is not administrator, and it is still propably going to fail for administrators if the running process is not prepared to run as administrator when called (i.e. through the Compatibility tab).

    You may want to check if Protected Mode is your problem or not by checking the IE zone (IE9 does not show it in the status bar, you need to right-click the page content and check its properties page), and see if the assigned zone has Protected Mode enabled. It is disabled by default in "Local Intranet" and "Trusted Sites" zone in IE9 on Windows 7 for me (despite the first link says about defaults), so if the problem is due to Protected Mode, assigning the site to those zones may help. Microsoft does not recommend to disable it for Internet zone.

    Another different kind of problem is if the user is a standard user trying to access an Intranet webpage that contains ActiveX controls that do not get installed, but this is a much more well known issue with ActiveX and there are different workarounds for this, including adding it to the platform components, software distribution, publishing through Active Directory or, for Windows Vista and 7, using the "ActiveX Installer Service" policy settings to allow certain URLs to get ActiveX installed when accessed.

    Hope this helps!

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment