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

Internet Explorer 11 Group Policy Preferences


With the release of Internet Explorer 11 from Microsoft for Windows 7 I have seen a number of question asking where are the Group Policy Preferences are for this new version of the browser? The good news is that the current Internet Explorer 10 Group Policy Preferences officially supported see .

This works as the default version checking goes from 10 to 99, meaning that it will happily apply the IE 10 settings to IE11.


Note: This does not mean that the IE 10 Group Policy Preferences have any of the new options in IE 11.

The really good news is that this has always been the default behaviour of the IE 10 Group Policy Preferences in Windows Server 2012 meaning that if you already have IE 10 Group Policy Preferences configured you don’t have to do anything to make them work for IE 11.

There is of course many ways to configured Internet Explorer and if you want to configured some of the new setting you can download the new IE 11 administrator templates to update your existing Group Policy Object or Central Store (see Internet Explorer 11 Administrator Templates ). But this is only required if you want to configure any of the 54 new Group Policy setting in the administrative templates.

Tip: You can get a full list of these IE setting from the Group Policy Settings Spread Sheet.

It’s also worth remembering that since Internet Explorer 10 the Internet Explorer Maintenance has  been removed from Group Policy. If you have the option setting configured in a policy it will still apply but the UI to edit these policy settings is now removed on any computer with Internet Explorer 10 or greater installed. The good news is that you can replace this functionality with combination of Administrative Templates, Group Policy Preferences and Group Policy Preferences Registry Keys. While this sounds a little klunky I still definitely recommend stop using IE Maintenance as its days are well and truly over.  I show you how to duplicate the setting from IE Maintenance to the newer ways in my TechEd New Zealand 2013 session The Browser You Love to Hate.

TIP: Once you are done with the Internet Explorer Maintenance be sure to clean up the old setting by doing a  “Rest Browser Settings” see How to remove imported Internet Explorer Group Policy Settings

For additional info see: