Using Group Policy Preferences to Map Drives Based on Group Membership

Using Group Policy Preferences to Map Drives Based on Group Membership

  • Comments 21
  • Likes

Hello AskDS Blog Readers, Mike here again! A common request we hear is how to automatically connect specific network shares to drive letters based on group membership. Mapping network drives based on group membership requires some programming knowledge-- either VBScript or command shell (batch files). VBScript based logon scripts can require hundreds of lines of code to provided a complete solution. And batch files require the assistance of helper applications such as IFMEMBER.EXE and NET.EXE, and introduce many challenges with controlling how Windows processes the script. But Group Policy Preferences removes the programming requirement and awkwardness of scripting mapped drives based on group membership. There are many scenarios in which you may want to map a local drive letter to a specific network share to include public drive mappings, inclusive group drive mappings, and exclusive group drive mappings.

Public drive mappings typically do not require membership to a particular group. However, sometimes public drive mappings do not provide enough granularity. Most organizations have data specific to business units such as accounting, marketing, or human resources.. Inclusive Group Drive mappings solve this problem by allowing a configuration that maps a specific drive letter to a specific network share based on the user being a member of a particular group. This ensures members of the accounting unit receive drive letters mapped for accounting and members of human resources map their respective drives. Exclusive drive mappings are not very common; however, they do provide the flexibility to prevent a user from mapping a particular drive letter to a network share if they are not a member of a specific group. A good example of exclusive drive mappings is to prevent the CIO or other executives members from mapping a drive letter in which they are likely to never use. Let us take a closer look at these scenarios

Public drive mappings

Producing a Group Policy Preference item to create public drive mappings is simple. The GPO containing the preference item is typically linked to higher containers in Active Directory, such as a the domain or a parent organizational unit.

Configuring the drive map preference item.

image

Figure 1 Configuring mapped drive preference item

Newly created Group Policy objects apply to all authenticated users. The drive map preference items contained in the GPO inherits the scope of the GPO; leaving us to simply configure the preference item and link the GPO. We start by configuring the drive map preference item by choosing the Action of the item. Drive map actions include Create, Replace, Update, and Delete. These are the actions commonly found in most preference items. Create and Delete actions are self-explanatory. The compelling difference between Replace and Update is that Replace deletes the mapped drive and then creates a new mapped drive with the configured settings. Update does NOT delete the mapped drive-- it only modifies the mapped drive with the new settings. Group Policy Drive Maps use the drive letter to determine if a specific drive exists. The preceding image shows a Drive Map preference item configure with the Replace action. The configured location is a network share named data; hosted by a computer named hq-con-srv-01. The configured drive letter is the G drive. All other options are left at their defaults. This GPO is linked at the contoso.com domain.

The results of this configuration are seen when using Windows Explorer on the client computer. The following picture shows a user's view of Windows Explorer. We see there is one network location listed here, which is the G drive that is mapped to \\hq-con-srv-01\data.

image

Figure 2 Public drive map client view

Later, we'll see how to use exclusive drive mappings with public drive mappings as a way to exclude public drive mappings from a subset of users.

Inclusive drive mapping

Inclusive drive mappings are drives mapped to a user who is a member of (or included) in a specific security group. The most common use for inclusive drive maps is to map remote data shares in common with a specific sub set of users, such as accounting, marketing , or human resources. Configuring an inclusively mapped drive is the same as a public drive mappings, but includes one additional step. The following image shows us configuring the first part of an inclusive drive mapping preference item.

image

Figure 3 Inclusive drive mapping

Configuring the first part of an inclusive drive mapping preference item does not make it inclusive; it does the work of mapping the drive. We must take advantage of item-level targeting to ensure the drive mapping items works only for users who are members of the group. We can configure item level targeting by clicking the Targeting button, which is located on the Common tab of the drive mapping item. The targeting editor provides over 20 different types of targeting items. We're specifically using the Security Group targeting item.

image

Figure 4 Security group targeting item

Using the Browse button allows us to pick a specific group in which to target the drive mapping preference item. Security Group targeting items accomplishes its targeting by comparing security identifiers of the specified group against the list of security identifiers with the security principal's (user or computer) token. Therefore, always use the Browse button when selecting a group; typing the group name does not resolve the name to a security identifier.

image

Figure 5 Configured inclusive security group targeting item

The preceding screen shows a properly configured, inclusive targeting item. A properly configured security group targeting item shows both Group and SID fields. The Group field is strictly for administrative use (we humans recognize names better than numbers). The SID field is used by the client side extension to determine group membership. We can determine this is an inclusive targeting item because of the text that represents the item within the list. The word is in the text "the user is a member of the security group CONTOSO\Management." Our new drive map item and the associated inclusive targeting item are now configured. We can now link the hosting Group Policy object to the domain with confidence that only members of the Management security group receive the drive mapping. We can see the result on a client. The following image shows manager Mike Nash's desktop from a Windows Vista computer. We can see that Mike receives two drive mappings: the public drive mapping (G: drive) and the management drive mapping (M: drive).

image

Figure 6 Client view of inclusive drive mapping

Exclusive drive mapping

The last scenario discussed is exclusive drive mapping. Exclusive drive mappings produce the opposite results of an inclusive drive mapping; that is, the drive map does NOT occur if the user is a member of the specified group. This becomes usefully when you need to make exceptions to prevent specific drives from mapping. Let's add an exclusive drive mapping to our public drive mapping to prevent specific members of management from receiving the public drive mapping.

image

Figure 7 Configured exclusive drive mapping

The preceding image shows the changes we made to the public drive mapping (from the first scenario). We've added a Security Group targeting item to the existing public drive mapping preference item. However, the targeting item applies only if the user IS NOT a member of the ExcludePublicDrives group. We change this option using the Items Options list. The client view of manager Monica Brink shows the results of applying Group Policy.

image

Figure 8 Client view of exclusive drive mapping

This client applies two Group Policy objects; each containing a drive mapping preference item. One item contains our public drive mapping with an exclusive security group targeting item. The other GPO contains the management drive mapping with an inclusive security group targeting item. The client processes the public drive mapping GPO; however, the exclusive targeting item verifies that Monica is a member of the ExcludePublicDrives group. Monica is also a member of the Management group. Therefore, Monica's group memberships prevent her from receiving the public drive mapping and include her in receiving the management drive mapping.

Summary

Drive mapping preference items do not require any scripting knowledge and are easy to use. Leveraging targeting items with drive mapping items increases the power in which to manage drive mapping to users and computers. Public drive mappings are typically linked at higher levels in the domain and generally apply to a large subset (if not all) users. Inclusive drive mappings associate as specific subset of data with a specific group of people, often times mapping to logical divisions within an organization such as accounting, marketing, or human resources. Exclusive drive mappings invert the principals of inclusive drive mappings. The user must not be a member of the specified group for the drive mapping to occur.

Best practices

Be sure to link GPOs high enough in Active Directory so the scope of the drive mapping effects the largest group of user accounts. Obviously, not every GPO should be linked at the domain; however, if there is an accounting organizational unit with three child OUs-- then linking at the Accounting OU effects that largest amount of users. Allow your inclusive and exclusive targeting item to do the bulk of your work. GPOs hosting inclusive drive mappings are best used when the number of user needing the drive mapping are fewer than the number who do not. Exclusive drive mappings are best used when the number of user not requiring the drive mapping are fewer than the number that do. These rules help prevent users from becoming members of too many groups and increasing the cost of managing drive mappings within the organization.

- Mike “Play Some Skynyrd!’ Stephens

  • PingBack from http://www.ditii.com/2009/01/08/using-group-policy-preferences-to-map-drives-based-on-group-membership/

  • Is there a method that will allow use of this system in a Windows 2003 environment? My queries on the web have not provided any definitive information.

    Thanks,

  • We are looking to have the drive mappings move with the users between PC's.  Will the above solution automatically map the drives requiring no user interation?

    Thank you

  • @ nriacone - Did you already install the GP Preferences client on all the 2003 machines, and have at least one Vista or 2008 computer in order to administer GPP? Those are the requirements.

    @ wcaulway - Yes, it is a per-user policy.

  • There is a desktop management system called desktop authority  that  is a good replacement of group policy preferences and can overcome all it's limitations.  

    It  can be installed on a windows domain running  on servers from NT including 2000,2003 and 2008.  

    And it can manage desktops runnnig OSs from windows 95 to Vista covering both 32- and 64-bit versions of XP and Vista.

    http://www.logonscriptreplacement.com

  • Is there a limit to how many drives you can map here?

    The reason I asked is I've deployed 8 drive mappings and only the first 6 are actually going through.

    Thanks,

    Dan

  • In GPP? No. I just tested on a Win7 client and mapped 9 drives.

  • We are trying to use GPP to map a drive using the following syntax: \\servername\%username:~0,1%\%username% in order to achieve the first letter of logged on user. It works fine with a net use command, but fails with network path not found in gpp logs. Is this expected?

  • Ah, I see. So you have a share called "A" that all your A users live in?

    Yes, that works for me on NET USE on Win7.

    It won't work in GPP because the wacky CMD env expansion routine happening here is specific to CMD. GPP has no idea what this means, it treats it as literal. It cannot translate it. The same way that if I tried to open this path using the Explorer RUN dialog, it will not work either when it tries to figure out that c:\a could be c:\%username~0,1% when I was logged on as Admin. It's specific to CMD.

    Your design requires you to stick with legacy logon scripts.

  • Also, it wouldn't work using Windows Explorer's drive mapper dialog either. Try it yourself. Should give a network path not found-type error.

  • Group Policy Preferences does not support command extensions, like those included with cmd.exe. GPP only expands environment variables and the built-in GPP variables that are visible when pressing F3 on any text field when configuring a preference item.

  • I can only get this to work if I disable UAC on the Windows 7 client.  Is this expected?

  • Please elaborate on how you have configured this. There is no UAC on/off requirement specific to GPP and mapped drives, it works fine with UAC on.

  • This should only happen with administrative user accounts. The drive mapping occurs in an elevated user process.  The Windows Explorer process is a non-elevated process.  Mapped drives, regardless of how they are mapped, by default do not span across processes of different elevation. Normal User accounts should not have this problem. You can bypass the problem by mapping the drive as a scheduled task, which would ocurr under the non-eleveated process. Or, you can enable the registry setting in MSKB Article ID: 937624.

  • I did not have this issue on Windows 7 even when using an Admin user though, in a quick repro. I'd expect Mike's answer to be correct for Vista, which had some non-cool behaviors with drive mapping.