Overview: 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:
You can check more details at http://msdn.microsoft.com/en-us/library/bb250462(VS.85).aspx and http://blogs.msdn.com/b/ieinternals/archive/2009/12/01/understanding-internet-explorer-security-protected-mode-elevation-dialog.aspx
If an administrator wants to deploy specific Protected Mode prompts for specific applications, can do two things:
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 http://support.microsoft.com/kb/918239 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:
So I decided to give ADMX creation a try, and end up with the following:
The advantages of this custom ADMX include:
Here are the ADMX files. Just copy ADMX to “%SystemRoot%\PolicyDefinitions” and ADML to “%SystemRoot%\PolicyDefinitions\en-US”, or place them in Central Store.
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.
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/vnd.ms-rtc" 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!