Group Policy allows administrators to manage one device or many thousands of devices and/or servers through a centralized management console. You can use it to secure domain-joined devices, make them more useful for end users, and make them look and feel identical as per your organization's standards.
Granularity in Group Policy objects offers you the ability to manage these settings for devices in the entire Active Directory domain, for an Active Directory site (but please refrain from linking Group Policy objects on the site-level), per Organizational Unit (OU), and beyond that by using Windows Management Instrumentation (WMI) filters.
Group Policy has been around since the beginning of Active Directory in Windows 2000 Server. It has seen many improvements in the last two decades, such as Group Policy preferences and many new settings relating to all the new client and server operating system possibilities.
Although currently considered archaic because of trends such as bring your own device and solutions such as Mobile Device Management (MDM) and Mobile Application Management (MAM), Group Policy should be considered an essential tool in every Active Directory admin's toolbox.
The following recipes are covered in this chapter:
This recipe shows how to create a GPO.
To create a GPO, sign in to a system with the Group Policy Management feature installed with an account that is either of the following:
Besides permission to create GPOs, additional permissions are needed to use a Starter GPO or link a GPO to an OU.
This recipe shows two ways to create a GPO:
To create a GPO, perform the following steps:
You now have a GPO. However, it doesn't have any settings, and it isn't linked – at least not yet.
To create a GPO using Windows PowerShell, use the following line of PowerShell:
New-GPO -Name "New GPO Name"
Replace New GPO Name with the name of the new GPO.
Group Policy Management is the tool of choice to manage GPOs.
Regardless of the tool used, GPOs are created in the Policies container in Active Directory.
Group Policy Management is a great tool to use when creating one GPO. When creating multiple GPOs or automating creating GPOs, Windows PowerShell proves more efficient.
To get things going with the GPO, refer to the Linking a GPO to an OU recipe.
This recipe shows how to copy an existing GPO to a new GPO. This is useful when you have configured the perfect GPO but want to adjust just a single setting to apply to legacy versions of the operating system or a test version in another OU.
To copy a GPO, sign in to a system with the Group Policy Management feature installed with an account that is either of the following:
This recipe shows two ways to copy a GPO:
To copy a GPO, perform the following steps:
To copy a GPO using Windows PowerShell, use the following line of PowerShell:
Copy-GPO -Sourcename "Existing GPO Name" -TargetName "New GPO Name"
Replace Existing GPO Name and New GPO Name with the names of the GPO to copy and the new GPO. Optionally, add the -CopyAcl parameter to switch from the Use the default permissions for new GPOs. option to the Preserve the existing permissions. option.
Copying a GPO is a sure way to create a GPO that is slightly different from an existing GPO.
After copying a GPO, only the name is different when you choose the Preserve the existing permissions. option. If you choose the Use the default permissions for new GPOs. option, your permissions on top of the default permissions apply, and the account used to copy the GPO would be the Group Policy owner.
In a multi-domain Active Directory forest, copying a GPO between the Group Policy Objects node in one domain to the Group Policy Objects node in another domain is a sure way to keep settings identical across domains. Copying GPOs is especially useful in networking environments consisting of development, testing, acceptance, and production environments to stage GPOs.
This recipe shows how to delete a GPO. As part of this recipe, any GPO links that are present are first deleted to ensure that no stale references occur in multi-domain environments.
To delete a GPO, sign in to a system with the Group Policy Management feature installed with an account that is either of the following:
This recipe shows two ways to delete a GPO:
To delete a GPO, perform the following steps:
To delete a GPO using Windows PowerShell, use the following line of PowerShell:
Remove-GPO -Name "Existing GPO Name"
Replace Existing GPO Name with the name of the GPO to delete.
A GPO not linked to an OU, site, or domain and not part of the development or testing process cannot be justified and can be deleted without repercussions.
When you delete a GPO, its links are not automatically deleted when the user account performing the deletion, does not have the permissions to manage the link, or when the link refers to another domain in the forest. GPO links should be removed before deleting a GPO to avoid lingering links.
For more information, refer to the Linking a GPO to an OU recipe.
This recipe shows how to modify settings in a GPO.
To manage settings in a GPO, sign in to a system with the Group Policy Management feature installed with an account that is either of the following:
Perform the following steps:
When you manage the settings and/or preferences in a GPO, they become active immediately. There are slight delays due to replication and the Group Policy background refresh timeout (90 minutes by default but with a 30-minute window of additional time, or 5 minutes for GPOs applied to domain controllers).
Some settings and/or preference patterns cause GPOs to apply slowly. This might slow down device startups and user sign-ins. Here are some tips:
This recipe shows how to assign a logon script using Group Policy.
To manage settings for a GPO, sign in to a system with the Group Policy Management feature installed with an account that is either of the following:
Perform the following steps:
This recipe describes four types of script you can use with Group Policy:
It is good practice to reference a script name in the Active Directory System Volume (SYSVOL). This way, the unavailability of a server doesn't mean the unavailability of scripts used to manage (part of) an environment. By default, when you type a script into the Script Name: field, Group Policy assumes that the script is located in the Scripts folder in the SYSVOL.
Windows PowerShell scripts require at least Windows 7 or Windows Server 2008 R2.
This recipe shows how to install an application using Group Policy.
To manage settings for a GPO, sign in to a system with the Group Policy Management feature installed with an account that is either of the following:
Perform the following steps:
Applications can be distributed to devices and user accounts using Group Policy. However, more advanced solutions are used in medium and large organizations, such as Microsoft Endpoint Manager, because of the lack of advanced features, controls, and reporting in Group Policy.
To install an application package, point to the package on a shared folder, which is accessible to the objects you target the GPO to. For users, the default Everyone – Full Control share permissions suffice, and default folders on Windows Server installations have Users – Read NT File System (NTFS) permissions. However, when deploying a package to devices, ensure that the UNC path is accessible to domain computers with read permissions.
Assigned applications will deploy at logon (when this option is selected) or when a user clicks the shortcut for the application or a filetype associated with the application. Published applications (only available under User Configuration) will be installed when a user clicks the shortcut for the application or a filetype associated with the application. Published applications can also be installed using Apps and Features on domain-joined devices.
Software installation settings are not processed when slow links are detected.
The Advanced button can be used to further specify settings for application installation, including but not limited to the presence of other application installations and versioning requirements.
This recipe shows how to link an existing GPO to an OU.
To link a GPO to an OU, sign in to a system with the Group Policy Management feature installed with an account that is either of the following:
Perform the following steps:
A GPO is not applied to computer or user objects without a link.
Despite the name Group Policy, GPOs cannot be linked to groups.
When a domain-joined device processes Group Policy, it processes GPOs in this order:
When a user signs in, Group Policy is processed in the same order, except this time, the domain and OU structure are defined by the location of the user object instead of the computer object.
When there are overlapping settings in different GPOs linked in the preceding order, the last processed GPO with the settings applies.
When multiple GPOs are linked to the same OU, the GPO with the lowest link order is applied, as the settings are applied in the reverse sequence of the link order. Link order can only really be considered a priority when link enforcement and block inheritance don't come into play.
GPOs can be linked to sites, domains, and OUs. It's a bad idea to link a GPO to a site due to the nature of intra-domain replication of GPOs.
This recipe shows how to block inheritance of GPOs on an OU.
To block inheritance of GPOs on an OU, sign in to a system with the Group Policy Management feature installed with an account that is either of the following:
Perform the following steps:
The Block Inheritance and Enforce settings are two ways to manage how GPOs are processed.
Group Policy inheritance can be used in situations where an OU structure, site, or domain governs settings through GPOs, and where none of these settings are undesired. This way, any GPO will no longer be processed by computer objects and/or user objects in the OU and underlying OU structure that has inheritance blocked.
Managing inheritance is useful where you want to strictly manage test environments. However, it does add complexity to Group Policy and may result in situations that are harder to troubleshoot.
When not all settings are undesired, you can link the GPOs with the desired settings to the OU that has Block Inheritance configured.
This recipe shows how to enforce a GPO link to ensure that its settings always apply.
To enforce a GPO link, sign in to a system with the Group Policy Management feature installed with an account that is either of the following:
Perform the following steps:
The Block Inheritance and Enforce settings are two ways to manage how GPOs are processed.
In a complex environment where multiple conflicting GPOs may be applied, enforcing a GPO link ensures the GPO is processed and its settings are applied, regardless of Group Policy inheritance settings. It always takes precedence.
Group Policy can be linked to OUs but, despite its name, not to groups. However, this recipe shows how a security filter can be applied so that the GPO link only applies to members of a specific group.
To apply security filters on a GPO, sign in to a system with the Group Policy Management feature installed with an account that is either of the following:
Perform the following steps:
By default, all GPOs have the GpoApply permission assigned to the Authenticated Users group. This permission can be scoped down to a specific group by removing the default permission and adding a scoped group. When the GpoApply permission is absent, the settings in the GPO don't apply to each of its GPO links.
Since groups can be nested, security filtering can make Group Policy processing slow, especially in multi-forest environments.
This recipe shows how to apply a WMI filter so that GPOs only apply to specific domain-joined devices and systems. In this recipe, a WMI filter is shown that targets the domain controller with the Primary Domain Controller Emulator (PDCE) Flexible Single Master Operations (FSMO) role only.
To create WMI filters on a GPO, sign in to a system with the Group Policy Management feature installed with an account that is either of the following:
WMI filters can be used to target specific systems in the scope of a GPO throughout all its GPO links, based on the specifications of the device.
Only one WMI filter can be applied at a time for a GPO. Use WMI filters with caution because they can seriously impact the performance of Group Policy processing.
A WMI filter is very useful for targeting only the domain controller holding the PDCE FSMO role for a Group Policy that sets the Windows time service to synchronize time with a reliable external time source.
This recipe shows how to refresh Group Policy settings on domain-joined hosts after changing and/or adding GPOs.
This recipe shows two ways to refresh GPO settings:
To refresh Group Policy settings using Group Policy Management, sign in to a system with the Group Policy Management feature installed with an account that is a member of the Domain Admins group.
To refresh Group Policy settings using the command line on a domain-joined host, sign in to the host with an account that has local administrator privileges.
To refresh the GPO settings, choose between the two ways – using Group Policy Management and using the command line on a domain-joined host.
Perform these steps to refresh the GPO settings for an OU using Group Policy Management:
Use the following command to update Group Policy settings on an elevated Command Prompt (cmd.exe) on a domain-joined host:
gpupdate.exe
If you want to refresh all Group Policy settings, instead of merely the settings that have changed, add the /Force parameter to this command.
The Group Policy client on domain-joined hosts typically refreshes Group Policy settings in the background. By default, GPOs are refreshed in the background every 90 minutes, with a 30-minute window of additional time to avoid clobbering the domain controllers. Domain controllers refresh GPOs every 5 minutes.
Using the methods in this recipe, the refresh is immediate. This allows for expedited testing of Group Policy settings and/or a more passionate troubleshooting.
This recipe shows how to configure Group Policy loopback processing.
To configure Group Policy loopback processing, sign in to a system with the Group Policy Management feature installed with an account that is either of the following:
In Group Policy loopback processing mode, Group Policy processing is changed. With default settings, the computer object processes the Computer Configuration parts of GPOs and the user object processes the User Configuration parts of GPOs. In loopback processing mode, though, Group Policy processing is different. It can be configured in two ways:
Group Policy loopback processing is ideal for the implementations of Remote Desktop Session Hosts and other Remote Desktop, Terminal Server, and Virtual Desktop Infrastructure (VDI) implementations. The user settings configured in the GPOs linked to the computer objects only apply when users sign in to these hosts but not when they sign in to other domain-joined devices.
This recipe shows how to restore the Default Domain Policy and the Default Domain Controllers Policy to default settings.
To restore the Default Domain Policy and the Default Domain Controllers Policy to default settings, sign in to a non-read-only domain controller with an account that is a member of the Domain Admins group.
The dcgpofix.exe command-line utility can be used to restore the Default Domain Policy and the Default Domain Controllers Policy to their default settings.
Use the following command to restore the Default Domain Policy to its default settings on an elevated Command Prompt (cmd.exe):
dcgpofix.exe /target:Domain
Type Y followed by Enter twice to continue and restore the Default Domain Policy.
Use the following command to restore the Default Domain Controllers Policy to its default settings on an elevated Command Prompt (cmd.exe):
dcgpofix.exe /target:DC
Type Y followed by Enter twice to continue to restore the Default Domain Controllers Policy.
Use the following command to restore the Default Domain Policy and the Default Domain Controllers Policy to their default settings on an elevated Command Prompt (cmd.exe):
dcgpofix.exe /target:BOTH
Type Y followed by Enter twice to restore the Default Domain Policy and the Default Domain Controllers Policy.
When you want to revert to the default settings for the Default Domain Policy and the Default Domain Controllers Policy, or if you've deleted them, they can be easily restored using the dcgpofix.exe command-line utility.
As there have been changes to the Default Domain Policy and the Default Domain Controllers Policy across versions of Windows Server and the Active Directory schema, dcgpofix.exe checks the schema version. If the schema level is different from the current domain controller operating system, dcgpofix.exe displays the following message:
The Active Directory schema version for this domain and the version supported by this tool do not match. The GPO can be restored using the /ignoreschema command-line parameter. However, it is recommended that you try to obtain an updated version of this tool that might have an updated version of the Active Directory schema. Restoring a GPO with an incorrect schema might result in unpredictable behavior.
In this case, add the /ignoreschema parameter to the previous command-line examples.
This recipe shows how to configure the Group Policy Central Store in the SYSVOL to optimize Group Policy authoring and replication.
Implement or locate a default Windows client device with Microsoft Office and any other software that supports Group Policy management. Install language packs for the languages that are used by admins in your organization. Update this system with the latest available Windows updates.
To create the Group Policy Central Store, sign in to a non-read-only domain controller or access the SYSVOL over the network with an account that is a member of the Domain Admins group.
Since Windows Server 2008 and Windows Vista, Group Policy settings in the Administrative Templates parts of GPOs are represented on the filesystem by the *.admx and *.adml files. The first type of file defines settings. The latter type of file provides language-dependent labels, so administrators can work together seamlessly using different languages.
Beyond the language benefit, the new file types also allow a central store to store all Group Policy settings and language settings in the SYSVOL. This way, files for configured settings no longer have to be stored with each GPO in the SYSVOL, only once in the SYSVOL. This optimizes Group Policy replication between domain controllers significantly.
Creating the Group Policy Central Store requires a process that is revisited when new software versions are introduced within an organization. Overwrite the *.adml and *.admx files with the newer versions.
3.147.65.65