Tag Archives: Group Policy Preferences

Improved Group Policy Preference Targeting by Computer Group Membership

Posted on by
Reply

I want to write about Group Policy Preference targeting items. I posted an article in June entitled Targeting Group Policy Preferences by Container, not by Group. This post highlighted the common problems many people encounter when targeting preferences items based on a computer’s group membership, why the problem occurs, and some workarounds.

Today, I’d like to introduce a hotfix released by Microsoft that improves targeting preference items by computer group membership. The behavior before the hotfix potentially resulted in slow computer group policy application. The slowness was caused by the way Security Group targeting applies against a computer account. The targeting item makes multiple round trips to a domain controller to determine group memberships (including nested groups). The slowness is more significant when the computer applying the targeting item does not have a local domain controller and must use a domain controller across a WAN link.

You can download the hotfix for Windows 7 and Windows Server 2008 R2 through Microsoft Knowledgebase article 2561285. This hotfix changes how the Security Group Targeting item calculates computer group membership. During policy application, the targeting item requests a copy of the computer’s authentication token. This token is mostly identical to the token created during logon, which means it contains a list security identifiers (SIDs) for every group of which the computer is a member, including nested groups. The targeting item performs the configured comparison against this list of SIDs in the token, rather than multiple LDAP calls to a domain controller. This behavior aligns the behavior of computer security group targeting with that of user security group targeting. This should improve the performance of security group targeting.

— Mike Stephens

Target Group Policy Preferences by Container, not by Group

Posted on by
Reply

This post reflects on Group Policy Preference targeting items, specifically targeting by security groups. Targeting preference items by security groups is a bad idea. There is a better way that most environments can accomplish the same result, at a fraction of the cost.

Group Membership dependent

The world of Windows has been dependent on group membership for a long time. This dependency is driven by the way Windows authorizes access to resources. The computer or user must be a member of the group in order to access the printer or file server. Groups are and have been the bane of our existence. Nevertheless, we should not let group membership dominate all aspects of our design. One example where we can move away from using security groups is with Group Policy Preference (GPP) targeting.

Targeting by Security Group

GPP Targeting items control the scope of application for GPP items. Think of targeting items as Group Policy filtering on steroids, but they only apply to GPP items included in a Group Policy object. They introduce an additional layer of administration that provides more control over “how” GPP items apply to a specific user or computer.

00-gppTargetingThe most common scenario we see using the Security Group targeting item is with the Drive Map preference item. IT Professionals have been creating network drive mappings based on security groups since Moby Dick was a sardine– it’s what we do. The act is intuitive because we typically apply permissions to the group and add users to the group.

The problem with this is that not all applications determine group membership the same way. Also, the addition of Universal Groups and the numerous permutations of group nesting make this a complicated task. And let’s not forget that some groups are implicitly added when you log on, like Domain Users, because it’s the designated primary group. Using code, determining group membership is simple — until it’s implemented, and its implementation’s performance is typically indirectly proportional to its accuracy. It either takes a long time to get an accurate list, or a short time to get a somewhat accurate list.

Security Group Computer Targeting

Using GPP Security Group targeting for computers is a really bad idea. Here’s why: in most circumstances, the application retrieves group memberships from a domain controller. This means network traffic from the client to the domain controller and back again. Using the network introduces latency. Latency introduces slow process, and slow processing is the last thing you want when the computer is processing Group Policy. Also, Preference Targeting allows you to create complex targeting scenarios using Boolean operators such as AND, OR, and NOT. This is powerful stuff and lets you combine one or more logon scripts into a single GP item. However, the power comes at a cost. Remember that network traffic we created by make queries to the domain controller for group memberships? Well, that information is not cached; each Security Group targeting item in the GPO must perform that query again- yes, the same one it just did. Don’t hate, that’s just the way it works. This behavior does not take into account nest groups. You need to increase the number of round trips to the domain controller if you want to include groups of groups of groups etcetera ad nauseam (trying to make my Latin word quota).

Security Group User Targeting

User Security Group targeting is not as bad as computer Security Group targeting. During user Security Group targeting, the Group Policy Preferences extension determines group membership from the user’s authentication token. This process if more efficient and does not require round trips to the domain controller. One caveat with depending on group membership is the risk of the computer or user’s group membership containing too many groups. Huh- too many Groups? Yes, this happens more often than many realize. Windows creates an authentication token from information in the Kerberos TGT. The Kerberos TGT has a finite amount of storage for this information. User and computers with large group memberships (groups nested with groups…) can maximize the finite storage available in the TGT. When this happens, the remaining groups memberships are truncated, which creates the effect that the user is not a member of that group. Groups truncated from the authentication token results in the computer or user not receiving a particular Group Policy preference item.

You got any better ideas?

A better choice of targeting Group Policy Preference items is to use Organization Unit targeting items. It’s da bomb!!! Let’s look at how Organizational Unit targeting items work.

01-gppTargeting

The benefits Organizational Unit Targeting Items

Organization Unit targeting items determines OU container membership by parsing the distinguished name of the computer or user. So, it simply uses string manipulation to determine what OUs are in scope with the user or computer. Furthermore, it can determine if the computer or user has direct container membership of an OU by simply looking for the first occurrence of OU immediately following the principal name in the distinguished name.

Computer Targeting using OUs

Computer Preference targeting with OUs still has to contact a domain controller. However, it’s an LDAP call and because we are not chasing nested groups, it’s quick and efficient. First, the preference client-side extension gets the name of the computer. The CSE gets name from the local computer, either from the environment variable or from the registry, in that order. The CSE then uses the name to look up the security identifier (SID) for the computer. Windows performs an LDAP bind to the computer object in Active Directory using the SID. The bind completes and retrieves the computer object’s distinguished name. The CSE then parses the distinguished name as needed to satisfy the Organizational Unit targeting item.

User Targeting using OUs

User Preference targeting requires fewer steps because the client-side extension already knows the user’s SID. The remaining work performed by the CSE is to LDAP bind to the user object using the user’s SID and retrieve the distinguished name from the user object. Then, business as usual, the CSE parses the distinguished name to satisfy the Organizational Unit targeting item.

Wrap Up

So there you have it. The solution is clean and it takes full advantage of your existing Active Directory hierarchy. Alternatively, it could be the catalyst needed to start a redesign project. Understandably, this only works for Group Policy Preferences items; however– every little bit helps when consolidating the number of groups to which computer and users belong– and it makes us a little less dependent on groups. Also, it’s a better, faster, and more efficient alternative over Security Group targeting. So try it.

Update

We recently published a new article around behavior changes with Group Policy Preferences Computer Security Group Targeting.  Read more here.

— Mike Stephens

Forcing Afterhours User Logoffs

Posted on by
Reply

Today I want to answer a common customer request—how to force users to logoff at the end of the day. The scenario requires a bit of an explanation, so let’s get started.

Let’s recognize the value of forcing users to logoff at the end of their work day, rather than simply allowing them to lock their computer. Locking their computer leaves many processes running. Running processes keep files open. Open files may introduce problems with synchronizing user data with Offline Files, home folders and distributing user content to other replica targets. Also, roaming user profiles are updated only at logoff (with the exception of Windows 7 background upload of the ntuser.dat, which must be turned on through policy). Allowing users to remain logged on after hours provides little benefit (aside from people like Ned, who does not sleep for fear of clowns may eat him).

00LogOffHoursWe force an after hour logoff using two Group Policy Preference Scheduled Task items. We’ll configure the items from a Windows Server 2008 R2 computer. Our targeted client computers are Windows 7 and Windows Vista. The typical business work day begins around 8am and ends between 5 and 6 pm. For this scenario, we’ll presume our workday ends at 5 pm. Our first scheduled task notifies the user the computer will shut down in 15 minutes. The second scheduled task actually shutdowns the computer.

Notify the user

We use the first scheduled task to notify the user they will be logged off in 15 minutes. This gives the user a reasonable amount of time to save their work. Ideally, users will save their work and logoff or shut down the computer within this allow time (once they understand their computer will log them off regardless). Our Group Policy Preference items target users; so, we’ll open GPMC and create a new Scheduled Task (Windows Vista or later) preference item.

01LogOffHoursWe use the Update action for the Preference item and name the item DisplayLogoffMessage. The Update action creates the new scheduled task if it does not exist, or updates an existing task with the current configuration. Under the Security option select %LogonDomain\LogonUser% and select Run only when user is logged on.

02LogOffHoursNext, we need to configure when the event triggers. For this scenario, we want the event to trigger daily, at 5 pm. Also, ensure the status for the task is set to Enabled. Next, we’ll configure the action that occurs when the event triggers.03LogOffHoursSelect Display a message for the action. Type Afterhours Logoff in the Title box. In the Message box, type Windows will logoff your session in 15 minutes. Please save your work. Click OK.

Force the logoff

We’ve notified the user. Now we need actually force the logoff. We’ll use a new Schedule Task (Windows Vista or later) preference item.04LogOffHoursWe’ll configure the General tab similar to the previous preference item. We’ll use Update for the Action. The Name and Description can vary; however, understand that name is the criterion used to determine if the scheduled task exists on the applying computer. The only change we’ll make in the Triggers configuration is the time. We should configure this preference item should start at 5:15 pm.05LogOffHoursThe Action for our new preference item is going to Start a program. The program we’ll use is LOGOFF.EXE, which is included with Windows and resides in the System folder. We represent this by using a Group Policy Preference variable. In the Program/script: box, type %SystemDir%\logoff.exe. The LOGOFF.EXE program does not require any arguments.

We should have two Scheduled Task Preference item. The DisplayLogoffMessage should be ordered first and the Force_afterhours_logoffshould be second. The only remaining configuration is to link the Group Policy object hosting these preference items to a point in Active Directory so it applies to user objects.06LogOffHours

On to the client

Users on Windows 7 computers will process the above settings without any additional configuration. However, Windows Vista computers, including those running Service Pack 1 need the latest Group Policy Preference Client Side Extension (http://support.microsoft.com/kb/974266).

At 5 pm, the scheduled task triggers Windows to display a message to the user.

07LogOffHoursFifteen minutes after the message, Windows will then end all the running applications and log off the user.

08LogOffHoursThis is actually the hardest part of the scenario. However, there is one additional configuration we must perform on the user account to complete the solution.

We need to configure Logon Hours for the user. The Logon Hours should be configured to prevent the user from logging on the computer after we’ve forcefully logged them out. In this scenario, we forcefully log off the user at 5:15 pm; however, we’ve configured their user account so their logon hours deny them from logging on past 5 pm. Windows prevents the logon and displays a message to the user explaining they are not allowed to logon at this time.

09LogOffHours

Conclusion

The scenario explains how to administratively force a user session logoff to your environment. If users are members of the local Administrators group, then all bets are off. The only way to prevent an administrator from doing something is not to make them an administrator.

Alternatively, you can slightly modify this scenario to force a computer shutdown rather than a user logoff. Windows includes SHUTDOWN.EXE, with a variety of command arguments. This may be the most optimal form of power management because a powered down computer uses the least amount of energy. Also, forcing shutdowns will force users to save their work before leaving, which helps with making sure centralized backups have the most current and accurate user data.

— Mike Stephens

Windows XP Power Management and Group Policy Preferences

Posted on by
Reply

This scenario covers managing power on Windows XP client computers using Group Policy Preferences. Let’s cover how Windows XP manages power before we cover Group Policy Preferences Power Management.

Windows XP Power Management

Windows XP only has one active power scheme for the entire computer and that scheme is based on the current or previously logged on user—that is to say Windows XP power schemes are only user-based. This means the power scheme can change as each user logs on. Also, it means that last logged on user’s power settings are the settings that remain once the user logs off. And yes, each user has its own power configuration; however, the entire operating system only has one active power scheme.

A recently started computer at the logon prompt makes the power configuration from the .DEFAULT profile the active power profile. User X logs on to the same computer. The active power profile is now read from user X’s user profile. User X logs off the computer. User X’s power profile remains the active power profile for the computer. Windows XP does not make the .DEFAULT power profile the active power profile. User Y logs on the computer. User Y’s power settings now become the active power profile. User Y’s power settings remain the active power profile after they log off the computer. We restart the computer and, once again, the active power profile is read from .DEFAULT.

00XpPower

 

Group Policy Preferences Power Options

Understanding how Windows XP manages the active power profile helps us better understand how Group Policy Power Option preference items manipulate Windows XP’s active power profile. Let’s start with computer startup. We’ve established that Windows XP reads power settings from the .DEFAULT profile into the active power profile. A Power Option preference item applying to a Windows XP computer does two things: it changes the power settings in the .DEFAULT profile and it makes those new settings the active power profile. A Power Option preference item applying to a user does two things: It changes the power settings in that user’s profile and it makes those new settings the active power profile. Remember there is only one active power profile—it’s the profile that was last made active.

01XpPower

 

Precedence

So predicting GPP Power Option precedence is trivial for computer startup and user logon. But background refresh can introduce some confusion. The computer starts up and receives GPP Power Item A. GPP Power Item A becomes the active power profile. User X logs on and receives GPP Power Item B. The active power scheme changes from A to B. Now, let’s presume that User X is a local administrator. This means User X can change the power settings, which changes the active power settings. So, User X changes the active power profile to power settings C. Now, a Group Policy background refresh occurs.

The background refresh changes the active power profile. And, as we previously covered, the last applied GPP Power item is the active power profile. When we last left our example computer, the active power profile was power settings C, which were created when the user changed their settings using the user interface. If the computer receives GPP Power Item A, and the user receives GPP Power Item B, then what is the resulting power profile? Power item B becomes the active power profile because it is the last power profile that is made active.

Let’s change the scenario. Let’s deploy GPP Power Item A to the computer and not deploy anything to the user because we want to apply a single power profile that affects all the users of the computer. Makes sense right? No, not in this case. The computer starts up and applies GPP Power Item A to .DEFAULT and makes GPP Power Item A the active power profile. User X logs on, and does not have a GPP Power item applied. The user loads their power profile from their user profile, and it becomes the active power profile. The power profile does not change until the user changes it (the need to be a local administrator) or during Group Policy refresh when the computer reapplies the GPP Power item; thus becoming the active power profile. You need combine Group Policy loopback processing (in replace mode) with GPP Power items to create one single GPP Power item that applies to all users of a computer.

Summary

I could easily add another five pages to cover all the different combinations of GPP Power items between computer and user settings. However, the main important thing to remember is there is only one active power profile for the entire computer running Windows XP. And, the active power profile is the power profile that was made active on the computer, regardless if it was done in the context of the user or computer.

— Mike Stephens

Group Policy Preferences Logging and Windows 7

Posted on by
Reply

Back in July of 2007, I posted a blog explaining how to enable Group Policy Preferences debug logging using RSAT. As a refresher, Group Policy Preferences debug logging is enabled through Group Policy administrative templates. Many customers experienced a problem when trying to enable the logging using RSAT and Windows Vista: the policy settings did not exist. You’ll experience the same behavior when using Windows 7 RSAT.

00GPPLogginWin7

The Group Policy Preferences administrative template is not included with Windows 7; however, it is included in Windows Server 2008 R2. The simply solution is copy the ADMX and ADML files from Windows Server 2008 R2 to the Windows 7 computer. Or, you can copy the files from this blog post. The procedure remains the same as it was from Windows Vista. Check out the blog from July 2007 for the detailed procedures.

01GPPLogginWin7

NOTE:
There are some subtle differences between the Vista and Windows 7 Group Policy Preferences administrative templates—no change in functionality—but many string names have changed in the ADL file. Do not try to mix and match the ADMX from one version of Windows with the ADML of another.

— Mike  Stephens

Migrating from PolicyMaker to Group Policy Preferences with GPPMIG

Posted on by
Reply

PolicyMaker customers rejoice—Microsoft has a way for you to migrate from PolicyMaker 2.x to the new Group Policy preferences released with Windows Server 2008 and included in the Remote Server Administration Tools for Windows Vista Service Pack 1 or higher.

Download GPPMIG: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=35791cb6-710b-48c4-aaa1-90db170bcf2a

PolicyMaker to Preferences… how to get there

If you’ve been using PolicyMaker then you already know how to use Group Policy Preferences. It is all managed using the Group Policy Management Console included with Windows Server 2008 or, using Windows Vista Service Pack1 by installing the Remote Server Administration Tools. However, Group Policy preferences cannot process PolicyMaker data and vice versa. Therefore, you need to have a strategy to migrate from PolicyMaker to Group Policy Preferences. Hopefully, this should help. Everything discussed below is also included in the GPPMIG installer as the ‘GPPMIG Migration Guide’.

Prerequisites

I want to take a few minutes to discuss some of the prerequisites before we jump right into the migration strategy. We have two categories Management and Client.

Management

Policymaker’s management looks and feels the same as managing other Group Policy setting. The same look and feel returns using Preferences. One thing to consider is– each instance (PolicyMaker or Group Policy Preferences) cannot edit the others data. For this reason, you may need to leave one or more Windows XP computer, with the PolicyMaker administrative tools installed, until you’ve completed your migration. If your migration follows a staged approach, then you may encounter a small period of time where you may need to manage using both Windows Vista and Windows XP. Or, you may be the weekend warrior type and have your migration complete from Friday to Monday. The choice and freedom are there, but the requirement remains—PolicyMaker administrative additions can only edit PolicyMaker items. Server 2008 and the RSAT tools can only edit Preferences. Read Microsoft Knowledgebase article 941314, Description of Windows Server 2008 Remote Server Administration Tools for Windows Vista Service Pack 1 for more information.

Client

The critical component that actual makes PolicyMaker and/or Preferences work is the client side extensions (CSEs), which you must install on the client computer. The CSEs make normal Group Policy processing PolicyMaker/Preferences aware. The same rules apply to the client portion—PolicyMaker CSEs only process PolicyMaker data and Preference CSEs only process Preference data. Also, installing the Group Policy Preference CSEs automatically removes PolicyMaker CSEs. The new Group Policy preference client side extensions installs on

  • Windows Vista RTM and Service Pack 1
  • Windows Server 2003 Service Pack 1
  • Windows XP Service Pack 2

Both Windows Server 2003 and Windows XP require the installation of XmlLite prior to installing the CSEs. Preference CSEs are included in Windows Server 2008. Read Microsoft Knowledgebase article 943729, Information about new Group Policy preferences in Windows Server 2008 for more information.

Testing

It goes without saying—you can never test enough and this scenario is not any different. Make sure you have backups… and they actually work. If you are going to use GPMC to backup your GPOs, then remember to use the correct version. GPMC backups are not interchangeable. If you backup with pre-Server 2008 GPMC, then you must restore with the same version. Back up some of your most complex or important GPOs and then important them into isolated test GPOs in a test OU with a single user and computer. Run through your entire migration strategy—noting what works and what does not— refining the plan with each pass. All efforts spent in planning usually pay off during implementation.

Group Policy Preference Migration utility

Now that we have the planning stuff out of the way—on to the good stuff. GPPMIG is a console application developed with version 3.0 of the .NET framework. Use GPPMIG to migrate PolicyMaker items to Group Policy Preference items into the same or a different Group Policy object. GPPMIG does not migrate PolicyMaker Application or Mail Profile data as Group Policy Preferences do not included client-side extensions for these items.

What it does

Let us take a few moments to discuss how GPPMIG works. For starters, GPPMIG always uses the domain of the currently logged on user. You’ll want to remember this so you can log on with domain administrator account for the domain GPOs you want to migrate. And, you must be a domain administrator as GPPMIG write to SYSVOL and Active Directory. One last point is that GPPMIG always connects to the PDC of the user domain—for reading and writing to Active Directory and SYSVOL. So, you’ll want to run GPPMIG from a computer close (same subnet) as the PDC emulator.

With GPPMIG, you can target a single GPO to migrate or, you can choose to migrate all GPOs. GPPMIG performs a paged LDAP query to the PDC to retrieves a list of all the Group Policy objects in the user’s domain. GPPMIG then filters out any GPO in the list that is not configured for PolicyMaker items. Then, GPPMIG iterates through each GPO in the final list, looking for PolicyMaker specific client side extensions in each GPO. The entire GPO is evaluated before moving to the next. If a PolicyMaker setting is found, then GPPMIG ensures there is not an equivalent Group Policy Preference configuration, as it will not migrate PolicyMaker items into existing Group Policy Preference items. When GPPMIG completes its search for PolicyMaker items in the GPO, it then updates the Group Policy object to included Group Policy Preference client side extensions and then increases the version number for the user, computer, or both depending on what PolicyMaker items it migrated. In no way does a migration alter any PolicyMaker items for the GPO. All PolicyMaker items remain configured and available in the GPO. GPPMIG creates a migration log in the directory from which it ran.

Usage

You can use GPPMIG to migrate to Group Policy Preferences in staged approach or, you can create brand new GPOs to hold your new Group Policy Preference items and migrate to those new GPOs. The staged approach is a planned migration strategy and is the approach I’ll document here. After reading this, you should be able to alternate this strategy to best suit the needs of your environment. Generally, you’ll migrate from PolicyMaker to Group Policy Preferences in three stages (after you’ve done your testing).

  • Stage 1— Identify GPOs containing PolicyMaker items and use GPMC 1.x to back up those GPOs
  • Stage 2— Migrate PolicyMaker items to Group Policy Preference items in the same or a new Group Policy object. Then, deploy the Group Policy Preference CSEs to your client computers.
  • Stage 3— Confirm Group Policy Preference items migrated and are successfully applying to user and computers. Use GPMC 6.0.0.1 to backup your GPOs (to a different back up location then Stage 1. Then remove PolicyMaker items from GPOs, if applicable

Commands

GPPMIG contains four basic commands:

  • Whatif — display all the Group Policy objects that contain PolicyMaker items
  • Migrate— migrates PolicyMaker items to Group Policy Preference items in the same GPO
  • MigrateTo— migrates PolicyMaker items to Group Policy Preference items to a different GPO
  • Remove— removes PolicyMaker items from a GPO

Stage 1 – Identify PolicyMaker GPOs

Begin your migration process by identifying GPOs containing PolicyMaker items. You can do this by using the –whatif command. Use the –allcommand afterwards to search all the GPOs in the user’s domain or, you can use the –name command and provided the display name of the GPO. Use GPMC to backup all of the GPOs identified to have PolicyMaker items.

Stage 2 – Migrate PolicyMaker Data to Group Policy Preferences

Next, you’ll want to migrate PolicyMaker items to Group Policy Preference items. You have a choice to migrate the setting within the same or to a different Group Policy object.

NOTE:
The migration does not modify PolicyMaker items, regardless of the migration action you choose.

Use the –migrate command to migrate PolicyMaker items to Group Policy Preference items within the same GPO. Use the following syntax:

Gppmig –migrate –name:gpo_name

Alternatively, you replace the –name argument with –all to migrate all the GPOs in the users domain that contain PolicyMaker items.

00GPPMIGcmdprmompt

You may prefer to keep PolicyMaker GPOs separate from Group Policy Preference GPOs. You use the –migrateTo command to accomplish this task

IMPORTANT
You must create the target GPO before using the -migrateTo command. GPPMIG does create the target Group Policy object.

01GPPMIGcmdprmompt

The –migrateTo command requires two additional arguments: -source: and –target: follows by the display name of the Group Policy object. Enclose the name of the GPO in quotes if the name contains spaces. Also, the –migrateTo command does not support the –all argument.

Deploy GPP Client

You’re now ready to deploy the Group Policy Preference client-side extensions after you’ve migrated all of your GPOs to include Group Policy Preference items. The migration does not modify any PolicyMaker items; so clients with the PolicyMaker CSE and the Group Policy preference CSEs process the same data

NOTE:
GPPMIG does not migrate Application or Mail PolicyMaker items. Therefore, Group Policy Preference CSEs do not apply these items to users or computers. Leave the PolicyMaker CSE installed on computers that require these items and do not install the Group Policy Preference CSEs as the installation removes PolicyMaker CSEs).

You can apply Group Policy Preferences to several Microsoft operating systems. The minimum operating system requirements are:

  • Windows Vista RTM or Windows Vista Service Pack 1 (32 or 64-bit)
  • Windows Server 2003 Service Pack 1 or later (32 or 64-bit)
  • Windows XP Service Pack 2 or later (32 or 64-bit)

Group Policy Preference client-side extensions are included in Windows Server 2008. You can use the links above to download the client-side extension installation packages. Or, you can download the extensions as an optional update from Windows Update.

IMPORTANT
Remember– installing Preference client-side extensions removes PolicyMaker Client Side Extensions.

Stage 3

The last stage in the migration process involves verifying your items migrated and apply correctly. Use GPMC to view the Group Policy object to which you migrated your items. Click the Settings tab to show the Preference items included in the GPO.

00GPPMIGGPMC

Next, you’ll want to apply the Group Policy object to your client computers. For in-place migrations, you’ll want to apply the GPO to computers using PolicyMaker CSEs and computers using Preference CSEs. Also verify user PolicyMaker and Preference items apply to the appropriate user. GPOs that are targets of in-place migrations should apply items to both (PolicyMaker and Preferences). Source-target migrations migrate the PolicyMaker items to Preference items in the newly created GPO. This allows you to keep your existing PolicyMaker GPOs separate from your Preference GPOs. You apply GPOs containing Preference items to computers are users using the Group Policy Preference CSEs.

Use the Resultant Set of Policy (RSOP) management console to confirm PolicyMaker items are applying to computers or users. Use the Group Policy Results feature within GPMC to confirm Preference items are applying to computers or users.

01GPPMIGGPMC

The actual migration from PolicyMaker to Group Policy Preferences is complete. Computers running either Preferences or PolicyMaker should be applying their respective items. Source-target migrations contain both PolicyMaker and Preference items. After you’ve transitioned your client to use the Group Policy Preference CSEs, you’ll want to remove the PolicyMaker data, which remains in the GPO. You can use GPPMIG with the -remove option to remove overlapping PolicyMaker and Preference items.

02GPPMIGcmdprmompt

NOTE:
GPPMIG does not remove PolicyMaker Application and Mail items from the Group Policy object.

Source-target Migrations do not included PolicyMaker items. Therefore, once you’ve completed transitioning your client computers to use Preference CSEs, you can delete the source version of the GPO, which contains only PolicyMaker items.

Conclusion

You should consider backing up your Group Policy objects after you’ve completed your migration and cleanup of Group Policy objects. Use the Group Policy Management Console included in Windows Server 2008 and the Remote Server Administration tools to backup all of your Group Policy objects before you proceed with any further changes.

– Mike Stephens

Using Group Policy Preferences to Map Drives Based on Group Membership

Posted on by
Reply

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.

00-mapped-drivesNewly 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.01-mapped-drivesLater, 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.02-mapped-drivesConfiguring 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.03-mapped-drivesUsing 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.04-mapped-drivesThe 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).05-mapped-drives

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.06-mapped-drivesThe 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.07-mapped-drivesThis 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 Stephens

Enabling Group Policy Preferences Debug Logging using the RSAT

Posted on by
Reply

Sometimes you need to enable additional logging when you are troubleshooting a particular component in Windows. Group Policy Preferences includes the ability to create verbose debug logging for each included client-side extensions. You activate Preference debug logging through Group Policy. Preference debug logging policy settings are located under the Computer Configuration\Policies\Administrative Templates\System\Group Policy node when editing a Group Policy object.00-gpp-debugYou can individually enable each preference client-side extension. Logging and tracing entries provide you with a several configuration options including what type of data to write to the event logs (Informational, Errors, Warnings, or all), enable trace logging and the location of the trace log file, and the size of the file.01-gpp-debugYou can configure the location of the trace files; however, keep in mind that file system permissions changed on Server 2008 and Windows Vista. Make sure permissions do not interfere with creating the log file. You’ll notice the default location for all three log files is
%COMMONAPPDATA%\GroupPolicy\Preference\Trace. The variable
%COMMONAPPDATA% is not recognized by Windows, however; it is meaningful to Preference client-side extensions. Preference client-side extensions recognize this variable and expand it according to operating system on which the client-side extension is installed. For Windows Server 2003 and Windows XP, %COMMONAPPDATA% expands to
%SYSTEMDRIVE%\Documents and Settings\All Users\Application Data. The equivalent path for Windows Server 2008 and Windows Vista is %SYSTEMDRIVE%\ProgramData (this folder is hidden by default, but you can manually type the path in Windows Explorer).

Logging and tracing missing from RSAT

You’ve installed Windows Vista Service Pack 1; you’ve downloaded and installed RSAT. You try to enable Logging and tracing, but it’s not there. Well, there is a reason for this.02-gpp-debugAdministrative Templates show in the user interface because of two files: an .ADMX and an .ADML. Logging and tracing does not appear because the GroupPolicyPreferences.admx and .adml files are not included with RSAT. You need to copy these to your local or central store.

You have two options as to how to get a copy of the Group Policy Preferences ADMX files. You can download the entire Windows Server 2008 ADMX file set, or you can download just the Group Policy Preferences ADMX file set. You can download the installer for either of these file sets from http://www.microsoft.com/downloads/details.aspx?FamilyID=927fc7e3-853c-410a-acb5-9062c76142fa&DisplayLang=en. These MSI applications install their contents to the default location of %PROGRAMFILES%\Microsoft Group Policy.

The Group Policy Preferences ADMX installation creates an additional folder named Preferences, which contains a single ADMX file with multiple locale folders. You want to copy the GroupPolicyPreferences.admx file into your policydefinition folder. If you are using a central store, then you must copy the file to the policydefinition folder on SYSVOL, otherwise; copy the file to your local store. You’ll then want to copy the .ADML file to the corresponding locale folder located in your policydefinition folder. See the Managing Group Policy ADMX Files Step-by-step guide for more information on managing ADMX Files and creating a central store. After you’ve copied both the .ADMX and .ADML file into the proper store, then close all instances of GPMC and its editor. Restart GPMC and edit the GPO in which you want to add Logging and tracing policy settings. Expand the nodes under Computer Configuration and you should now see Logging and Tracing options.

– Mike Stephens

Managing Power with Group Policy: Part 3 of 3

Posted on by
Reply

It’s time we wrap up our discussion on managing power using Group Policy. The previous blog posts discussed managing power on Windows Vista (and Windows Server 2008). Today, I’ll cover how we can achieve the equivalent for Windows XP.

The key to managing power on Windows XP is Group Policy preferences. The Group Policy Management Console (GPMC) included with Windows Server 2008 and (soon to be released) Remote Server Administration Tools contains the management portion of portion of preferences. Next, you need preference client side extensions that allow Windows XP to process Group Policy objects that contain preference configuration data. Group Policy preferences client side extensions are available from Microsoft for Windows Vista, Windows Server 2003, and Windows XP.

Preferences provide two preference items you can use to configure power on Windows XP (or Windows Server 2003 and Windows Server 2003 R2). The first of these items is the Power Option item. Figure 1 shows you the properties on a Power Option preference item. This is one of the great features with preferences—the configuration screen closely resembles the screen you actually use on the operating system.00-manage-power-p3The Power Option preference item gives you the ability to configure hibernation, prompting for password when the computer resumes. Also, you can configure the Power button action when you close the lid of the computer (laptop), press the power button, or press the sleep button.

One of the cool things about preferences is you have control over which settings you want to configure and ones that you do not. Figure 1 shows each setting in the preference item underlined with a single green line. This means the setting in the item is enabled and the setting applies as configured. Using Figure 1 as an example, the Always show icon on the taskbar is enabled but, the checkbox is not selected. During Group Policy processing, this preference item configures Always show icon on the taskbar, Prompt for password when computer resumes from standby, and Enable Hibernate as off. This result is because the setting in the item was enabled (green underline) and the checkbox is cleared (off). This is a very powerful feature because it allows you full control over the setting you want to configure and the setting that you do not. Let’s look at another example.01-manage-power-p3The above image shows another configured Power Options preference item. In this example, Always show icon on the taskbar has a red dashed underline, which means the setting is disabled. This means when Group Policy applies this preference item, Prompt for password when computer resumes from standby and Enable hibernation are enabled and, Always show icon on the taskbar is ignored. You enable and disable a setting by using the function keys on the keyboard.

  • F5 enables all the settings in a preference item
  • F6 enables the currently selected setting in a preference item
  • F7 disables the currently selected setting in a preference item
  • F8 disables all the setting in a preference item

NOTE:
Preference items are not policy settings, which means they are not enforced—just applied. Users with the proper privileges may have the ability to change the preference setting to another selection. However, preference item settings return on the next Group Policy refresh, unless configured otherwise.

The other power preference item is Power Scheme. The Power Scheme preference item allows you to create, modify, and delete power schemes. This allows you to configure a Windows XP computer to use one of the pre-existing power schemes or modify the settings included in one of the pre-existing power schemes or, just you create your own—it is your choice. Each power scheme has settings for two options: Plugged in or Running on batteries. From there, you define the time out settings for turning off monitors, hard disks, system standby and system hibernate. The Power Scheme preference item has the same enable/disable feature as the Power Option preference item and behaves in the same fashion.

The one difference with the Power Schemes preference item is the Action field. The action field determines the action Group Policy processing applies to the specific preference item. Configuring a Power Scheme preference item to Create; does just that—it creates a new power scheme. However, if, on the computer applying the preference item, a power scheme with the same name exists, the preference item does nothing. Delete and Update do just what they describe—delete and update. However, Update does provide additional functionality other than updating an existing power scheme with new settings. If you configure your Power Scheme preference item to update a power scheme that does not exist on the applying computer, then a new power scheme is created with that name. Lastly, configuring the preference item with Replace has similar results to using Update. When using Update, the Power Scheme preference item only updates the enabled settings within the preference item on the existing named power scheme—leaving all other settings as they are. Replace, however; actually deletes the named power scheme from the computer and then creates a new power scheme based on the settings configured in the Power Scheme preference item.

Other things to remember with power management preference items:

  • You can configure power management preference items in both computer and user configurations. Understand, user configuration apply after computer configuration. This results in the user settings replacing the current power settings, which could have been from another preference item.
  • Local Administrators are Administrators. This means they can change their power configuration. Standard users cannot.
  • When Group Policy applies power management preference items; those items become the current power management scheme—even after the user logs off.
  • Power management preferences item support background refresh—your settings can change.

That wraps up Managing Power with Group Policy. Three blog entries, six categories, 34 policy settings, and two preference items later, it should be easy to see how combining these Group Policy features could save your company significant resources. It may be a good time to review how you could implement some of these features and savings you may gain.

Managing Power with Group Policy: Part 1 of 3
Managing Power with Group Policy: Part 2 of 3
Managing Power with Group Policy: Part 3 of 3

-Mike Stephens

Introducing Group Policy Preferences

Posted on by
Reply

Have you ever wanted to map a drive for specific users at logon—without using a logon script? Have you ever wanted to change the local administrator’s password on all your client computers? Have you ever wanted to add items to a user’s Start menu? Now you can with Windows Server 2008, which includes Group Policy preferences.

What are Group Policy preferences? Group Policy preferences allow administrators to configure and deploy Windows and application settings that were previously unavailable using Group Policy. The Windows Server 2008 Group Policy Management Console (GPMC) includes Group Policy preferences, which are available when editing domain-based Group Policies. Also, you can manage Group Policy preferences from a Windows Vista Service Pack 1 computer by installing the Remote Server Administration Tools (RSAT), which included the updated version of GPMC.

You first notice a change in the namespace and node structure when editing a domain-based Group Policy object with GPMC. Computer and User Configuration remain; however there are now two categories under each configuration: Policies and Preferences.00-gpprefThe Policies node contains the familiar node structure found when editing earlier versions of Group Policy. The Preferences node contains all the preference settings, which are a categorized into Windows Settings and Control Panel Settings.01-gpprefWith Group Policy preferences there are many different ways to accomplish a specific task. Each Group Policy preference extension provides configuration properties specific to the extension and common among most preference extensions.02-gpprefPreference items allow you to fine tune how they apply to users and computer by offering sophisticated targeting features. Using the targeting editor, you can create various targeting conditions to ensure the correct preference item applies to the correct user or computer.03-gpprefThe Client-Side Extensions for GP Preferences are included in Windows Server 2008, and down-level versions will be available as a separate download for:

  1. Windows XP Service Pack 2 and above
  2. Windows Vista RTM and above
  3. Windows Server 2003 SP1 and above

Finally, it’s important to understand that Group Policy preferences are just that – preferences. Unlike policy-enabled components that apply managed policy settings, preferences simply configure the settings as if a person did it. Users can change these settings until the next refresh of Group Policy. For example, when you use Group Policy to configure a screensaver, the option to change it is unavailable (grayed out) for the user. When using preferences, the screensaver is preconfigured per the preference settings; however, the user still has the ability to change the settings (until the next Group Policy refresh—depending on how you configure the preference item).

You can read more details on Group Policy preferences by downloading the Group Policy preferences whitepaper from the Microsoft Download Center (http://go.microsoft.com/fwlink/?LinkId=103735)

– Mike Stephens