Group Policy Preferences not mapping network drives in Windows 8

One of the first problems I noticed with Windows 8 is my drive mappings were missing.  I joined a freshly installed Windows 8 workstation to the domain, and with that membership the workstation should be provided some drive mappings based on who I am when I log on to the computer.  I am using Group Policy Preferences and security groups to map drives in this environment.  It works exceptionally well on Windows 7 and Windows XP, but here I am looking at an empty explorer window that should have about 4 mapped drives sitting in it.

After some research, I discovered that this is actually a known issue, and not only is it a known issue, but according to message boards it has been known for quite some time now and nothing has been done to correct it.  From the reading that I did, I determined that if you are a standard user (no administrative rights on the domain or on the local workstation) you will be provided your network drives.  However, if you are an administrator (domain or local), the group policy applies successfully and no errors result, but no drives are displayed in the explorer window.  That seems really backwards to me as a network administrator, but that is what is occurring.

According to posts that I have read on the subject, it would seem that because group policy preferences are applied using the users security context, and the explorer window by default is launched without any administrative privileges, it doesn’t have the rights to display the drives.  I don’t know if I believe that, but the users who were stating that, also provided the workarounds that gave me my drives back.

So, because no one seems to be able to pin-point the exact issue and several changes have provided a workaround, I am just going to list all the possibilities here and they can be attempted at will.

  • “uncheck” the reconnect option in the drive mapping settings.


  • run in logged-on user’s security context (user policy option)


  • It was also suggested that removing Item-level targeting would map the drives, but I don’t think that is something that most people will want to do since Item-level targeting is one of the key features with Group Policy Preferences.
  • Disable Fast Logon: Fast Logon Optimization
  • Check “Always wait for the network at computer startup and logon” policy is enabled under Computer Configuration/Administrative Templates/System/Logon in the Group Policy.


  • and of course there is removal of the user from any administrative groups (not likely to be the first choice)

The first option to “uncheck” the reconnect option worked for me.  I really hope that Microsoft releases a patch shortly to correct this.  I would prefer to have the drives reconnect.

Use Group Policy to Configure Windows Firewall to allow WMI

Using Group Policy to enable WMI (Windows Management Instrumentation) remote requests through the Windows Firewall

It is always a good idea to enable the Windows firewall under the domain profile. Enabling the firewall can prevent needed functionality as well.  For example, in some scenarios it may be required to be able to interact with client workstations or servers via WMI (which would be a type of unsolicited DCOM request on port 135).  Windows firewall will block this functionality unless you explicitly allow it.  To allow WMI remote requests through the windows firewall using Group Policy,  the “Allow Remote Administration Exception” policy needs to be enabled in the group policy object being applied to the workstations and / or servers requiring this access in the environment.  In order to set this, open up Group Policy Manager, and browse to the following location: Computer Configuration\Administrative Template\Network\Network Connections\Windows Firewall\Domain Profile(if setting this for the domain profile).  The same policy can be found in the “Standard Profile” as well.

Once you enable “Allow Remote Administration Exception” (and the computer objects refresh their policies usually 4 hours), WMI traffic should be allowed.

If you are impatient like me, sometimes it is best to just issue a command from the commmand line and be done.  The following are examples of commands that can be used to enable the same functionality as above.

Allow WMI through the Windows Firewall from the command line


If a connect attempt using wbemtest.exe fails – follow these steps to allow the requests through the firewall.

From the local machine command line, if the platform is Windows XP / Server 2003 (Below are three commands each providing different options)

 c:\> netsh firewall set service remoteadmin enable
 c:\> netsh firewall set service remoteadmin enable subnet
 c:\> netsh firewall set service remoteadmin enable custom,LocalSubnet

Windows7 / Server 2008 (Two commands below provide 2 ways to set the firewall to allow WMI)

 c:\> netsh advfirewall firewall set rule group="windows management instrumentation (wmi)" new enable=yes

You should see something like the following if successful.

Updated X rule(s) (where X is the number of rules updated)

  c:\> netsh advfirewall firewall set rule group="remote administration" new enable=yes

Again, you will see something like the following if successful.

Updated X rule(s).

This should be all that is required to allow WMI remote requests through the Windows Firewall.  The name of the Group Policy Object setting prevented me from getting this to work for quite a while.

Group Policy Filtering using WMI


The purpose of WMI filtering is to allow more control over the Active Directory objects that Group Policy is applied.  WMI filtering can be very powerful when used correctly, and can prevent the complex tree of Organization Units created to try and separate the Active Directory objects correctly.  Microsoft recommended best practice is to leverage filtering and item level targeting (for preferences) to avoid large and complex Active Directory structure.  While OUs can be used to filter, it is also a manual process and requires the interaction of an administrator.  With WMI filtering, if a workstation is upgraded to another operating system, WMI will automatically acknowledge that change, where in the OU structure, the account would have to be moved to a new OU manually.  So WMI filtering can reduce management overhead and prevent errors in policy application.

A couple of things to note when designing Group Policy using WMI filters:

  • The WMI query syntax is similar to an SQL query
  • Complex syntax can be written, but the more complex it becomes the more difficult it will be to manage
  • The more filters are used and the more complex the queries, the greater the length of the logon time
  • Per Microsoft recommended best practice, if a user / computer configuration if it is not being used, it should be disabled.  Every configuration that is processed will add time to the logon process even if it is not being used


By default no WMI filters exist in Active Directory.  The WMI filter container can be found in the Group Policy Management MMC under the Group Policy Objects container.

To create a new filter, right click the WMI Filters container and select “new” from the list.

This will open the WMI filter dialog window.  (shown below)

Type a name and description, and then click the “Add” button to add the query to run (to determine OS version in this case)

This will open a new dialog window and it will prompt for the namespace (which should already be populated and unless you are doing something really strange should not be changed).  It should be defaulted to root\CIMv2.  It will also have a big box to type the query you want to run in.  This is where you put the following:

select * from Win32_OperatingSystem where Version like "6.%" and ProductType = "1"

When you click “OK” on the WMI dialog window you will see the following:

Additional queries can be run (like checking for the presence of a battery, or this query can be modified to include the check for the existence of a battery.  Remember the notes from above, more complexity will lead to more difficulty managing them and it will increase logon times.  Click the “Save” button to save your new filter.

If everything worked out, you will now see something similar to the following:

Where a new filter will be listed under the WMI Filters container.  The last step before testing is associating the filter with the GPO.  To do this, click on the GPO you want to filter, and under the scope tab look for the WMI Filtering section toward the bottom of the window.  Select your newly created filter and you will now be filtering based on OS and only Windows 7 workstations will be affected by this policy. (for this example).


There really isn’t too much that can go wrong with these.  A couple of things that should be verified are the following:

  • Make sure the scope is set accurately, if the computer is a part of a security group, make sure that security group has read and apply rights to the Group Policy Object
  • Make sure that the group policy is applied to the correct OU and that it is enabled
  • Make sure no inheritance blocking is set, or an enforcement rule applied to another GPO that will prevent the settings of this GPO from applying correctly
  • Run the following command from a command prompt to verify that the GPO is applied as expected
gpresult /r

This is a quick way to set Group Policy using a variety of conditions providing the ability to maintain a more “flat” Active Directory structure so less manual processes need to be completed reducing time requirements and avoiding errors.

Active Directory Group Policy Preferences


Microsoft released a great new set of tools for Active Directory with the release of Windows Server 2008 called Group Policy Preferences.  Group Policy Preferences was introduced in the 2008 release of Microsoft Windows Server.  It was the opinion of most members of the systems administration community that we should have seen these incorporated into Active Directory much sooner.  They provide a simple GUI  interface to manipulate and control almost any aspect of the Microsoft Windows operating system.


The following document will not only outline Group Policy Preferences and the powerful management tools available but also provide Microsoft best practice surrounding them.  Simple examples will be provided but these examples can be combined to really harness the full power of Group Policy Preferences.

Detailed Information


Probably one of the easiest and most useful tasks that Group Policy Preferences accomplishes is mapping network drives.  The best way to accomplish this is to incorporate existing Microsoft best practice (which should already be in place in a standard  environment) and mesh it together with the new Group Policy Preferences component for ease of administration and improved security.

Security Setup

This example will assume that an Accounting department exists and that a share for the Accounting department is required for collaboration.  Per Microsoft recommend best practice, and found to work most efficiently  across all types of environments is creating domain local security groups for access to shared resources and assigning NTFS permissions to these security groups.  Next domain global groups are created and all the users required to access the resources are placed into these global groups.  Finally, the global groups are associated to the local groups connected to the shared resources.  This is actually a Microsoft recommend best practice but very few organization actually implement this strategy and even disagreed with Microsoft wholeheartedly.  However, when leveraging this configuration it becomes very clear why this method is used and recommended by Microsoft.

The following will provide the details of an example of how this methodology works.  The shared resource name will be simply “Accounting“.  It is recommend to name the folder name identical to the shared name for simplicity, but isn’t necessary.  It is also recommend to create a folder administration group for managing file and folder NTFS permissions.  This will provide very granular control over who has access to all file and folder permissions.  Potentially, user accounts would only be placed into this security group as permissions need to be changed or setup.  A domain global security group is created called “user-file and folder admins” group. This is not necessarily an arbitrary name.  Naming and naming conventions are also critically important when working with Active Directory.  Any IT professional that feels differently has most likely had very little experience managing or administering an Active Directory domain. The naming convention used in this example will follow the format [type]-[description]-[optional details] where [type] is the type of objects that are associated with the group, [description] is a short description of the group like Accounting Department, and the [optional details] could be something like read OR write or manage OR standard detailing the access levels.  For the Accounting department, in order to provide some examples of user security groups, we have 3 security groups; user-Accounting Department-general, user-Accounting Department-managers, and user-Accounting Department-controllers.

In a similar fashion the network resource will have various security groups associated with it.  In order to keep this simple, the following will be used; file-Accounting Share-read and file-Accounting Share-write.  We now have all the groups required to setup a solid environment and provide access controls through NTFS permissions.

We will make user-Accounting Department-managers and user-Accounting Department-controllers a part of the file-Accounting Share-write and the user-Accounting Department-general group a part of the file-Accounting Share-read security group.  This will allow managers and controllers to manipulate the data in the share, but the general accounting users will only be allowed to read the data as we may want them to have access to the data, but we don’t want them to manipulate or change it.  Users will then be placed in the appropriate user global security group.

NOTE:  It is really important that users are never placed directly into the file security groups.

Mapping a network drive using Group Policy Preferences

After testing and verifying the access rights based on the new security groups, the next step involves actually setting up the configuration that will map the drives.  First, a Group Policy Object is created which will contain the preferences.  The reoccurring theme is back with naming of Group Policy Objects.  When creating a Group Policy Object, the name will be important and a standard should be followed per Microsoft.  For this example, the following template is used; [object it applies]-[Short description]-[type], where [object it applies] refers to user, computer, or both, [Short description] provides a quick description of the Group Policy Object‘s goals, and [type] would be policy, preference, or both indicating what methods of configuration are used.

Based on this template for Group Policy Objects the following Group Policy Object is created user-Drive Mapping-preferences.  The name quickly identifies that the Group Policy Object will apply to user objects, it is for the purpose of drive mapping, and it uses preferences to accomplish this task.

Once the Group Policy Object has been created, right clicking the object and selecting the “edit” option will open the policy.  Drilling down under the User Configuration section, then Preferences, then Windows Settings, Drive Maps will be listed.  Right clicking this object will provide a menu, select “New -> Mapped Drive“.  A new “Properties” window will be displayed allowing a configuration to be built for the drive mapping.

All preferences use the same 4 options; create, delete, update, and replace.

  • Create will create the “configuration” if it doesn’t exist, but will not check for changes or update if anything is changed.
  • Delete removes the “configuration” and can be used in conjunction with the other actions.
  • Update will update the “configuration” by creating if needed or updating if required.  A quick note, the update action does not remove an item if the object it is being applied to falls out of scope.
  • Replace is similar to update, but it is the only action that can be used with the “remove when no longer applies” option.  If the “replace” action is implemented and the object (user for example) is no longer in the scope of the preference, replace will remove the preference configuration.

For mapped drives, the most common action used is “replace” as it will add and remove mapped drives as needed.  Once the action has been selected, the path to network resource in this case \\fileserver01\Accounting is provided in the “Location” entry box and the “reconnect” check box is selected if this functionality is needed.  Preferences also allows for the network resource to be named.  This is a great idea to prevent end-users from becoming confused or using the drive letter associated with the network resource.  By placing a check in “Label as“, and in the space provided supply a meaningful name for your network resource (to remain consistent and to keep things simple, the actual shared resource name could be used here (Accounting).  Next the drive letter is selected.  Again, another great option with Group Policy Preferences is the ability to select “User first available, starting at:” which will attempt to map the drive to the drive letter indicated first, but if it is in use continues to attempt to map the drive to ascending letters until an open letter is found.  This functionality displays why naming the shared resource is so important.  If the end-user was calling the network resource the “G” drive for example, but today it is the “J” drive, they would be confused and likely contact the help desk believing they lost access to their network drive.  Of course using “Existing” allows a single letter to be chosen for the mapping.  There are several other options on this Properties page, but they will not be covered in detail here.

The next, and arguably the more impressive page / tab is the “Common” tab.  This is the options that will be configured for how the drive mapping will be used.  This tab contains features like “Run in logged-on user’s security context (user policy option)” which allows preferences to run as the user logging on with the user’s defined rights and permissions.  The “Remove this item when it is no longer applied” option (used only when the “Replace” action is selected) removes the configuration if it no longer applies to the object (user or computer).  “Apply once and do not reapply” is used when a configuration is only needed to be applied one time, similar to “run once” in Windows.  The last option is “Item-level targeting” and is what really makes Group Policy Preferences worthwhile.  It allows fine grain control over what configurations apply and how they apply using almost unlimited filtering.

For this example, we will be assuming that the organization has several sites / locations and the accounting department of each of these sites has individual drive mappings.

By leveraging the “Item-level targeting” the drive can be mapped to the users of the account security groups (created above) who have a IP address in the subnet of the specific location, or using the Active Directory Site.

First it should be understood that adding a single targeting item is completely acceptable, but several items can be used with either AND or OR statements and IS or IS NOT statements.  Several items can be combined into a collection and collections can be evaluated the same way individual items are evaluated.

In order to better understand this, using the example above, a mapped drive definition will be setup that will map the network drive to any user who meets the following criteria:

  • is a member of the user-Accounting Department-managers security group
  • is a part of the “Location A” site in Active Directory Sites and Services
  • has been assigned an IP address in the range of –

To make this happen, a collection is created.  In that collection 2 targeting items are created.  The first item defines that the IP address is between and and the other item defines the object must be a part of the Location A site in Active Directory Sites and Services.  Now, using the item options it can be specified that one of these conditions must be true, or both of these conditions must be true by toggling the And and Or options.  Using “And” will define that both items must be true for the drive mapping to occur while using “Or” will allow for either of the conditions to be met.  The same applies when looking at the “Is” and “Is Not” item options.  These options perform just want you would expect.  By using the “Is” option, the conditions must be true, and conversely by using the “Is Not” option, the conditions must be false.


Once the collection is created and configured to provide expected results, the last task is to provide a single item requiring membership in the user-Account Department-managers.

Again, the item options can be used to require is be true and the collection be true or require that one or the other is true.  In the example, the goal is to have everything match, so the “and” modifier will be used for all items and since we want everything true, the “Is” modifier will also be used for each item.

Saving this new configuration and applying it to an OU that contains the users, the following will be the result of all the configurations made in this example from the security group selections to the item level targeting of the drive mapping preference.

  • Managers of the Account department for the Location A site will receive a mapped drive
  • These users will have read and write access to the drive
  • If they move to another location, they will lose the mapped drive until they return to Location A
  • If a manager is moved to a new role within the organization, simply removing them from the user-Accounting Department-managers will remove the drive mapping from their workstation, but also remove access rights to the network location so manually providing the UNC path to the resource will result in an “access denied” message.

The example above provides a simple and hopefully straight forward example of how Group Policy Preferences can be leveraged and how potentially powerful they can be in administration of rights and delegation of resources.

Known Issues / Troubleshooting

Problem: |  The network resource does not get mapped to a drive even though all settings are correct and user is a member of required security groups.

Solution: |  Due to Group Policy Preferences being relatively new, there are several prerequisites required in order for the instructions of the preferences to interact with older windows systems.  The prerequisites will not be covered here, but a quick search should provide several Microsoft documents that define what each version of Windows require in order for successful use of Group Policy Preferences.

Problem: |

Solution: |

References / Additional Resources



Delay Tasks Using Group Policy

Goal / Scope

Create a Group Policy Object or modify an existing Group Policy Object to run a scheduled task once a user has logged on to the system.


This will only be effective using Window Vista (or later) Operating Systems.

Methodology / Process Steps

Edit the Group Policy Object to be used for pushing the new task.  Expand the User section, and locate the preferences section and expand it.  Now Expand the Control Panel section and locate Scheduled Tasks and select it.


In the right hand pane, right clicking will display a menu.  Selecting “New” will display a sub menu.  Locate and select “Scheduled Task (Windows Vista and later)”.  This is the only option that can be used for setting the special delay option.  Once the new dialog window is displayed, configuration of the task can be started.  Begin by entering a name for the task.  Next select the user credentials this task should be run under.  By default, the logged on user will be supplied in the form of variables.  Run only when user is logged on is the recommended option as the goal is to run something a set time after a user logs on to the workstation.  Selecting “run with highest privileges” is recommended if the script is having problems executing due to permissions.


Next click on the “triggers” tab and click “new …” at the bottom.  This will open a dialog box allowing the creating of a trigger.  In the “begin the task” dropdown menu, select when the task should be initiated.  In this example “At log on” will be selected.  Depending on what is being accomplished, it may be necessary to specify a specific user, but the default is any user logon will trigger the event.


The next step is the important one, under the “Advanced” section, place a checkmark in “Delay task for” and select a time frame from the drop down that meets the requirements of the task.  The options are slightly limited, but other options (under the Conditions tab) help offset these.


Once all the settings have been configured correctly, clicking “Ok” will set the trigger.  Multiple triggers can also be setup.  Next under the “Actions” tab, the task can be configured (i.e. what will be run or executed when a trigger is triggered.)  Aside from starting a program or a script, an email can be sent and a message can be displayed.


The configuration of what action should be executed is simply setting the location of the program or script and adding any arguments.


Clicking “Ok” will complete the creation of the action.  Several actions can also be configured.

The next tab, the “Conditions” tab, allows specific additional conditions such as checking if the workstation is running on battery or wake up the workstation to run the task, and more importantly check if a network connection exists and only run if a connection is established.


Finally, under the “Settings” tab provides options for retrying the action if it fails, stopping the action, and removing the action.  In this example, the action is retried 5 additional times every 5 minutes.


The common tab is the same as any other Group Policy Preference and item level targeting and run once options can be set as well.


Known Issues / Troubleshooting

This section is for the issues that have well defined and tested solutions.

No known issues currently.



Update GPO Templates

Goal / Scope

How to install additional GPO templates into an Active Directory environment.  This is limited to environments running Server 2008 or later


Additional templates for managing devices and endpoints are often very useful.  The method for importing GPO templates into Group Policy for use has changed from previous versions of Windows server and Active Directory.  The process is much simpler and more straight forward once it is understood.

Methodology / Process Steps

To import or leverage new GPO templates in an Active Directory environment, the admx template files simply need to be copied to the following location:


Once the files are in place, opening the Group Policy MMC, will allow the new policies to be set and applied.

Known Issues / Troubleshooting

This section is for the issues that have well defined and tested solutions.

Problem: | Unable to copy the files to the specified location

Solution: | These steps must be run as a domain administrator

Problem: | The new policy is unable to be read when attempting to view or make changes to the policy

Solution: | The admx templates need to be copied to all domain controllers in the environment that will be accessed to make changes to the policies.