Windows Server · How-To
Create and Link Group Policy Objects (GPOs)
A Group Policy Object (GPO) is a container of settings you push to users and computers across an Active Directory domain. You create one in Group Policy Management, link it to a domain or Organizational Unit so it takes effect, then edit the settings inside it. Machines pick up changes on their next refresh — or immediately when you run gpupdate — and you confirm what actually applied with gpresult. Creating a GPO and linking it are two separate acts, and understanding that distinction is most of the battle.
This guide covers the whole loop end to end with general, version-safe steps. The console, cmdlets and command-line tools below have been stable across recent Windows Server releases, so they apply whether you are on the latest Windows Server or a slightly older build in your environment. It assumes you already have a working domain — if you do not, start with setting up Active Directory on Windows Server first.
Think of a GPO as a named bundle of rules — password length, drive mappings, a locked-down desktop, an allowed app list — stored centrally in the domain. Instead of touching every PC, you define the rule once and target it at the right group of machines or people. Windows enforces it automatically and re-checks it on a schedule, so settings do not drift over time.
Before you begin
You will do this from a domain controller, or from a management PC that has the Group Policy Management tools installed (part of the Remote Server Administration Tools). You also need an account with rights to create and link GPOs — a member of Group Policy Creator Owners can create them, while linking to a domain or OU requires delegated permission or membership of Domain Admins.
Step 1 — Open Group Policy Management
- Open Server Manager and choose Tools → Group Policy Management, or
press Win+R and run
gpmc.msc. - Expand Forest → Domains and select your domain. You will see your Organizational Units, the built-in Group Policy Objects container, and any existing links.
The Group Policy Management Console (GPMC) is your single pane of glass: every GPO in the domain lives in the Group Policy Objects node, and everywhere it is linked shows up under the matching site, domain or OU.
Step 2 — Create a new GPO
There are two ways to create a GPO, and they differ only in whether the link is made for you:
- Create unlinked: right-click the Group Policy Objects container and choose New. This makes the GPO but does not attach it anywhere yet — handy when you want to build and test it before it goes live.
- Create and link in one step: right-click the target OU and choose Create a GPO in this domain, and Link it here. This creates the object and links it to that OU at the same time.
Either way, give the GPO a clear, descriptive name such as Staff — Screen
Lock or Workstations — Firewall Baseline. Good names save you hours later when a domain
has dozens of policies.
A convention like <target> — <purpose> makes the GPO list self-documenting. When something misbehaves, you want to read the name and instantly know which accounts it touches and why it exists, without opening it.
Step 3 — Link the GPO to an OU or domain
A GPO only does something once it is linked to a container that holds accounts. If you created the GPO unlinked, attach it now:
- In GPMC, right-click the Organizational Unit (or the domain) you want the policy to reach and choose Link an Existing GPO.
- Pick your GPO from the list and click OK. It now applies to every user or computer object in that OU and its child OUs, unless inheritance is blocked or filtering excludes them.
Link where the objects live: computer settings only affect computer accounts, and user settings only affect user accounts, so the account must sit in — or below — the linked OU. Linking a computer-focused policy to an OU that contains only users will quietly do nothing.
It is tempting to drop everything into the built-in Default Domain Policy, but keep that one for domain-wide account and password settings only. Put your day-to-day rules in purpose-built GPOs linked to specific OUs. Overloading the default policy makes problems far harder to isolate later.
Step 4 — Edit a common policy
Now put a setting inside the GPO. Right-click the GPO (under the OU link or in the Group Policy Objects container) and choose Edit. This opens the Group Policy Management Editor, which is split into two halves:
- Computer Configuration — settings applied to the machine at startup and on refresh, regardless of who signs in.
- User Configuration — settings applied to the person at sign-in and on refresh, wherever they log on.
As a first, safe example, set a screen-lock timeout. Navigate to Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options and configure the interactive logon inactivity limit, or use an Administrative Templates setting under User Configuration to control the screen saver. Double-click a setting, switch it to Enabled, set its value, and click OK. Close the editor when you are done — there is no separate save step.
Step 5 — Apply the change and refresh
By default, member computers refresh Group Policy in the background roughly every 90 minutes (with a random offset), and at startup or sign-in. To apply changes now on a target machine, open an elevated command prompt or PowerShell and run:
gpupdate /forceThe /force switch reapplies every setting rather than only those that changed, as the
gpupdate command reference on Microsoft Learn puts it. Some policies —
software installation, folder redirection, drive maps — only take effect at startup or sign-in, so
gpupdate may ask you to log off or restart. That prompt is normal.
Step 6 — Control scope with precedence and filtering
Once you have more than one GPO, you need to understand which one wins and how to narrow a policy to a subset of accounts.
Precedence and inheritance
Group Policy is processed in a fixed order: Local → Site → Domain → Organizational Unit, and within a single OU by link order. The policy processed last wins, so a GPO linked closer to the account normally overrides one linked higher up — Microsoft Learn's Group Policy processing for Windows reference sets out this order and notes that the AD container closest to the account overrides settings from higher-level containers. Two levers change this:
- Enforced — right-click a GPO link and set Enforced to make it win over anything lower down. Use this sparingly for non-negotiable settings.
- Block Inheritance — set on an OU to stop policies from higher levels flowing into it. Enforced GPOs still get through, which is the point of Enforced.
Select any OU and open the Group Policy Inheritance tab to see the effective order at a glance — it is the fastest way to reason about a conflict.
Security filtering
By default a linked GPO applies to Authenticated Users — every user and computer in scope. To target a subset, use security filtering: select the GPO, open the Scope tab, and in the Security Filtering section click Add to name a specific security group, then remove Authenticated Users if you want only that group to receive it.
Since the changes Microsoft made to Group Policy security hardening, an account still needs Read on the GPO for it to apply. If you remove Authenticated Users from the scope filter, make sure the group you filter to (or the computer accounts involved) can still read the GPO, otherwise it silently fails to apply. The Delegation tab is where you check and fix that.
Step 7 — Verify with gpresult
GPMC tells you what should happen; gpresult tells you what actually did. On a target
machine, open an elevated prompt and run:
gpresult /rThis prints a summary of the applied GPOs for the computer and the signed-in user, along with any that
were filtered out and why — Microsoft's
gpresult command reference documents /r as the Resultant Set of Policy summary and
/h as an HTML report. For a fuller, shareable report, generate an HTML file:
gpresult /h C:\gpreport.htmlOpen that file in a browser to see every setting, its winning GPO, and the resultant set of policy. If a setting is not landing, this report almost always shows the reason — a missing link, a filtered group, or a higher policy overriding yours.
Where to go next
With the create-link-edit-verify loop in hand, the natural next steps are to build a small library of purpose-named GPOs per OU, and to add a second domain controller so Group Policy and authentication stay available if one server goes offline. When a policy stubbornly refuses to take, work through Group Policy not applying for the usual DNS, replication and filtering culprits. For more background on the directory these policies live in, see the wider Windows Server section.
Frequently asked
What is the difference between creating a GPO and linking it?
Creating a GPO makes a policy object that lives in the Group Policy Objects container in your domain. On its own it does nothing. Linking is what attaches that GPO to a site, domain or Organizational Unit so that the accounts in that location actually receive its settings. A single GPO can be linked in more than one place, and a link can be disabled without deleting the GPO, so it is worth keeping the two ideas separate in your head.
Why is my new GPO not applying to users?
The most common reasons are that the GPO is not linked to the Organizational Unit the accounts actually sit in, that the link is disabled, or that security filtering excludes those accounts. Remember that computer settings apply to computer objects and user settings apply to user objects, so the account has to be in, or below, the linked OU. Run gpupdate /force on the client and then gpresult /r to see exactly which GPOs were applied and which were filtered out.
What does gpupdate /force do?
gpupdate tells a machine to reprocess Group Policy immediately instead of waiting for the normal background refresh, which happens roughly every 90 minutes for member machines. Adding /force reapplies every setting rather than only the ones that changed, which is useful when you are testing a new GPO. Some settings, such as software installation or folder redirection, only apply at startup or sign-in, so gpupdate may prompt you to log off or restart.
How does GPO precedence work when policies conflict?
Group Policy is processed in the order local, site, domain, then Organizational Unit, and within an OU by link order. The setting applied last wins, so a GPO linked closer to the account normally overrides one linked higher up. You can change this with the Enforced option, which forces a higher GPO to win, and with Block Inheritance on an OU, which stops higher policies from flowing down unless they are Enforced.
Browse all how-to guides for more Windows and Windows Server walkthroughs, or dig through the windows-now.com archive of restored community posts.