Internet Explorer Enterprise Mode via Group Policy

imageWith the release of Windows 8.1 Update Microsoft has introduced a new feature Internet Explorer Enterprise Mode. This allows admins to assign via Group Policy a way to force web site to render using specific browser modes.

Internet Explorer has has a long heritage and each new version of the browser shipped has had the rendering engine of the previous installed for compatibility. This option can be invoked by a user by pressing the F12 and then selecting the Document Mode they want to render the page with (see below).


The problem is how IE determine what browsing mode the browser mode should use (See is never an exacting science and it sometimes gets it wrong.

One way was for the web site authors update a meta tag or the host header of the web site to tell the browser to use a particular rendering mode (see  However many organisation have had web sites created internally where the authors have long gone. Therefore Internet Explorer by default will render any intranet web site in the “Intranet Zone” as using the IE7 rendering engine. But buy displaying all the “Intranet Zone” pages as IE7 this means that the pages are being rendered with an older (and MUCH SLOWER) JavaScript engine. So while the browser is capable of cutting edge performance it some time limits it self to much slower performance for the sake of backwards compatibility. If you want more information on this check out myself and Chris Jackson talk about this feature in my recent TechEd presentation The Browser You Loved to Hate

To help address this performance issue and to make it easier for enterprise view internal website using newer rendering engines Microsoft has introduced an new option call Internet Explore Enterprise Mode. This gives administrators more configuration power over what web sites are configured using older and newer rendering engines.

How to enable Internet Explorer Enterprise Mode

Internet Explorer Enterprise mode is not visible to the users out of the box. To enable this feature you need to enable the “Let users turn on and use Enterprise Mode from the Tools menu”.


Once enabled user can toggle the “Enterprise Mode” option from the Internet Explorer menu.


But if the organisation want to specify the location of the Enterprise Mode IE List you can specify the path via the “Use the Enterprise Mode IE website list” group policy.



Update: Managing the Internet Explorer Enterprise Mode Site List

The URL that you specify in the above mentioned setting is an XML tool called the Enterprise Mode Site List Manager (not yet available). This tool will allow you to create you own custom corporate XML file that allow you to granularly specify what web site to render in IE Enterprise Mode.


Once you save the file you publish it to the URL configured via Group Policy and the user will pull down the updated compatibility view list.

Correction: If you have downloading the EMSL tool you can use a text file to bulk import sites in the tool to generate the XML file. As the tools is not out yet you still need to hand craft the XML file.,,



Source #2:

Updated: Enterprise Mode Site List Manager Download  –

How to use Group Policy to configure “Always switch to new tabs when they are created” in Internet Explorer

IE9answerThere is a setting in Internet Explorer that is called “Always switch to new tabs when they are created” which as the name suggests controls how tabs in the browser are created. This setting can of course be controlled via Group Policy so that tabs will either appear in the background or foreground in the browser when a user opens a new tab (e.g. Middle click on a link)


However it’s somewhat confusing as the group policy that controls this option has a totally different name called “Prevent the configuration of new tab creation”.


Just to make it more confusing this policy can also be know as “Turn off configuration of default behaviour of new tab creation” depending on the version of ADMX/ADML files you are running in your environment.


Having policies that have multiple names depending is somewhat common as this is dependent on the version of ADMX/ADML files you have deployed. This is another advantage of using a Central Store for you ADMX/ADML files as it means that the names of the Group Policy will be consistent in your organisation.

TIP: But if you are trying to find a setting that you knew existed before but might have changed name the best place to start looking is in the original location in the GPO as this does not normally change.

Another example of a Group Policy Object being renamed based on the version of ADMX/ADML files that you have deployed in your environment (e.g. “Verbose vs normal status messages” is now called Display highly detailed status messages). But rest assure that the is only a cosmetic change that that you will find that the actual settings and its configured values are still the same.

How to target Group Policy to Virtual Computers

microsoft-hyper-v-logoFellow Australian and Microsoft Hyper-V Program Manager Ben Armstrong (a.k.a. Virtual PC Guy) has just published a blog explaining how you can deploy group policy object to be only targeting to virtual servers (see Targeting Group Policy at Hyper-V VMs).

To do this he explains that you can create a WMI query filter that means the Group Policy object will only apply to Hyper-V guests.

SELECT * FROM Win32_ComputerSystem WHERE Model = “Virtual Machine”

But what if you do not have Hyper-V guests deployed? Then you can running the following command on the virtual platform of choice to discover the model value to query.

wmic computersystems get model

Untitled (2)

In the example above you can see that this returns the vendor specific value of “VMWare Virtual Platform” (if you happen to be using VMWare). You can then take this model value to target the virtual platform of your choice (Hyper-V is of course the only valid choice).

SELECT * FROM Win32_ComputerSystem WHERE Model = “VMWare Virtual Platform”

TIP: You can also use the same method to target Group Policy object to specific hardware models of servers and workstations.

Windows 8.1 and Windows Server 2012 R2 Administrative Templates (ADMX)

Microsoft has just released the Administrative Templates (ADMX/ADML) files that allow you to configure their newest Group Policy Administrative Template setting for Windows 8.1 and Windows Server 2012 R2 on down level Operating Systems. To be clear this just enables you to edit the Group Policy objects on a down level computer, not make them apply.

To install both of these administrative template simply install them on the computer that you are editing the GPO’s. Then the GPO’s you edit from the computer will be automatically upgrade next time you open the via GP Editor.

This might seem fairly handy if you manage you group policy object from a Windows 7 computer. However, as always it is still “BEST PRACTICE” (yes i said the “B” word) to edit Group Policy Objects from the most recent OS in your environment.

Note: Also remember that the Internet Explore 11 administrator templates were also recently made available.

Internet Explorer 11 ADMX

Windows 8.1 ADMX

Why Passwords in Group Policy Preference are VERY BAD


A long time ago did a blog post explaining how to use the Group Policy Preferences Local Users setting to manager the password of the local accounts. This post explained how to do it  in a way that minimised the exposure of the password in Active Directory (see  How to use Group Policy Preferences to change account Passwords ) for anyone that knew what they were doing.

At least as far back as 2009 (and certainly earlier) it was well known that the password was only weakly encrypted and as such could be easily reverse engineer to recover the password. However, for a long time this was much better than the alternative as a lot of administrators would often revert to using scripts that had the password stored as clear text.

Update: Microsoft has now released MS14-025 which explicitly blocks the configuration of passwords in Group Policy Preferences. See more about this at Group Policy Preferences Password Behaviour Change – MS14-025

Microsoft has also gone to extensive lengths over the years to warn users about risks of using password in Group Policy preferences:

1. Via blog posts at Passwords in Group Policy Preferences (updated)

A password in a preference item is stored in SYSVOL in the GPO containing that preference item. To obscure the password from casual users, it is not stored as clear text in the XML source code of the preference item. However, the password is not secured. Because the password is stored in SYSVOL, all authenticated users have read access to it. Additionally, it can be read by the client in transit if the user has the necessary permissions.

2. When you look up the Local Users Group Policy Preferences warning it says this…


3. And when you actually configure the password you are warned again before setting the password.


So how weakly encrypted is the cpassword?

The CPASSWORD is the filed that is used in the Group Policy Preferences XML configuration file that contains the password. Being an XML file this makes it very easy if find the field by simply looking a the contents of the XML files stored in you SYSVOL.



Microsoft documents the password that us used to encrypt/decrypt using AES 32-byte encryption (VERY WEAK).  If you would like to see the password for yourself it can be found in the official technical specification at or… in the modified screenshot provided below (yes that is the ACTUAL key used to encrypt password in Group Policy).


Now you might be thinking that it is absurd that Microsoft are publishing the key used to encrypt the password however due to the DOJ settlement with Microsoft back in 2001 Microsoft are required to document its application programming interfaces with third-party companies. This means that the Microsoft are compelled to document this information…

And now for the REALLY BAD NEWS….

Since June 11th 2012 there has been a  Group Policy Preferences Password module added to MetaSploit that allows you to scan you to discover all the uses of passwords saved in your Active Directory (see description below).

This module enumerates the victim machine’s domain controller and connects to it via SMB. It then looks for Group Policy Preference XML files containing local user accounts and passwords and decrypts them using Microsofts public AES key. Tested on WinXP SP3 Client and Win2k8 R2 DC.


So what does this really mean?

Any users that has the MetaSpoit tool installed on their computer and has an account on your domain can scan your Active Directory and decrypt the stored value of password in a Group Policy Preference . Of course once they have the password of the account they can probably use that account which quite often has elevated privileges…

What Group Policy Preferences are affected ?

While in this post I have focused on the Local Users account password option this is not the only location that you can save a password. In fact there are five separate location in Group Policy Preferences that a save password option can be found.

  • Local User preference items


  • Data Source preference items


  • Mapped Drive preference items


  • Scheduled Task or Immediate Task preference items


  • Service preference items


Update: How do I know here I have this password configured?

Darren Mar-Elia at SDMSoftware has now written a PowerShell script that allows you to identify all the location in your domain that the Group Policy Preference password exists. Check it out at

Should I blame Microsoft for this security issue?

In my opinion, No. This security risk as been in Group Policy Preferences ever since Microsoft bought PolicyMaker. They have also documented a number of time (see above) the risks associated with using this option. Security is also an ever changing field and at the time even weakly encrypted password was better than what most IT administrators otherwise did to do the same task.

So what do I do?

Firstly… Stop configuring any new password in Group Policy Preferences.

Then to find any XML files stored in your SYSVOL (yes there will be a LOT). Open the XML files and then find any that have a configured CPASSWORD value and remove them using either using the Group Policy Preferences UI or by just delete the value our of the XML manually. Once this is done the password value is set to null thus removing the value from Active Directory and mitigating the risk.


As they are Group Policy Preferences the value will persist on the computers/accounts that are already configured. However any new computers will not get the new value configured so keep this in mind as it will probably affect any computer build process you already have in place that uses this setting.

And yes… this means you will need to implement an alternative way to manage password on your computers in your organisation.

Certainly all this news a PITA, however it is something as a Group Policy administrator you must be aware of and actively stop in your organisation…

Additional References: Group Policy Preferences Password Behaviour Change – MS14-025NICE