Group Policy. It’s a service that just about every Windows administrator is familiar with. But what is Group Policy? Group Policy is a common way to apply configuration settings, install software, run scripts, and more across thousands of Active Directory (AD) domain-joined computers.
Group policy consists of many different services and workflows. Most administrators probably don’t even know how it works under the hood! In this article, we aim to change that.
If you’re interested in learning how Group Policy works, stay tuned because we’re going to leave no stone uncovered!
Table of Contents
Group Policy Objects (GPOs)
GPOs are the crux of Group Policy. GPOs are individual policies that contain many different settings to perform on a domain-joined computer.
In Windows 10/2019 Server there are more than five thousand settings covering all the relevant aspects of Windows. On top of that, you can import even more for specific applications: Office, Microsoft Edge, Google Chrome, LAPS-E are just a few. You can also create your own.
Think of a GPO as simply a single policy; it’s a manifest that contains instructions to perform tasks like setting a logon script, changing a user’s desktop, installing software and thousands of other tasks.
Active Directory stores GPOs in the Active Directory database that are replicated between domain controllers (DCs).
GPOs have two “categories” of settings; one for a computer and one for a user. These “categories” define how the settings inside of the GPO will apply to the computer. For example, if you need to change a user’s background, that would be user settings. If you need to install a system-wide software, that’d be a computer setting.
Once you create a GPO, you then target that GPO to a set of computers or users within an OU. The computer then periodically looks for new GPOs and applies those settings (more on this later).
Group Policy Templates
If a GPO is the primary component of Group Policy, the Group Policy Template (GPT) is the next important concept. The GPT goes hand in hand with the GPO.
Active Directory stores GPOs in SYSOL which is a file share on DCs to distribute files from. GPTs consist of registry settings, security files, applications, scripts and installers, shortcuts, XML files, graphic files, and so on, depending on what kind of settings you define in the corresponding GPO.
Managing Group Policy with the GPMC
Group Policy is controlled via the Group Policy Management Console (GPMC). This console is installed on all domain controllers and as part of the Remote Server Administration Toolkit (RSAT). The GPMC connects to the domain controller holding the Primary Domain Controller Emulator (PDCe) role to make changes to Group Policy.
Inside of the GPMC is where you can create and assign Group Policy Objects (GPOs) to Active Directory organizational units (OUs), Active Directory sites, and more.
How Group Policy Replication Works
As mentioned earlier, GPOs and GPTs are part of AD. As such, they are part of the typical Active Directory replication process.
A specific workflow kicks off when you create/update a new GPO and target it to an Active Directory OU.
- Once a GPO is changed via the GPMC, the GPMC connects to the PDCe DC.
- The GPMC then creates or modifies the GPO inside of the Active Directory databases and creates/updates the GPT in SYSVOL.
- Once modified, AD replication takes over and replicates both the GPO and GPT to the rest of the DCs according to the AD replication schedule. Replication usually takes up to 5 minutes if your “local” DC and the PDCE are in the same site or longer if they’re in different sites.
DCs also replicate the GPTs in SYSVOL once created with the GPMC but they do so via a separate replication mechanism called DFS-R. The replication schedule for SYSVOL is the same as the replication schedule for the AD database. Both components of a GP should arrive at roughly the same time on your local DC.
How GPOs are Applied
So the GPMC has created the GPO/GPT and they have been replicated to all DCs in your AD environment. Now what? Now the client(s) need to pick up the policy. At this point, it’s up to the client to check the DC for new/changed policies.
Clients adhere to their defined Group Policy refresh interval. This is the interval in which they routinely check for changes with their DC. By default, the refresh interval is set to 90 minutes, plus a random offset between 0 and 30 minutes.
If a DC is targeted with a policy, the default refresh interval is only five minutes.
Once the refresh interval is up, the Group Policy Client service on the client will check with the DC for any new or changed policies. If found, it will then download these policies and begin executing the instructions on the client computer.
The Group Policy Client service may not immediately apply new settings. Some settings cannot be applied immediately such as at the next logon, redirected folders, after the next restart, etc.
There are GPs which apply even there are no changes since the last time they were applied. A good example are security settings, which are re-applied at the computer startup and every 16 hours if the computer has not been restarted in the mean-time. This is important: if someone has made changes to a specific security configuration, they will be restored at the next refresh (think of opened firewall ports in Windows firewall, or members added to/ removed from Restricted Groups on the local computer).
Other settings may be configured to be reapplied even if the GP has not changed. You can control the behaviour of the GP Client for a particular type of setting via the registry, or, you guessed it, via GP.
If you’ve ever asked yourself, “What is Group Policy?”, I hope this tutorial was able to answer that question. Group Policy is a system that’s been around for a long time and is still used today by thousands of organizations. It’s a staple for many needing to apply changes across their Windows computer environment.
If you need to perform a change on one, ten or 1,000 domain-joined computers, be sure to take a look at Group Policy.