While the new capabilities of GPOs were significant when first introduced with Active Directory, the obvious things that were lacking were good tools for managing them. The dual storage nature of GPOs creates a lot of problems. Initially, Microsoft did not provide a scriptable interface for accessing and manipulating GPO settings. Additionally, there were no tools for copying or migrating GPOs from a test environment to production. Back then the primary tool for managing GPOs was the Group Policy Editor (GPE), now known as the Group Policy Management Editor (GPME). The main function of the GPME is to modify GPO settings; it does not provide any other management capabilities.

Microsoft realized these were major issues for Group Policy adoption, so it developed the Group Policy Management Console (GPMC) with the release of Windows Server 2003. The GPMC is an MMC snap-in that provides the kitchen sink of GPO management capabilities: you can create, delete, import, copy, back up, restore, and model GPO processing from a single interface. Perhaps what is even better is the scriptable API that comes with the GPMC. Pretty much every function you can accomplish with the GPMC tool, you can do via a script.

In versions prior to Windows Server 2008, GPMC is an out-of-band download that can be obtained from Microsoft. In Windows Server 2008 and later, Group Policy Management is a feature, and it can be installed on Windows client computers as part of the Remote Server Administration Tools (RSAT). Note that throughout the book we use the name “Group Policy Management” instead of GPMC in order to match up with the shortcut and menu names used by Windows.

Another tool that you can download from the Microsoft website is GPInventory. This is an incredibly useful tool that will allow you to perform a software inventory for users and computers in a domain or OU, and to track information about the rollout of GPOs in AD, such as computers that have not applied new GPO information. Additionally, the Group Policy Best Practice Analyzer (GP BPA) is a free download that can help you identify Group Policy configuration errors within your environment.

The majority of solutions presented in this chapter use the Group Policy Management snap-in. Most of the command-line solutions we provide will use one of the scripts provided in the Group Policy Management Console Sample Scripts install available from the Microsoft Download Center. A whole host of precanned scripts have been written already, in a mix of VBScript and JScript, which serve as great command-line tools and good examples to start scripting GPOs. These scripts are available by default in the C:Program Files (x86)Microsoft Group PolicyGPMC Sample Scripts directory on a Windows Server 2012 server that has had the sample scripts installed on it. You can execute them in one of two ways, either by using cscript:

> cscript listallgpos.wsf

or, if you make cscript your default WSH interpreter, by executing the file directly. To make cscript your default interpreter, run this command:

> cscript //H:cscript

You want to find all of the GPOs that have been created in a domain.

See Introduction for more on how GPOs are stored in Active Directory.

Get-GPO cmdlet reference; “Group Policy Cmdlets in Windows PowerShell”

You want to create a Group Policy Object within Active Directory.

When you create a GPO through the Group Policy Management snap-in, it is initially empty with no settings or links configured. See Modifying the Settings of a GPO for more on modifying GPO settings, and Creating a GPO Link to an OU for more on creating a link.

New-GPO cmdlet reference; “Group Policy Cmdlets in Windows PowerShell”

You want to copy the properties and settings of one GPO into another GPO.

Prior to the GPMC tool, two of the biggest problems with managing GPOs in large environments were migrating GPOs from one forest to another and copying GPOs from one domain to another within the same forest. It is common to have a test forest where GPOs are initially created, configured, and tested before moving them into production. The problem before GPMC was that once you had the GPO the way you wanted it in the test forest, there was no easy or well-publicized way to move it to the production forest.

With the GPMC and the Group Policy Management snap-in, you can simply copy GPOs between domains. You can also import GPOs, which is similar to a copy operation. A GPO import uses a backup of the source GPO in order to create the new GPO. See Importing Settings into a GPO for more information on importing a GPO.

Some properties of GPOs, such as security group filters, UNC paths, and Restricted Groups, may vary slightly from domain to domain; for example, a logon script that runs from \SERVERAshare in the source domain may need to run on \SERVERBshare in the target domain. In that case, you can use a GPMC migration table to help facilitate the transfer of those types of references to the target domain. For more information on migration tables, see the GPMC help file and Creating a Migration Table.

Importing Settings into a GPO for importing a GPO; Creating a Migration Table; Copy-GPO cmdlet reference

You want to delete a GPO.

When you delete a GPO through the Group Policy Management snap-in, it attempts to find all links to the GPO in the domain and will delete them if the user has permissions to delete the links. If the user does not have the necessary permissions to remove the links, the GPO will still get deleted, but the links will remain intact. Any links external to the domain the GPO is in are not automatically deleted. For this reason, it is a good practice to view the links to the GPO before you delete it. Links to deleted GPOs show up as “Not Found” in the Group Policy Management snap-in.

Listing the Links for a GPO for viewing the links for a GPO; Remove-GPO cmdlet reference

You want to view the settings that have been defined in a GPO.

The Group Policy Management snap-in can generate an XML or HTML report that contains all of the settings in a GPO. See Modifying the Settings of a GPO for more information on how to modify GPO settings.

Get-GPOReport cmdlet reference

You want to modify the settings associated with a GPO.

Modifying GPOs has historically been performed from a GUI. Up until the Set-GPRegistryValue cmdlet was introduced, there wasn’t an easy way to modify a GPO from a command-line environment. Note that the Set-GPRegistryValue cmdlet is restricted to registry settings only and thus isn’t as fully featured as the Group Policy Management Editor.

Copying a GPO for copying a GPO; Viewing the Settings of a GPO for viewing the settings of a GPO; Importing Settings into a GPO for importing settings into a GPO; Set-GPRegistryValue cmdlet reference

You want to import settings from one GPO to another.

The Group Policy Management import function uses a backup of the source GPO to create the new “imported” GPO. This means you must first back up the source GPO. You can then import the settings from that GPO into a new GPO, which may be in the same domain or in a completely different forest. Importing a GPO is a great way to help facilitate transferring GPO settings from a test environment to production.

Some properties of GPOs, such as security group filters and UNC paths, may vary slightly from domain to domain; a logon script that runs from \SERVERAshare in the source domain may need to run on \SERVERBshare in the target domain, for example. In this case, you can use a migration table to help facilitate the transfer of those kinds of references to the target domain. For more information on migration tables, see Creating a Migration Table.

Copying a GPO for copying a GPO; Creating a Migration Table; Backing Up a GPO for backing up a GPO; Import-GPO cmdlet reference

You want to create a migration table to assist in copying or migrating a GPO from one domain or forest to another.

One of the convenient features of the Group Policy Management snap-in is the ability to copy a GPO’s settings from one GPO to another, or to migrate GPOs between domains or forests. In some cases, certain entries in the GPO may need to be modified to suit the needs of the destination domain or forest. For example, a UNC for user home directories will likely need to be modified to correspond to a server or DFS share in the destination, as well as individual user or group names. To address this need, you can create and populate a migration table to automatically transform the necessary entries on one or more GPOs.

Copying a GPO for more on copying a GPO; Importing Settings into a GPO for information on importing settings into a GPO

You want to deploy settings via Group Policy that are not covered by the default set of GPO templates that come with Active Directory.

Windows comes preloaded with a number of default templates that define a number of settings that can be controlled via GPO. To control and deploy settings for additional or third-party applications, you’ll need to create your own custom ADM or ADMX file to manage the settings you require. You’ll create this file in Notepad or another simple text editor, and save it as <FileName>.adm or <FileName>.admx. For example, the following ADMX file will add a new search provider to Internet Explorer using a customized ADMX file:

<?xml version="1.0" encoding="utf-8"?> <policyDefinitions
  xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="1.0"
  schemaVersion="1.0"
xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
  <policyNamespaces>
    <target prefix="search" namespace="Microsoft.Policies.search" />
    <using prefix="inetres" namespace="Microsoft.Policies.InternetExplorer" />
  </policyNamespaces>
  <resources minRequiredRevision="1.0" />
  <policies>
    <policy name="PopulateSearchProviderList_1" class="User"
      displayName="$(string.PopulateSearchProviderList)"
      explainText="$(string.IE_Explain_PopulateSearchProviderList)"
      key="SoftwarePoliciesMicrosoftInternet ExplorerSearchScopes">
      <parentCategory ref="inetres:InternetExplorer" />
      <supportedOn ref="inetres:SUPPORTED_IE7Vista"/>
      <enabledList>
        <item key="SoftwarePoliciesMicrosoftInternet ExplorerSearchScopes"
          valueName="Version">
          <value>
            <decimal value="VERSION" />
          </value>
        </item>
        <item key="SoftwarePoliciesMicrosoftInternet
          ExplorerSearchScopesSUBKEY1" valueName="DisplayName">
          <value>
            <string>NAME1</string>
          </value>
        </item>
        <item key=" SoftwarePoliciesMicrosoftInternet
          ExplorerSearchScopesSUBKEY1" valueName="URL">
          <value>
            <string>URL1</string>
          </value>
        </item>
      </enabledList>
    </policy>
    <policy name="PopulateSearchProviderList_2" class="Machine"
      displayName="$(string.PopulateSearchProviderList)"
      explainText="$(string.IE_Explain_PopulateSearchProviderList)"
      key="SoftwarePoliciesMicrosoftInternet ExplorerSearchScopes">
      <parentCategory ref="inetres:InternetExplorer" />
      <enabledList> Insert same as user policy above </enabledList>
    </policy>
  </policies>
</policyDefinitions>

In addition to the ADMX file, you will need to create an ADML file using a format similar to the following:

<?xml version="1.0" encoding="utf-8"?>
  <policyDefinitionResources xmlns:xsd=http://www.w3.org/2001/XMLSchema
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="1.0"
schemaVersion="1.0"
    xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
    <displayName>enter display name here</displayName>
    <description>enter description here</description>
    <resources>
      <stringTable>
        <string id="PopulateSearchProviderList">Populate List of search
providers</string>
        <string id="IE_Explain_PopulateSearchProviderList">
This policy setting will allow you to populate a list of search providers that 
will be displayed in Internet Explorer's search box. If you enable this policy 
setting and if the "Restrict search providers to a specific list of search
providers" Group Policy setting is enabled, this list will be the only list 
that appears in the Internet Explorer drop-down list. If the "Add a specific 
list of search providers to the user's search provider list" Group Policy 
setting is enabled, this list will be added to the user's list of search 
providers. If you disable this policy setting or do not configure it, 
users will have complete freedom to create their own search provider list.
</string>
      </stringTable>
    </resources>
  </policyDefinitionResources>

When you create a custom ADMX file, save it to the %windir%policydefinitions folder; the ADML file will be saved in the %windir%policydefinitions<Definition Language> folder. After saving the files, you can edit a GPO to use the new settings. The templates will automatically populate in the Administrative Templates section of the GPO.

“Managing Group Policy ADMX Files Step-by-Step Guide”

You want to assign either user logon/logoff scripts or computer startup/shutdown scripts in a GPO.

When you assign a script in a GPO, you can reference a script that either is stored locally on the domain controller somewhere under the SYSVOL share or is stored in a UNC path to a remote fileserver. The default storage location is in the <DomainName>SYSVOL<DomainName>scripts folder—for example, \adatum.comsysvoladatum.comscripts.

You want to install an application on a group of computers using a GPO.

Installing applications with a GPO is a powerful feature, but you must be careful about the impact it can have on your network throughput and clients. If the MSI package you are installing is large in size, it will take a while for it to download to the client computer. This can result in sluggish performance on the client, especially over a heavily utilized connection. (Software installation does not occur over slow links, by default.) You’ll also want to make sure you’ve thoroughly tested the application before deployment. After you’ve configured the GPO to install an application, it will be only a short period of time before it has been installed on all targeted clients. If there is a bug in the application or the installer program is faulty, the impact could be severe to your user base and support staff alike.

Your two options for deploying an application are to assign it or to publish it. If you assign an application using the “deploy at logon” option, it will be installed automatically on the targeted clients when users log on to those machines. If you publish an application or assign it without choosing this option, it will be installed the first time a user double-clicks on a shortcut to the application or attempts to open a file that requires the application. A published application also can be installed manually from the Programs and Features applet in the Control Panel on the target computers. You can assign an application to both user and computer objects, but you can publish applications only to users.

You want to disable either the user or the computer settings of a GPO.

GPOs consist of two parts, a user section and a computer section. The user section contains settings that are specific to a user that logs in to a computer, while the computer section defines settings that apply to the computer regardless of which user logs in. You can enable or disable either the user configuration or the computer configuration section of a GPO, or both. By disabling both, you effectively disable the GPO. This can be useful if you want to stop a GPO from applying settings to clients, but you do not want to delete it, remove the links, or clear the settings.

Disabling the user configuration or the computer configuration is useful in environments that have separate OUs for computers and users. Typically, you would disable the computer configuration for GPOs linked to the users’ OU, and vice versa. Disabling half of the GPO in this way makes GPO processing a tiny bit more efficient but likely will have almost no impact on overall performance.

“Group Policy Cmdlets in Windows PowerShell”; MSDN: GPMGPO.SetUserEnabled; MSDN: GPMGPO.SetComputerEnabled

You want to list all of the links for a particular GPO.

See Introduction for more information on GPO linking.

Introduction; Creating a GPO Link to an OU for creating a GPO link to an OU

You want to apply the GPO settings to the users and/or computers in an OU. This is called linking a GPO to an OU.

Linking a GPO is the process whereby you assign a scope of management (SOM), which can be an OU, site, or domain. The solutions show how to link a GPO to an OU, but they easily could be modified to link to a site or domain.

See Linking a GPO to an OU for details on how to link an OU by modifying the gpLink attribute, instead of using the Group Policy Management interface.

New-GPLink cmdlet reference; MSDN: GPM-SOM.CreateGPOLink

You want to block inheritance of GPOs on an OU.

By default, GPOs are inherited down through the directory tree. If you link a GPO to a top-level OU, that GPO will apply to any objects within the child OUs. Sometimes that may not be what you want, and you can disable inheritance as described in the solutions.

Try to avoid blocking inheritance when possible because it can make determining what settings should be applied to a user or computer difficult. If someone sees that a GPO is applied at a top-level OU, he may think it applies to any object under it. Using the Resultant Set of Policies (RSoP) snap-in can help identify what settings are applied to a user or computer (see Simulating the RSoP).

Simulating the RSoP; Set-GPInheritance cmdlet reference; MSDN: GPMSOM; MSDN: GPOInheritanceBlocked; MSDN: GPMDomain.GetSOM

You want to ensure that a GPO’s settings are enforced regardless of any Block Inheritance settings that have been enforced farther down the scope of management.

As a counterpoint to the ability to block inheritance of a GPO for a particular site, domain, or OU, an administrator can configure a particular GPO link as Enforced, meaning that the settings contained in that GPO will be configured for that SOM regardless of the presence of any Block Inheritance configuration. This is useful in a decentralized environment, for example, where a central IT department has configured a certain Group Policy baseline that it wishes to enforce regardless of what individual departments may have configured on their own. Just like security filtering and Block Inheritance, though, we recommend that you use this function sparingly, as it can create complex troubleshooting issues when trying to determine where and how the Group Policy application is failing.

Blocking Inheritance of GPOs on an OU; Set-GPLink cmdlet reference; MSDN:IGPMSearchCriteria; MSDN:GPMC Object Model

You want to configure a GPO so that it applies only to members of a particular security group.

You can use security filtering to restrict the users, groups, or computers that a GPO applies to by granting or denying the Apply Group Policy permission on the ACL of the GPO. By default, Authenticated Users are granted the Apply Group Policy right on all new GPOs, so you will also need to remove this right if you want to restrict the GPO to be applied only to members of one specific group.

As a rule, you should avoid using Deny permissions as part of any custom security filter, because this can lead to confusion with accounts that are members of groups with conflicting filter settings. For example, if a user is a member of a group that has Deny set in the filter and is also a member of a group that is allowed to apply the policy, the Deny setting will always win. This can be difficult to troubleshoot, particularly if nested group memberships are involved.

Set-GPPermission cmdlet reference;MSDN: GPM.CreatePermission; MSDN: GPMGPO.GetSecurityInfo

You want to delegate permissions on GPOs and related tasks within Active Directory.

In addition to using Active Directory users and groups to control how GPOs are applied within a site, domain, or OU, you can also use ACLs to delegate permissions over GPOs to allow you to decentralize the administration of them in your organization.

You can delegate the ability to do the following:

While the ability to delegate administration in this manner is quite simple to implement, it’s critical that you fully understand the security implications that it carries. For example, the ability to link GPOs to an entire site or domain should be granted only to highly trusted administrators as it can have far-reaching implications for the performance and behavior of your network.

MS KB 250842 (Troubleshooting Group Policy Application Problems); Applying a Security Filter to a GPO for more on using security filtering to control GPO behavior

You want to import a security template into a GPO.

Rather than manually configuring the plethora of security settings available in Windows, you can use a template. Windows 2003 shipped with several templates, including templates for high-security workstations and high-security domain controllers. However, Windows 2008 and later have scaled back the number of default templates and now only include three templates: a default base template, a default domain controller template, and a default member server template. Each template is useful in a scenario where you need to reset security settings back to the default state.

You want to create a WMI filter.

WMI filters provide another way to filter how GPOs are applied to clients. WMI filters live in Active Directory as objects under the WMIPolicy container within the System container for a domain. A WMI filter consists of a WMI Query Language (WQL) query that, when linked to a GPO, will be run against all clients that the GPO applies to. If the WQL returns a true value (i.e., it returns nonempty results from the WQL query), the GPO will continue to process. If the WQL query returns false (nothing is returned from the query), the GPO will not be processed.

The great thing about WMI filters is that the vast amount of information that is available in WMI on a client becomes available to filter GPOs. You can query against CPU, memory, disk space, hotfixes installed, service packs installed, applications installed, running processes—the list goes on and on.

For example, creating a GPO that applies only to computers that are running a specific version of Windows would have been really difficult to accomplish without a WMI filter. Either you would have had to create a security group that contained all of those computers as members (and apply a security filter) or you would have had to move all of those workstations to a particular OU. With a WMI filter, this becomes trivial to create. Bear in mind, however, that there is client performance overhead associated with WMI queries, as each computer will need to process the WMI query to determine whether a particular GPO should or should not be applied. Here is a sample WQL query that would return true when run on a Windows Server 2012 Datacenter server:

select * from Win32_OperatingSystem↵
where Caption = "Microsoft Windows Server 2012 Datacenter"

The introduction of Group Policy Preferences created significant new options in terms of how GPOs can be targeted and filtered. Prior to the introduction of Group Policy Preferences, you were limited to filtering using only WMI filters to control whether the entire GPO is applied. With WMI filters, you cannot specify individual settings within a GPO. Group Policy Preferences, on the other hand, support item-level targeting, where individual settings can be targeted based on criteria such as IP address, whether that machine is a laptop or desktop, security group membership, and so on.

Applying a WMI Filter to a GPO for applying a WMI filter to a GPO; MSDN: Querying with WQL

You want to apply a WMI filter to a GPO.

You can link only one WMI filter to a GPO at any time. This is not an overly restrictive limitation, though, because you still can link more than one GPO to a site, domain, or OU. If you need multiple WMI filters to apply to a GPO, copy the GPO and apply a different WMI filter to it. See Creating a WMI Filter for more information on WMI filters.

You want to configure a GPO to use loopback processing that will enforce consistent computer settings regardless of which user logs on to a computer.

GPOs are applied to user/computer combinations on an Active Directory network based on the site, domain, and OU that the user and computer objects belong to. If the user and computer are located in two separate locations, the user will receive the GPOs that apply to the user’s container combined with those that apply to the computer’s container. However, there may be cases where you want a user to receive GPOs based solely on the location of the computer objects. In this case, you will enable loopback processing in one of two modes:

MS KB 231287 (Loopback Processing of Group Policy)

You want to back up a GPO.

The Group Policy Management snap-in and the Backup-Gpo cmdlet both provide a way to back up individual (or all) GPOs. A GPO backup consists of a set of folders and files that catalog the GPO settings, filters, and links, and is created in the backup location you specify. You can back up a GPO to a local drive or over the network to a fileserver. Restoring a GPO is just as easy and is described in Restoring a GPO.

In legacy versions of Windows, the only way to back up GPOs was by backing up the System State on a domain controller. The System State includes Active Directory and the SYSVOL share (both components are needed to completely back up a GPO). To restore a GPO using this method, you’d have to boot into DS Restore mode and perform an authoritative restore of the GPO(s) you were interested in. Needless to say, the methods are significantly easier now.

A good practice is to back up your GPO backups. Since all the backup information is captured in a series of files, you can back up that information to media, which provides two levels of restore capability. You could restore the last backup taken, which could be stored on a domain controller or fileserver, or you could go to tape and restore a previous version.

In the folder you specify to store the GPO backups is a list of folders that have GUIDs for names. This does not make it very easy to distinguish which backups are for which GPOs. A quick way to find that out is to use the querybackuplocation.wsf script. This will list each folder GUID name and the corresponding GPO it is for:

> querybackuplocation.wsf "c:gpmc backups"

Restoring a GPO for restoring a GPO; Backup-GPO cmdlet reference; and MSDN: GPMGPO.Backup

You want to restore a GPO.

To restore a GPO using the Group Policy Management snap-in, you first need a valid backup of the GPO. The procedure for backing up a GPO is described in Backing Up a GPO. You can then restore the GPO, even if the GPO has been deleted. To restore a deleted GPO, use the following steps:

If you don’t have a valid backup of the GPO, but you do have another GPO that is identical or similar to the one you want to restore (perhaps in another forest), you can copy that GPO to replace the one you want to restore.

Keep in mind that restoring a GPO does not restore the links that were associated with that GPO, since the gpLink attribute is configured on the container that the GPO was linked to and not the container itself. See Copying a GPO for more on copying GPOs.

Copying a GPO for copying a GPO; Backing Up a GPO for backing up a GPO; Restore-GPO cmdlet reference; MSDN: GPMDomain.RestoreGPO

You want to simulate the Resultant Set of Policies (RSoP) based on OU, site, and security group membership. This is also referred to as Group Policy Modeling.

You can simulate the RSoP based on user-defined OU, site, group, and domain membership. This is very powerful because it allows you to create one or more GPOs, simulate them being applied to a user and computer, and determine whether any changes are necessary before deployment.

Viewing the RSoP for viewing the RSoP

You want to view the actual RSoP for a user and computer. This is a great tool for determining whether policies are being applied correctly on a client.

If you implement more than a few GPOs, it can get confusing as to what settings will apply to users. To address this problem, you can query the resultant set of policies on a client to determine which settings have been applied.

The registry on the target computer is another source of information. You can view the list of policies that were applied to the computer by viewing the subkeys under this key:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionGroup PolicyHistory

The settings that were applied are not stored in the registry, but you can obtain the GPO name, distinguished name, SYSVOL location, version, and where the GPO is linked.

Finally, you can also rely on the Windows Event Logs for troubleshooting. Since Windows Vista, the logs have been improved greatly and now include a Group Policy operational log. Additionally, the source name for events now uses “Group Policy,” which makes it easier to track down Group Policy events.

Simulating the RSoP for simulating the RSoP

You’ve made some changes to a GPO and want to apply them to a computer by refreshing the group policies for the computer.

By default, Group Policy settings will refresh automatically every five minutes on a domain controller and every 90 minutes (with an additional random offset between zero and 30 minutes) on clients and member servers. To force GPO settings to refresh sooner than that, you will need to run the gpupdate utility on the client computer. With gpupdate, you can force all settings to be applied with the /force option (the default is only changed settings). You can apply the computer or user settings of GPOs using the /target option, and you can force a logoff or reboot after the settings have been applied using the /logoff or /boot option. Windows Server 2012 introduced a remote Group Policy update feature built into the Group Policy Management snap-in. (Right-click on an OU and you can force a Group Policy update on all computers in the OU.)

Invoke-GPUpdate cmdlet reference

You’ve made changes to the Default Domain Security Policy, Default Domain Controller Security Policy, or both, and now you want to reset them to their original configuration.

If you’ve made changes to the default GPOs in the Windows Server 2003 or later version of Active Directory and would like to revert back to the original settings, the dcgpofix utility is your solution. dcgpofix works with a particular version of the schema. If the version it expects to be current is different from what is in Active Directory, it will not restore the GPOs. You can work around this by using the /ignoreschema switch, which will restore the GPO according to the version dcgpofix thinks is current. The only time you might experience this issue is if you install a service pack on a domain controller (DC1) that extends the schema but the changes have not yet replicated to a second domain controller (DC2). If you try to run dcgpofix from DC2, you will receive the error since a new version of the schema and the dcgpofix utility were installed on DC1. Note that this tool isn’t a panacea. It doesn’t always return permissions to the exact state after the domain controller promotion process. Because of this, backups of Group Policy should be relied on first.

You want to create a Fine-Grained Password Policy (FGPP).

Prior to Windows Server 2008, only one password and account lockout policy functioned per domain (note that we are only talking about domain user accounts); this has been updated since Windows Server 2008 once you reach the Windows Server 2008 domain functional level. Fine-Grained Password Policies are controlled by creating one or more msDS-PasswordSettingsObjects, or PSOs for short, in the cn=Password Settings Container,cn=System,cn=<Domain DN> container. Each PSO can apply to one or more user or group objects, and each is assigned a precedence that will allow Active Directory to determine which PSO to enforce if more than one can apply to a particular user.

Viewing the Effective PSO for a User; Editing a Fine-Grained Password Policy; New-ADFineGrainedPasswordPolicy cmdlet reference

You want to modify a Fine-Grained Password Policy.

Once a PasswordSettingsObject has been created, you can modify the password and account lockout settings controlled by the object, as well as the users and groups that the PSO should apply to. Since the PasswordSettingsObject is an Active Directory object class, these modifications can be made using any interface that can modify objects.

When working from the command line, the psomgr tool allows you to modify one or multiple PSOs at a time, and can also create “starter” PSOs using the psomgr -quickstart -forreal syntax. The -quickstart switch creates a PSO that replicates the domain-linked password policy, as well as the following two PSOs:

The full syntax for psomgr.exe can be obtained by typing psomgr.exe /? at a command prompt, or by visiting the joeware website.

Viewing the Effective PSO for a User; Creating a Fine-Grained Password Policy; Applying a Fine-Grained Password Policy to a User Object

You want to determine which PSO is in effect for a particular user.

Within a Windows Server 2008 or later domain, each user object contains a constructed backlink attribute called msDS-ResultantPSO that indicates which PasswordSettingsObject is in effect for that user. The precedence rules for PasswordSettingsObjects are as follows:

Creating a Fine-Grained Password Policy; 3.1.1.4.5.36 msDSResultantPSO