Active Directory Group Policy Objects (GPOs) can customize virtually any aspect of a computer or user’s desktop. They can also be used to install applications, secure a computer, run logon/logoff or startup/shutdown scripts, and much more. You can assign a GPO to a local computer, site, domain, or organizational unit. This is called scope of management (SOM), because only the users or computers that fall under the scope of the computer, OU, site, or domain will process the GPO. Assigning a GPO to a SOM is referred to as linking the GPO. You can restrict the application of GPOs further by using security groups to filter which users or groups they will apply to or by using inheritance blocking.
You can also use a WMI filter to restrict the application of a GPO. A WMI filter is simply a WMI query that can search against any information on a client’s computer. If the WMI filter returns a true value (i.e., the client computer matches the conditions that are specified in the filter), the GPO will be processed; otherwise, it will not. So not only do you have all of the SOM options for applying GPOs, but also you can use any WMI information available on the client’s computer to determine whether GPOs should be applied. For more on the capabilities of GPOs, we recommend reading Active Directory, Fifth Edition, by Brian Desmond et al. (O’Reilly).
Group Policies are defined by a set of files that are replicated to
each domain controller in a domain and a groupPolicyContainer
(GPC) object that is stored
in the cn=Policies,cn=System,
<DomainDN>
container. GPC objects contain information related to software deployment,
wireless deployments, IPSec assignments, and metadata about the version of
the GPO. GPC objects are used for linking to OUs, sites, and domains. The
guts of GPOs are stored on the filesystem of each domain controller in
Group Policy Template (GPT) files and can be found in the %SystemRoot%SYSVOLsysvol<DomainDNSName>Policies
directory.
So why are there two storage points for GPOs? The need for the Active Directory object is obvious: to be able to link GPOs to other types of objects, the GPOs need to be represented in Active Directory. Group Policy Templates are stored in the OS filesystem to reduce the amount of data that needs to be replicated within Active Directory.
For legacy Windows computers, each Group Policy Object stores individual copies of Administrative templates (.adm files) in the SYSVOL folder. In an environment containing numerous GPOs, this can add significantly to the amount of data that must be replicated to the SYSVOL share on all domain controllers in a domain. However, since Windows Vista, GPO settings are deployed using a new XML-based .admx format, and administrators have the option to configure a single Central Store to provide a storage instance for all GPOs in a domain.
Furthermore, Windows Server 2008 introduced Group Policy Preferences (GPPs), a new group of GPO settings that can be used to manage configuration items that could not be managed previously (or that could not be managed particularly well) via GPOs, including managing the creation of file shortcuts, ODBC connections, drive mappings, printer connections, and more.
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.
The only major feature that is still lacking is the ability to modify the settings of a GPO directly via command line or script (although there is some ability to modify specific types of settings, improvement is needed). Previously, this could be done with only the GPOE, but there are third-party options that can provide this type of functionality. The GPMC still provides numerous options for migrating GPOs, which addresses the majority of the problems people face today.
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 can generate a list of all GPOs in a domain using the listastallgpos.wsf script, as well as DSQuery and AdFind:
> listallgpos.wsf [/domain:<DomainDNSName>
] [/v]
> dsquery * domainroot -filter (objectcategory=grouppolicycontainer)
-attr displayname
> adfind -default -f (objectcategory=grouppolicycontainer)↵
displayname
See Introduction for more on how GPOs are stored in Active Directory.
In the left pane, expand the Forest
container, expand the Domains
container, and browse to the
domain that will contain the new GPO.
Expand the domain and then right-click on the Group Policy Objects
container and
select New.
Enter the name of the GPO, ensure that the Source Start GPO is set to (none), and then click OK.
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.
Open the Group Policy Management snap-in (gpmc.msc).
In the left pane, expand the Forest
container, expand the Domains
container, browse to the domain
of the source GPO, expand the domain, and then expand the Group Policy Objects
container.
Right-click on the source GPO and select Copy.
Right-click on the Group Policy
Objects
container and select Paste.
Select whether you want to use the default permissions or to preserve the existing permissions from the GPO being copied, and click OK.
A status window will pop up that will indicate whether the copy was successful. Click OK to close.
Rename the new GPO by right-clicking it in the left pane and selecting Rename.
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
In the left pane, expand the Forest
container, expand the Domains
container, browse to the domain
of the target GPO, expand the domain, and then expand the Group Policy Objects
container.
Right-click on the target GPO and select Delete.
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
In the left pane, expand the Forest
container, expand the Domains
container, browse to the domain
of the target GPO, expand the domain, and then expand the Group Policy Objects
container.
Click on the target GPO.
In the right pane, click on the Settings tab.
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
Open the Group Policy Management snap-in (gpmc.msc).
In the left pane, expand the Forest
container, expand the Domains
container, browse to the domain
of the target GPO, expand the domain, and then expand the Group Policy Objects
container.
Right-click on the target GPO and select Edit. This will bring up the Group Policy Management Editor.
Browse through the Computer Configuration or User Configuration settings and modify them as necessary.
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
Open the Group Policy Management snap-in (gpmc.msc).
In the left pane, expand the Forest
container, expand the Domains
container, expand the domain of
the target GPO, and expand the Group
Policy Objects
container.
Right-click on the target GPO and select Import Settings.
Click Next.
Click the Backup button if you want to take a backup of the GPO you are importing into.
Click Next.
Select the backup folder location and click Next.
Select the backed-up GPO you want to import from and click Next.
The Import wizard then will scan to see whether there are any security principals or UNC paths in the GPO being imported from. If there are, it will give you an option to modify those settings.
Click Next.
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.
Open the Group Policy Management snap-in (gpmc.msc). Navigate to the forest and domain containing the GPOs you wish to migrate or copy.
Right-click on the Group Policy Objects node and select Open Migration Table Editor.
You will begin with a blank migration table. To populate the source fields from existing data, click on Tools→Populate from GPO or Tools→Populate from Backup. Select the GPO or the backup that you wish to import. Optionally, place a checkmark next to “During scan, include security principals from the DACL on the GPO.” Click OK.
Modify the Destination Name column of any entries to match their format in the destination forest or domain.
To add a new entry, enter the name of the item in the Source Name column. In the Source Type column, select one of the following:
User
Computer
Domain Local Group
Domain Global Group
Universal Group
UNC Path
Free Text or SID
To delete an entry, right-click on the entry and select Delete.
To configure an entry to use the same information as configured in the source GPO, right-click on the entry and select Set Destination→Same As Source.
To configure an entry to use the relative name of the destination, right-click on the entry and select Set Destination→Map by Relative Name. For example, if you have an entry for the [email protected] user in a GPO that you wish to copy to the mycompany.com forest, selecting Map by Relative Name will populate the entry in the destination GPO as [email protected].
To ensure that you have properly formatted all entries in the table, click Tools→Validate Table, then click File→Save or File→Save As to save the migration table.
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.
To create a migration table from the command line, use the createmigrationtable.wsf script that is included in the ~GPMC Sample Scripts folder. The script requires two arguments: the destination filename and the GPO that it should be populated from.
As an alternative to the /GPO:
switch, you can use /BackupLocation:
to populate the migration
table from a GPO backup. By default, a migration table that you create
using this script will use Same As Source mapping, or you can specify
the /MapByName
parameter to use
relative name mapping.
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.
In the left pane, expand the Forest
container, expand the Domains
container, expand the domain of
the target GPO, and expand the Group
Policy Objects
container.
Right-click on the target GPO and select Edit. This will bring up the Group Policy Management Editor.
Browse to Computer Configuration→Policies→Windows Settings→Scripts. If you want to assign a user logon or logoff script, browse to User Configuration→Policies→Windows Settings→Scripts.
In the right pane, double-click on the type of script you want to add.
Click the Add button.
Select the script by typing its name or browsing to its location.
Optionally, type any script parameters in the Script Parameters field.
Click OK twice.
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.
In the left pane, expand the Forest
container, expand the Domains
container, expand the domain of
the target GPO, and expand the Group
Policy Objects
container.
Right-click on the target GPO and select Edit. This will bring up the Group Policy Management Editor.
Expand Software Settings under Computer Configuration or User Configuration, depending on which you want to target the installation for.
Right-click on Software Installation and select New→Package.
Browse to the network share that has the MSI package for the application and click OK. Be sure to specify a UNC path such as \servernameshareinstaller.msi. If you enter a local file path on the DC, such as c:packagespro.msi, the client will not be able to access the installer.
Select whether you want to assign the application or publish it, and click OK. You can also click Advanced to define further how you want to deploy the software installation package.
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 user
s.
In the left pane, expand the Forest
container, expand the Domains
container, expand the domain of
the target GPO, and expand the Group
Policy Objects
container.
Right-click on the target GPO and select GPO Status.
You can select User Configuration Settings Disabled to disable the user settings, Computer Configuration Settings Disabled to disable the computer settings, or All Settings Disabled to disable both user and computer settings.
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
See Introduction for more information on GPO linking.
The built-in PowerShell cmdlets are not useful for retrieving
links. Instead, we rely on searching the other direction: the OUs
themselves. In the PowerShell solution, we get all of the OUs in the
current domain and then filter them for any that have the specified
GPO GUID stored in the gpLink
attribute. This indicates that the GPO is linked to the OU. Finally,
we select only the name of the OUs.
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
Below are two ways to block inheritance by using PowerShell. The first example uses one of the cmdlets from the Group Policy module, whereas the other relies on a COM object.
Set-GPInheritance -Target "<OU DN>
" -IsBlocked Yes $gpm = New-Object -ComObject GPMgmt.GPM $gpmConstants = $gpm.GetConstants() $objDomain = $gpm.GetDomain("<Domain FQDN>
", "", $gpmConstants.UseAnyDC) $objOU = $objDomain.GetSOM("<OU DN>
") $objOU.GPOInheritanceBlocked = $true
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.
In the left pane, expand the Forest
container, expand the Domains
container, expand the domain of
the target GPO, and expand the container containing the link you
want to enforce.
Right-click on the link you want to configure and place a checkmark next to Enforced. To remove the Enforced setting, right-click on the link and remove the checkmark.
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.
Remember that the Enforced setting is configured against a particular link to a GPO, not against the GPO itself. This means that one GPO can be linked to several locations, but not all of those links need to be enforced.
Blocking Inheritance of GPOs on an OU; Set-GPLink
cmdlet reference;
MSDN:IGPMSearchCriteria; MSDN:GPMC
Object Model
In the left pane, expand the Forest
container, expand the Domains
container, expand the target
domain, and expand the Group Policy
Objects
container.
Click on the GPO you want to modify.
In the right pane under Security Filtering, click the Add button.
Use the Object Picker to select a group and click OK.
Highlight Authenticated Users and click the Remove button.
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.
Be very careful when changing permissions on GPOs. If you create a very restricted GPO and apply a security filter to it, also be sure to put tight controls on who can modify the GPO and how. If for some reason that security filter were removed (resulting in no security filters), the restrictive GPO could be applied to every user or computer in the domain.
Set-GPPermission
cmdlet reference;MSDN:
GPM.CreatePermission; MSDN: GPMGPO.GetSecurityInfo
To delegate the ability to create GPOs, do the following:
Open the Group Policy Management snap-in (gpmc.msc).
Navigate to the Group Policy Objects node and click on the Delegation tab.
To add permissions for a new user or group to create GPOs, click Add. Use the object picker to select the object you want and click OK.
To delegate permissions on a particular GPO, follow these steps:
Open the Group Policy Management snap-in (gpmc.msc).
Navigate to the GPO that you want to delegate permissions for and click on the Delegation tab.
To add permissions for a new user or group, click Add. Use the object picker to select the object you want and click OK.
In the Permissions drop-down box, select “Read”, “Edit settings,” or “Edit settings, delete, and modify security,” then click OK.
To delegate Group Policy−related tasks on a particular site, domain, or OU, do the following:
Open the Group Policy Management snap-in (gpmc.msc).
Navigate to the site, domain, or OU that you want to delegate permissions for and click on the Delegation tab.
In the Permission drop down, select “Link GPOs,” “Perform Group Policy Modeling analyses,” or “Read Group Policy Results data.”
To add permissions for a new user or group, click Add. Use the object picker to select the object you want and click OK.
In the Permissions drop-down box, select “This container only” or “This container and all child containers”; then click OK.
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:
Create GPOs
Manage the settings of an individual GPO
Link GPOs to a site, domain, or OU
Create WMI filters
Manage an individual WMI filter
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
In the left pane, expand the Forest
container, expand the Domains
container, expand the domain of
the GPO you want to target, and expand the Group Policy Objects
container.
Right-click on the target GPO and select Edit.
Navigate to Computer Configuration→Policies→Windows Settings.
Right-click on Security Settings and select Import Policy.
Browse to the template you want to import and click Open.
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.
Open the Group Policy Management snap-in (gpmc.msc).
In the left pane, expand the Forest
container, expand the Domains
container, expand the target
domain, and click the WMI
Filters
container.
Right-click on the WMI
Filters
container and select New.
Enter a name and description for the filter.
Click the Add button.
Select the appropriate namespace, enter a WQL query, and click OK.
Repeat steps 5 and 6 for as many queries as you need to add.
Click the Save button.
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
In the left pane, expand the Forest
container, expand the Domains
container, expand the domain of
the GPO you want to target, and expand the Group Policy Objects
container.
Click on the target GPO.
At the bottom of the right pane, on the Scope tab, select a WMI filter from the list of WMI filters.
After you’ve selected the WMI filter, click Yes to change the filter.
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.
Keep in mind that requiring your clients to process multiple WMI filters will have an impact on their performance at logon time and during the GPO background refresh process.
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.
Navigate to the GPO that you want to configure. Right-click on the GPO and select Edit Settings.
Navigate to Computer Configuration→Policies→Administrative→Templates System→Group Policy. Double-click on “Configure user Group Policy loopback processing mode”. Select the radio button next to Enabled.
In the Mode drop-down box, select either Merge or Replace. (See this recipe’s for more information on these two options.)
Click OK.
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:
In this mode, any GPOs that are associated with the user
will be applied first. The GPOs associated with the computer
object will be applied after
the GPOs associated with the user
object, thereby giving them a
higher precedence than the user GPOs. In this case, the user will
still receive any GPO settings associated with her user
object, but settings configured for
the computer will override in the case of any conflicts.
In this mode, only the list of GPOs that apply to the
computer
object will be
applied.
In the left pane, expand the Forest
container, expand the Domains
container, expand the domain of
the GPO you want to back up, and expand the Group Policy Objects
container.
Right-click on the GPO you want to back up and select Back Up.
For Location, enter the folder path to store the backup files.
For Description, enter a descriptive name for the backup.
Click the Back Up button.
You will see a progress bar and status message that indicates whether the backup was successful.
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
In the left pane, expand the Forest
container, expand the Domains
container, expand the domain of
the GPO you want to restore, and expand the Group Policy Objects
container.
Right-click on the GPO you want to restore and select Restore from Backup.
Click Next.
Select the backup folder location and click Next.
Select the backup you want to restore and click Next.
Click Finish.
You will see the restore status window. After it completes, click OK to close the window.
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:
Right-click on the Group Policy
Objects
container in the target domain and select Manage
Backups.
Highlight the GPO you want to restore and click the Restore button.
Click Yes to confirm.
Click OK after the restore completes.
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.
In the left pane, right-click Group Policy Modeling and select Group Policy Modeling Wizard.
Click Next.
Select a domain controller to process the query and click Next.
Under User Information and/or Computer Information, either select the container you want to simulate to contain the user or computer, or select a specific user or computer account, and click Next.
Select a site if necessary, and specify whether you wish to simulate a slow network connection or loopback processing, and then click Next.
If you selected a target user container or user account in step 5, you will be presented with an option to simulate different group membership. Click Next when you are done.
If you selected a target computer container or computer account in step 5, you will be presented with an option to simulate different group membership. Click Next when you are done.
If you selected a target user container or user account in step 5, you will be presented with an option to simulate any additional WMI filters. Click Next when you are done.
If you selected a target computer container or computer account in step 5, you will be presented with an option to simulate any additional WMI filters. Click Next when you are done.
Click Next to start the simulation.
Click Finish.
In the right pane of the Group Policy Management snap-in window, the results of the simulation will be displayed.
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.
To display summary RSoP data to the screen, use the following command:
> gpresult /R
To generate an RSoP in HTML format, use the following command:
> gpresult /H RSoP.htm
You can specify a /S
option
and the name of a computer to target, which allows you to run the
command remotely. For a complete list of options with either version,
run gpresult /?
from a command
line.
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.
The following command will replace both the Default Domain
Security Policy and the Default Domain Controller Security Policy on a
domain controller. You can specify Domain
or DC
instead of Both
, to only restore one or the
other:
> dcgpofix /target:Both
Note that this must be run from a domain controller in the target domain where you want to reset the GPO.
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.
At the top of the left pane, click the tree view icon.
Browse to the desired domain and then expand the domain,
expand System, and then highlight the Password Settings
container.
Right-click the Password
Settings
container in the left pane, click New, and then
click Password Settings.
Type in a name for the settings, enter a precedence value, and then fill in the desired password settings. Note that settings with a red asterisk are mandatory.
In the Directly Applies To section near the bottom, click the Add button to specify users or groups to apply the password settings to.
When finished, click OK to save the settings and apply the settings to the specified users or groups.
Fine-Grained Password Policy objects can also be created in PowerShell, as follows:
New-ADFineGrainedPasswordPolicy -Name "HighSec2" -Precedence 1 -ComplexityEnabled $true -Description "High Security Password Policy" -DisplayName "Domain Users PSO" -PasswordHistoryCount "12" -MinPasswordLength "15" -MinPasswordAge "1" -MaxPasswordAge "180" -LockoutDuration "30" -LockoutObservationWindow "1" -LockoutThreshold "999"
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-PasswordSettingsObject
s, 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.
Open Active Directory Administrative Center.
At the top of the left pane, click the tree view icon.
Browse to the desired domain, expand the domain, expand
System, and then highlight the Password
Settings
container.
In the right pane, right-click on the desired policy and then click Properties.
Update the desired settings and click OK to save the new settings.
The following command renames a PasswordSettingsObject
:
psomgr -rename newname -pso oldname -forreal
The following modifies a PSO’s maximum password age to 60 days:
psomgr -mod -pso TestPSO -pwdlen 60 -forreal
The following adds the Marketing group to the list of groups that a PSO will apply to:
psomgr -applyto cn=Marketing,cn=Users,dc=ADATUM,dc=COM -pso TestPSO -forreal
The following removes the Marketing group from the list of groups that a PSO will apply to:
psomgr -unapplyto cn=Marketing,cn=Users,dc=ADATUM,dc=COM -pso TestPSO -forreal
You can also use the
DomainsAMAccountName
syntax instead of a
distinguished name.
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:
cn=pwd_policy_admin
Creates a PSO with a minimum password length of 15, with passwords that expire every 35 days and that are subject to a 30-minute lockout after 25 bad-password attempts
cn=pwd_policy_serviceid
Creates a PSO with a minimum length of 15, with passwords that expire every 364 days and that are not subject to account lockout
The full syntax for psomgr.exe can be obtained by typing psomgr.exe /?
at a command prompt, or by
visiting the joeware website.
Open Active Directory Users and Computers. Click on View and confirm that there is a checkmark next to Advanced Features.
Browse to the user or group in question; right-click on the object and click Properties.
Click on the Attribute Editor tab. Click Filter and confirm that there is a checkmark next to “Show read-only attributes: Constructed and Backlinks”.
Scroll to msDS-PSOApplied
.
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 PasswordSettingsObject
s are as
follows:
If a PSO has been applied directly to the user object, it will take precedence. If multiple PSOs have been applied to a single user, the following tiebreakers will be used:
A PSO with a lower-numbered Precedence
attribute (e.g., 5) will be
applied over a higher-numbered one (e.g., 50).
If multiple PSOs have been configured with the same
Precedence
attribute, the PSO
with the lowest GUID will take final precedence.
If no PSOs have been applied directly to the user, any PSO that has been applied to a group that the user is a member of, whether directly or indirectly, will be applied. The same tiebreakers will be used here as in rule 1.
If no PSOs have been applied to the user or any groups that the user is a member of, the default domain PSO will be applied.
18.226.164.216