Introduction

Group Policy is a feature in Microsoft Windows operating systems that allows administrators to manage and configure the settings of user accounts and computer systems centrally and then deploy them to computers across their organizations.

The Administrator can define, enforce, and update their entire configuration by using GPO settings. By using GPO settings, they can affect an entire site or a domain within their organization, or they can narrow their focus to a single OU.

What is Group Policy

Group Policy is a framework in Windows operating systems with components that reside in AD DS, on domain controllers, and on each Windows Server and client. By using these components, you can manage configuration in an AD DS domain. You define Group Policy settings within a GPO. A GPO is an object that contains one or more policy settings that apply to one or more configuration settings for a user or a computer.

Group Policy is a powerful administrative tool. You can use GPOs to push various settings to a large number of users and computers. Because you can apply them to different levels, from the local computer to domain, you also can focus these settings precisely. Primarily, you use Group Policy to configure settings that you do not want users to configure. Additionally, you can use Group Policy to standardize desktop environments on all computers in an organizational unit (OU) or in an entire organization. You also can use Group Policy to provide additional security, to configure some advanced system settings, and for other purposes discussed in a subsequent demonstration unit.

What are GPOs?

The most granular component of Group Policy is an individual policy setting. An individual policy setting defines a specific configuration, such as a policy setting that prevents a user from accessing registry-editing tools. If you define that policy setting and then apply it to a user, that user will be unable to run tools such as Regedit.exe.

Some settings affect a user, known as user configuration settings or user policies, and some affect the computer, known as computer configuration settings or computer policies.

Important. Settings do not affect groups directly and apply only to user and computer objects.

Group Policy manages various policy settings, and the Group Policy framework is extensible. You can manage almost any configurable setting with Group Policy.

Implement GPO scope and inheritance

Policy settings in GPOs define configuration. However, you must specify the computers or users to which the GPO applies before the configuration changes in a GPO will affect computers or users in your organization. This is called scoping a GPO. The scope of a GPO is the collection of users and computers that will apply the settings in the GPO.

Important: You scope a GPO by linking it to an OU that contains the target users and computers.

Scope a GPO

You can use several methods to manage the scope of domain-based GPOs. The first is the GPO link. In AD DS, you can link GPOs to:

• Sites
• Domains
• OUs

The site, domain, or OU then becomes the maximum scope of the GPO. The configurations that the policy settings in the GPO specify will affect all computers and users within the site, domain, or OU, including those in child OUs. You can link a GPO to more than one domain, OU, or site.

Caution! Linking GPOs to multiple sites in a multiple domain forest can introduce performance issues when applying the policy, and you should avoid linking GPOs to multiple sites in this situation. This is because, in a multi-forest multiple-site network, the GPOs are stored on the domain controllers in the domain where the GPOs were created. The consequence of this is that computers in other domains might need to traverse a slow wide area network (WAN) link to obtain the GPOs.

You can further narrow the scope of the GPO with one of two types of filters discussed in the following:

Security Filtering

These specify security groups or individual user or computer objects that relate to a GPO’s scope, but to which the GPO explicitly should or shouldn’t apply.

WMI Filtering

These specify a scope by using characteristics of a system, such as an operating system version or free disk space.

Use security filters and WMI filters to narrow or specify the scope within the initial scope that the GPO link created. The following is an example of a WMI filter that results in a list of computers running Windows 10.

select * from Win32_OperatingSystem where Version like "10.%"

GPO processing order

The GPOs that apply to a user, computer, or both don’t apply all at once. GPOs apply in a particular order. Conflicting settings that process later might overwrite settings that process first.

Group Policy follows the following hierarchical processing order:

1. Local GPOs.
2. Site-linked GPOs.
3. Domain-linked GPOs.
4. OU-linked GPOs.
5. Child OU-linked GPOs.

Important: In Group Policy application, the default rule is that the last policy (the most specific policy) applied prevails.

For example, a policy that restricts access to the Control Panel applied at the domain level could be reversed by a policy applied at the OU level for the objects contained in that particular OU.

If you link several GPOs to an OU, their processing occurs in the order that the administrator specifies on the OU’s Linked Group Policy Objects tab in the Group Policy Management Console. By default, processing is enabled for all GPO links. You can disable a container’s GPO link to block the application of a GPO completely for a given domain or OU. For example, if you made a recent change to a GPO and it’s causing production issues, you can disable the link or links until the issue resolves.

Note that if the GPO is linked to other containers, they’ll continue to process the GPO if their links are enabled.

You also can disable the user or computer configuration of a particular GPO independently from either the user or computer. If one section of a policy is known to be empty, disabling the other section can speed up policy processing slightly. For example, if you have a policy that only delivers user desktop configuration, you could disable the computer section of the policy.

GPO inheritance

You can configure a policy setting in more than one GPO, which might result in GPOs conflicting with each other. In this case, the precedence of the GPOs determines which policy setting the client applies. A GPO with higher precedence prevails over a GPO with lower precedence. Precedence is determined numerically. Each GPO has a precedence value. The lower the number, the higher the precedence. Therefore, a GPO that has a precedence of one prevails over all other GPOs.

The default behavior of Group Policy is that GPOs linked to a higher-level container are inherited by lower-level containers. When a computer starts up or a user signs in, the Group Policy Client Extensions examines the location of the computer or user object in AD DS and evaluates the GPOs with scopes that include the computer or user. Then, the client-side extensions apply policy settings from these GPOs. Policies apply sequentially, beginning with the policies that link to the site, followed by those that link to the domain, followed by those that link to OUs. This sequential application of GPOs creates an effect called policy inheritance. Policies are inherited, which means that the Resultant Set of Policies (RSoPs) for a user or computer will be the cumulative effect of site, domain, and OU policies.

Block Inheritance

You can configure a domain or OU to prevent the inheritance of policy settings. This is known as blocking inheritance. To block inheritance, right-click or access the context menu for the domain or OU in the GPMC console tree, and then select Block Inheritance.

The Block Inheritance option is a property of a container, so it blocks all Group Policy settings from GPOs that link to parents in the Group Policy hierarchy.

Caution: Use the Block Inheritance option sparingly because blocking inheritance makes it more difficult to evaluate Group Policy precedence and inheritance. Tip: With security group filtering, you can carefully scope a GPO so that it applies to only the correct users and computers in the first place, making it unnecessary to use the Block Inheritance option.

Enforce a GPO link

Additionally, you can set a GPO link to be enforced. To enforce a GPO link, right-click or access the context menu for the GPO link in the console tree, and then select Enforced from the shortcut menu.

When you set a GPO link to Enforced, the GPO takes the highest level of precedence. Policy settings in that GPO prevail over any conflicting policy settings in other GPOs.

Important: An enforced link applies to child containers even when those containers are set to Block Inheritance. The Enforced option causes the policy to apply to all objects within its scope.

Enforcement is useful when you must configure a GPO that defines a configuration that’s mandated by your corporate IT security and usage policies. Therefore, you want to ensure that other GPOs that are linked to the same or lower levels don’t override those settings. You can do this by enforcing the GPO’s link.

Evaluating precedence

To facilitate evaluation of GPO precedence, you can simply select an OU or domain, and then select the Group Policy Inheritance tab. This tab displays the resulting precedence of GPOs, accounting for GPO link, link order, inheritance blocking, and link enforcement.

Define domain-based GPOs

You can create domain-based GPOs in AD DS and store them on domain controllers. You can use these GPOs to manage configuration centrally for the domain’s users and computers. When you install AD DS, Windows Server creates two default GPOs:

Default Domain Policy.

The Default Domain Policy GPO is linked to the domain, and it applies to Authenticated Users. This GPO doesn’t have any WMI filters. Therefore, it affects all users and computers in the domain. This GPO contains policy settings that specify password, account lockout, and Kerberos version 5 authentication protocol policies.

These settings are of critical importance to the AD DS environment, and thus, make the Default Domain Policy a critical component of Group Policy. You shouldn’t add unrelated policy settings to this GPO. If you need to configure other settings to apply broadly in your domain, create additional GPOs that link to the domain.

Default Domain Controllers Policy

The Default Domain Controllers Policy GPO links to the OU of the domain controllers. Because computer accounts for domain controllers are kept exclusively in the Domain Controllers OU, and other computer accounts should be kept in other OUs, this GPO affects only domain controllers or other computer objects that are in the Domain Controllers OU.

You should modify GPOs linked to the Domain Controllers OU to implement your auditing policies and to assign user rights that are required on domain controllers.

Note: Windows computers also have local GPOs, which are primarily used when computers aren’t connected to domain environments.

Create and configure a domain-based GPO

You manage GPOs by using two primary tools:

• The Group Policy Management console
• The Group Policy Management Editor

You can also use Windows PowerShell cmdlets to manage GPOs and their settings, including those described in the following table.

Creates a new GPO New-GPO Links a GPO to a site, domain, or OU New-GPLink Gets Group Policy inheritance information for a specified domain or OU. Get-GPInheritance Blocks or unblocks inheritance for a specified domain or organizational unit. Set-GPInheritance Gets one GPO or all the GPOs in a domain. Get-GPO

What can you manage with GPOs?

There are two major categories of policy settings: computer settings, which are contained in the Computer Configuration node, and user settings, which are contained in the User Configuration node:

• The Computer Configuration node contains The settings that apply to computers, regardless of who logs on to them. Computer settings apply when the operating system starts, during background refreshes, and every 90 to 120 minutes thereafter.
• The User Configuration node contains The settings that apply when a user logs on to a computer, during background refreshes, and every 90 to 120 minutes thereafter.

Within the Computer Configuration and User Configuration nodes are the Policies and Preferences nodes. The Policies nodes in Computer Configuration and User Configuration have a hierarchy of folders that contain policy settings. Because there are thousands of settings, the scope of this course doesn’t include individual settings. However, it’s worth reviewing the types of settings that you can configure.

Apply security settings

In the Windows Server operating system, GPOs include a large number of security-related settings that you can apply to both users and computers. For example, you can enforce settings for the domain password policy, for Windows Defender Firewall, and you can configure auditing and other security settings. You also can configure full sets of user-rights assignments.

Manage desktop and application settings

You can use Group Policy to provide a consistent desktop and application environment for all users in your organization. By using GPOs, you can configure each setting that affects the representation of the user environment. You also can configure settings for some applications that support GPOs.

Deploy software

With Group Policy, you can deploy software to users and computers. You can use Group Policy to deploy all software that is available in the .msi format. Additionally, you can enforce automatic software installation, or you can let your users decide whether they want the software to deploy to their computers.

Important: Deploying large software packages with GPOs might not be the most efficient way to distribute an application to your organization’s computers. In some circumstances, it might be more effective to distribute applications as part of the desktop computer image.

Manage Folder Redirection

With the Folder Redirection option, it is easier to back up users’ data files. By redirecting folders, you also ensure that users have access to their data regardless of the computer to which they sign in. Additionally, you can centralize all users’ data to one place on a network server, while still providing a user experience that is similar to storing these folders on their computers. For example, you can configure Folder Redirection to redirect users’ Documents folders to a shared folder on a network server.

Configuring network settings

By using Group Policy, you can configure various network settings on client computers. For example, you can enforce settings for wireless networks to allow users to connect only to specific Wi-Fi network SSIDs and with predefined authentication and encryption settings. You also can deploy policies that apply to wired network settings, and some Windows Server roles use Group Policy to configure the client side of services, such as DirectAccess.

Troubleshooting the application of GPOs?

Group Policy inheritance, filters, and exceptions are complex, and it can often be difficult to determine which policy settings will apply. RSoP is the net effect of GPOs applied to a user or computer, considering GPO links, exceptions such as Enforced and Block Inheritance, and the application of security and WMI filters.

RSoP also is a collection of tools that you can use to evaluate, model, and troubleshoot the application of Group Policy settings. RSoP can query a local or remote computer and report the exact settings that applied to the computer and to any user who has logged on to the computer. RSoP also can model the policy settings that are anticipated to be applied to a user or computer under a variety of scenarios, including moving the object between OUs or sites, or changing the object’s group membership. With these capabilities, RSoP can help you manage and troubleshoot conflicting policies. The following tools exist for performing RSoP analysis:

• The Group Policy Results Wizard.
• The Group Policy Modeling Wizard.
• GPResult.exe.

Define GPO storage

What are Group Policy containers and templates? These two components are described in the following

The Group Policy container

The Group Policy Objects container is located in Active Directory and it stores GPO metadata. It doesn’t contain actual settings, but information on when GPO was created, how many times user and computer settings were modified, GPO version and its GUID (which is used to link Group Policy settings to a Group Policy template.

The Group Policy template

This template is a collection of files stored in the SYSVOL of each domain controller in the %SystemRoot%\SYSVOL\Domain\Policies\GPOGUID path, where GPOGUID is the globally unique identifier (GUID) of the Group Policy container. The Group Policy template contains the Group Policy settings.

Note: Similar to all AD DS objects, each Group Policy container includes a GUID attribute that uniquely identifies the object within AD DS.

When you change the settings of a GPO, the changes are saved to the SYSVOL share. By default, the domain controller that holds the PDC Emulator operations master role is used. Changes made are then replicated to other domain controllers.

Tip: By default, when Group Policy refresh occurs, the client-side extensions apply settings in a GPO only if the GPO has been updated.

The Group Policy client can identify an updated GPO by its version number, as the following describes:

• Each GPO has a version number that increments each time you make a change.
• The version number is stored as a Group Policy container attribute and in a text file, GPT.ini, in the Group Policy template folder.
• The Group Policy client knows the version number of each GPO it has previously applied.
• If, during the Group Policy refresh, the Group Policy client discovers that the version number of the Group Policy container has changed, Windows Server will inform the client-side extensions that the GPO is updated.

GPO replication

The Group Policy container and the Group Policy template both replicate between all domain controllers in the local domain in AD DS. However, these two items use different replication mechanisms.

The Group Policy container in AD DS replicates by using the Directory Replication Agent (DRA). The DRA uses a topology that the Knowledge Consistency Checker generates, which you can define or refine manually. The result is that the Group Policy container replicates within seconds to all domain controllers in a site and replicates between sites based on your intersite replication configuration. The Group Policy template in the SYSVOL replicates by using the Distributed File System Replication (DFS-R).

Caution: Because the Group Policy container and Group Policy template replicate separately, it is possible for them to become out-of-sync for a brief time. Typically, when this happens, the Group Policy container will replicate to a domain controller first.

Systems that obtained their ordered list of GPOs from that domain controller will identify the new Group Policy container. Those systems will then attempt to download the Group Policy template, and they’ll notice that the version numbers are not the same. A policy processing error will record in the event logs.

If the reverse happens, and the GPO replicates to a domain controller before the Group Policy container, clients that obtain their ordered list of GPOs from that domain controller won’t be notified of the new GPO until the Group Policy container has replicated.