A setting you changed an hour ago still isn't on the laptop, and the user is waiting on the phone while you type gpupdate /force for the third time. Group Policy has configured Windows fleets since Windows 2000, but it hides behind three tools with nearly identical names and a precedence model that decides silently which setting wins. This guide covers the Group Policy Editor end to end: which editor to open, how local and domain policy stack, what gpupdate /force does and doesn't do, and how to find out why a policy isn't landing.
TL;DR
- "Group Policy Editor" means three different tools.
gpedit.mscedits one computer's local policy. GPMC (gpmc.msc) creates, links and scopes domain policies. The Group Policy Management Editor opens from GPMC to edit one domain GPO. - Windows 11 Home doesn't ship
gpedit.msc, and it can't join a domain, so neither local nor domain Group Policy is a supported option there. - Policies apply in order: local, site, domain, then OU, with the closest OU applied last. The last writer wins, unless a GPO is Enforced.
- Windows refreshes policy in the background every 90 minutes plus a random offset of up to 30 minutes. Domain controllers refresh every five minutes.
gpupdate /forcereapplies every setting, not only changed ones. It won't finish jobs that need a restart or a sign-out, like software installation or folder redirection. That's what/bootand/logoffare for.- When a policy doesn't apply, run
gpresult /hfirst. It tells you which GPOs applied, which were denied, and why.
Group Policy Editor, GPMC and the Management Editor: Three Tools, One Name
Search for "Group Policy Editor" and you get instructions for three different consoles. They share a lot of screens, so it's easy to edit the wrong thing and wonder why nothing changed.
The Local Group Policy Editor is gpedit.msc. It edits the policy stored on the computer you're sitting at, and only that computer. Microsoft's own description calls it an MMC snap-in with two halves: Computer Configuration, applied at startup and on background refresh, and User Configuration, applied at sign-in and on background refresh. On a standalone PC or a workgroup, this is all the Group Policy you have.
The Group Policy Management Console is gpmc.msc. It doesn't edit settings itself. It's where you create Group Policy Objects (GPOs) in Active Directory, link them to sites, domains and organizational units (OUs), and decide who they apply to. It also runs reports, backs GPOs up and models what would happen if you moved a user.
The Group Policy Management Editor opens when you right-click a domain GPO in GPMC and choose Edit. It looks almost identical to gpedit.msc, with the same Computer Configuration and User Configuration trees and the same Administrative Templates. The difference is where the settings go: into a GPO stored on the domain controllers, not into the local machine.
A quick way to keep them straight: gpedit changes one machine, GPMC decides where a policy goes, and the Management Editor decides what the policy says.
| Tool | Command | Edits | Scope | Where you'll find it |
|---|---|---|---|---|
| Local Group Policy Editor | gpedit.msc | Local policy on this PC | One computer | Pro, Enterprise, Education |
| Group Policy Management Console | gpmc.msc | Links, scope, filters, backups | Whole domain | Domain controllers, or RSAT on a workstation |
| Group Policy Management Editor | Edit from GPMC | One domain GPO | Wherever that GPO is linked | Opens from GPMC |
gpupdate | gpupdate /force | Nothing, it refreshes | This computer | Every edition with Group Policy |
gpresult | gpresult /h report.html | Nothing, it reports | This computer and user | Every edition with Group Policy |
Andy Malone's walkthrough covers the same split from the domain side, including how GPMC links a GPO to an OU:
If you manage a client's domain from your own workstation, you'll mostly live in GPMC and the Management Editor. gpedit.msc is for standalone machines, lab boxes and checking what's been set locally before a domain policy overwrites it.
How to Open the Group Policy Editor on Windows 11
The fastest route is the Run box. Press Win+R, type gpedit.msc and press Enter. You can also type gpedit into Start search and pick "Edit group policy". Either way, you need an account with local admin rights to change anything.
For a saved console, open mmc, choose File, then Add/Remove Snap-in, and add Group Policy Object Editor. The Browse button lets you target the local computer, another computer, or one of the per-user local policies covered below. Save the console and it opens straight to that target next time.
Inside, settings live in two trees. Computer Configuration applies to the machine no matter who signs in. User Configuration follows the user. Each tree splits into Software Settings, Windows Settings (scripts, security settings, folder redirection) and Administrative Templates, which is where the bulk of the registry-based settings sit.
Administrative Templates run to thousands of settings, and scrolling through folders is the slow way to find one. Right-click Administrative Templates and choose Filter Options. You can search by keyword in the title, the explanation text or the comments, and show only settings that are configured. This r/sysadmin thread is where plenty of admins learned it exists:
The same filter works in the Management Editor for domain GPOs. "Configured: Yes" is the quickest way to audit what a GPO does before you change it.
Why gpedit Is Missing on Windows 11 Home
If gpedit.msc returns "Windows cannot find", you're almost certainly on Home. The Local Group Policy Editor ships with Pro, Enterprise and Education, and Home doesn't include it. Home also can't join an Active Directory domain, so domain GPOs aren't an option either.
Forum posts pass around a DISM loop that installs the Group Policy client packages from the servicing folder. It can make the console appear. It isn't a supported configuration, and the Microsoft Q&A answer that shares it warns that the templates may not behave as they do on Pro and that updates could break it. For a business device, the fix is a Pro license, which is an in-place upgrade with a new product key and no reinstall.
For a single setting on a Home machine, the registry value behind the policy is the practical route. Our guide to turning off Windows notifications shows the registry keys next to the matching policies for one common case.
Multiple Local Policies on One PC
Local policy has more than one layer. Since Windows Vista, a standalone PC can hold three layers of local GPOs, applied in order. First the Local Computer Policy, which holds computer settings and user settings for everyone. Then either the Administrators or the Non-Administrators policy, depending on who signs in. Last, a per-user policy for one named local account.
Microsoft's guide describes the rule as "Last Writer Wins". A setting enabled in the Local Computer Policy and disabled in a per-user policy ends up disabled for that user. That makes it possible to lock down a shared kiosk for regular users while leaving the local admin alone, without a domain.
On a domain-joined machine, every local layer applies first and domain policy applies after it. Any conflicting domain setting wins. Domain admins can switch off local policy processing entirely with the "Turn off Local Group Policy Objects processing" setting under Computer Configuration, Administrative Templates, System, Group Policy.
Local vs Domain Group Policy: Which Setting Wins
In a domain, a computer gathers policy from four places and applies it in a fixed order. Microsoft documents it as local first, then GPOs linked to the site, then the domain, then OUs. With nested OUs, the parent OU's GPOs apply before the child's. Admins shorten this to LSDOU.
Order matters because each GPO overwrites what came before it. A password setting in the domain GPO beats the same setting in local policy. A screen-lock timeout linked to the Finance OU beats the domain default. The setting closest to the object usually wins, because it's written last.
Within one container, link order decides it. In GPMC, the Linked Group Policy Objects tab lists a link order, and link order 1 has the highest precedence. The GPO with link order 1 is applied last, so it wins ties. Drag a GPO up the list and it wins more often.
Two switches change the defaults. Block Inheritance on an OU stops GPOs from parent containers, including the domain, from applying to it. Enforced on a GPO link stops lower containers from overriding it, so a domain GPO marked Enforced wins against every OU below it. When both are set, Enforced beats Block Inheritance. Microsoft's documentation is explicit on that, and it's what lets a security baseline survive an OU that blocks everything else.
Use both sparingly. Every Enforced link and every blocked OU is an exception someone has to remember during troubleshooting. A structure that relies on link order and clean OUs is easier to reason about a year later, when nobody remembers why the Sales OU blocks inheritance.
Computer settings and user settings also interact. By convention, where the same thing can be set in both halves, the computer setting wins. Keep a setting in the half it belongs to and this rarely comes up.
Scoping a GPO: Links, Security Filtering and Loopback
Linking a GPO to an OU only makes it a candidate. Three more checks decide whether a given user or computer processes it.
Security filtering decides who reads the GPO. By default, Authenticated Users has Read and Apply Group Policy on every new GPO. Remove Authenticated Users and add a security group instead, and only members of that group get the settings. This is how you roll a change out to a pilot group before the whole OU.
There's a trap here that still breaks rollouts. The MS16-072 security update from June 2016 changed how Windows retrieves user policy: it now uses the computer's security context, not the user's. If you filter a user GPO to a group of users and remove Authenticated Users entirely, the computer can no longer read the GPO, and the user settings silently stop applying. Microsoft's MS16-072 guidance is to keep Authenticated Users with Read, or add Domain Computers with Read, while the Apply permission stays with your target group.
WMI filters add a condition evaluated on the device, such as "only Windows 11" or "only laptops". They're flexible and slow. Each one runs a query at every refresh, so keep them few and simple.
Loopback processing flips which user settings apply. Normally, user settings follow the user's OU no matter which computer they sign into. Enable "Configure user Group Policy loopback processing mode" on a computer GPO and the user settings follow the computer instead. Merge mode adds the computer's GPOs after the user's own, so the computer's win conflicts. Replace mode ignores the user's GPOs entirely. Microsoft's loopback article points to kiosks, labs, classrooms and shared terminal servers as the use case. It only works when both the user and the computer are in Active Directory.
When a GPO is linked correctly and still doesn't apply, the answer is almost always in one of these three checks. gpresult names the filter that denied it, which is why it's the first command in the troubleshooting section below.
How to Install GPMC on Windows 11
GPMC is already on every domain controller. On a Windows 10 or 11 admin workstation, it comes with the Remote Server Administration Tools (RSAT), which install as Features on Demand since Windows 10 version 1809.
In Settings, go to System, then Optional features, then View features, and search for "RSAT: Group Policy Management Tools". From an elevated PowerShell prompt, the same install is one line:
powershellAdd-WindowsCapability -Online -Name Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0
The DISM version works from a Command Prompt or a task sequence:
cmdDISM /Online /Add-Capability /CapabilityName:Rsat.GroupPolicy.Management.Tools~~~~0.0.1.0
The capability installs the Group Policy Management Console, the Management Editor and the Starter GPO Editor. It also brings the GroupPolicy PowerShell module, which you'll want for Invoke-GPUpdate, Get-GPResultantSetOfPolicy and GPO backups. Our list of useful PowerShell commands covers the everyday ones around it. Devices that pull updates from WSUS sometimes fail to download Features on Demand, and the fix is the same Group Policy setting that lets optional features come straight from Windows Update.
Build a Central Store for Administrative Templates
Administrative Templates are ADMX files, with language files (ADML) beside them. On a single PC they live in C:\Windows\PolicyDefinitions. In a domain, create a Central Store: a PolicyDefinitions folder inside SYSVOL, such as \\contoso.com\SYSVOL\contoso.com\Policies\PolicyDefinitions. Microsoft notes that Group Policy tools check it by default, and SYSVOL replicates it to every domain controller.
Without a Central Store, each admin's editor reads templates from their own machine. Two admins on different Windows versions then see different settings, and newer settings show up as "Extra Registry Settings" in reports. Build the store from a current Windows 11 machine or the latest ADMX download, and add templates for Office, Edge and anything else you manage. Microsoft suggests building a new versioned folder, such as PolicyDefinitions-25H2, and swapping it in by renaming, so you can roll back if a template misbehaves.
gpupdate and gpupdate /force: What They Do
Group Policy refreshes on its own. Microsoft's defaults: computers and users refresh in the background every 90 minutes, with a random offset of 0 to 30 minutes so a whole office doesn't hit the domain controllers at once. Domain controllers refresh every five minutes. On top of that, Windows applies computer policy at startup and user policy at sign-in, which Microsoft calls foreground processing.
gpupdate asks for that refresh now instead of waiting. Plain gpupdate applies only settings that changed since the last refresh. gpupdate /force reapplies every setting, changed or not. That's useful when someone has changed a setting locally and you want policy to put it back, or when you're not sure whether the last refresh saw your change.
The switches matter more than /force. Microsoft's gpupdate reference lists them:
cmdgpupdate /target:computer :: only computer settings (or /target:user) gpupdate /force :: reapply all settings, not only changed ones gpupdate /wait:0 :: return immediately (default wait is 600 seconds) gpupdate /logoff :: sign out after refresh if an extension needs it gpupdate /boot :: restart after refresh if an extension needs it gpupdate /sync :: make the next startup or sign-in apply policy synchronously
Some client-side extensions don't process during a background refresh at all. User-targeted software installation and folder redirection wait for a sign-in. Computer-targeted software installation waits for a restart. For those, gpupdate /force reports success and the setting still isn't there. /logoff and /boot trigger the sign-out or restart only when an extension needs one.
Drive mappings and printer preferences can behave the same way when they're set to apply in the foreground. If a setting only lands after a reboot, it probably needs a foreground cycle, and more gpupdate runs won't change that.
This r/sysadmin thread is a good snapshot of how admins use /force in practice, and when a plain gpupdate would have done:
/force has a cost at scale. It makes every client-side extension reprocess, which means more reads from SYSVOL and more work on the endpoint. On one machine that doesn't matter. Scripted across 500 machines at 9 a.m., it's a spike your domain controllers will notice.
How to Force a Group Policy Update Remotely
Walking to a desk to run gpupdate doesn't scale. There are three remote options, and they suit different jobs.
From GPMC. Right-click an OU and choose Group Policy Update. GPMC schedules a refresh on every computer in that OU and shows which ones succeeded. It's the quickest option for a single OU after a change.
With PowerShell. Invoke-GPUpdate from the GroupPolicy module schedules the same refresh on a named computer:
powershellInvoke-GPUpdate -Computer "WS-ACCT-014" -Target Computer -RandomDelayInMinutes 0 -Force Get-ADComputer -Filter * -SearchBase "OU=Finance,DC=contoso,DC=com" | ForEach-Object { Invoke-GPUpdate -Computer $_.Name -RandomDelayInMinutes 10 }
It works by creating a scheduled task on the target that runs gpupdate. -RandomDelayInMinutes 0 runs it as soon as the task is created, and a larger value spreads the load, up to 44,640 minutes (31 days). One confusing detail: -Force on this cmdlet suppresses the confirmation prompt. It isn't the same as gpupdate /force.
Invoke-GPUpdate depends on the target's firewall. Microsoft lists three inbound rules that must be enabled on each client: Remote Scheduled Tasks Management (RPC), Remote Scheduled Tasks Management (RPC-EPMAP) and Windows Management Instrumentation (WMI-In). If the cmdlet fails with an RPC error, check those rules before anything else. The GPMC right-click method uses the same mechanism, so it fails for the same reason.
With a remote shell. If PowerShell remoting is already set up, Invoke-Command -ComputerName WS-ACCT-014 { gpupdate /force /target:computer } runs the command directly. That needs WinRM configured on the target, which is a separate decision with its own security trade-offs.
Active Directory Pro's video shows gpupdate locally and the remote update from GPMC side by side:
For devices outside the office, the domain controller is often the missing piece. A laptop on home Wi-Fi without a VPN can't reach SYSVOL, so no remote trigger helps until it can. That's a gap an RMM agent covers, because it doesn't need line of sight to a domain controller to run a command. OpenFrame, for example, can run gpupdate or gpresult as a script across a client's devices and collect each device's output in one place.
Why a Group Policy Isn't Applying
Start with the report, not the refresh. On the affected machine, open an elevated prompt and run:
cmdgpresult /r /scope:computer gpresult /h %TEMP%\gp.html
/r prints a summary: which domain controller answered, which GPOs applied, and which were filtered out and why. /h writes an HTML report with every winning setting and the GPO it came from. Run it as the affected user for user settings, since gpresult reports on the account that runs it. GPMC's Group Policy Results wizard builds the same report remotely.
If the GPO shows as denied, the reason is usually printed next to it: "Access Denied (Security Filtering)", "WMI filter", "Empty" or "Disabled Link". If the GPO isn't listed at all, it isn't linked where you think, or the computer object sits in a different OU than you assumed.
Next, read the logs. Group Policy writes warnings and errors to the System log and a detailed trace to Applications and Services Logs, Microsoft, Windows, GroupPolicy, Operational. Microsoft's troubleshooting guide maps the common event IDs to causes:
| Check | Command or place | What it tells you |
|---|---|---|
| 1. Which GPOs applied | gpresult /r | Applied and denied GPOs with the reason |
| 2. Which setting won | gpresult /h report.html | Every winning setting and its source GPO |
| 3. Is the object where you think | ADUC or Get-ADComputer -Identity <name> | The OU the computer or user sits in |
| 4. Link order and Enforced | GPMC, Linked Group Policy Objects tab | Which GPO wins in that container |
| 5. Security filtering | GPMC, Delegation tab | Authenticated Users or Domain Computers still has Read |
| 6. Domain controller reachable | Event ID 1129 in the System log | Network or LDAP port 389 blocked |
| 7. SYSVOL readable | Event ID 1058 | Name resolution, DFS or replication issue |
| 8. Authentication | Event IDs 1006 and 1097 | Credentials, or a clock more than five minutes off the DC |
| 9. Needs a restart or sign-out | Operational log, extension events | Software install or folder redirection pending |
| 10. Change made on one DC only | Compare the GPO version on each DC | Replication hasn't reached the DC the client uses |
A few of those deserve a line each. Event ID 1129 means the machine couldn't reach a domain controller, which is expected off-network and a firewall problem on-network. Event ID 1058 means the machine found the GPO but couldn't read its files from SYSVOL, which points at DNS, the DFS client or replication. Event ID 1097 often traces back to time: Microsoft's guidance notes that a difference of more than five minutes between the computer and the domain controller can break authentication, and w32tm /resync is the first fix.
For the stubborn cases, Microsoft documents a verbose Group Policy service log. Set the GPSvcDebugLevel value under HKLM\Software\Microsoft\Windows NT\CurrentVersion\Diagnostics to 0x30002, create %windir%\debug\usermode if it doesn't exist, run gpupdate /force and read gpsvc.log in that folder. Turn it off afterwards, because verbose logging costs disk space and performance.
Policy that affects updates is a common place to hit these issues. Our guide to stopping Windows Update walks through the update-specific policies and how they interact with Defender, which is a good test case for everything in this section.
Group Policy on Entra-Joined and Intune-Managed Devices
Group Policy needs Active Directory. A device joined only to Microsoft Entra ID, with no on-premises domain, doesn't process domain GPOs, because there's no domain controller to ask. Local policy still works on Pro and above, but it doesn't scale past a handful of machines.
For cloud-joined fleets, Intune's settings catalog carries many of the same settings through configuration service providers (CSPs). Microsoft built a bridge for the move: Group Policy analytics in Intune. You export a GPO from GPMC as an XML report (under 4 MB), import it, and Intune shows the percentage of settings with an MDM equivalent, flags deprecated ones, and can turn the supported settings into a settings catalog policy.
Hybrid-joined devices get both, which creates its own precedence question. Windows has a policy to let MDM settings win over the matching Group Policy settings, and without it, Group Policy can quietly overwrite what Intune set. Decide which system owns which setting before you migrate, and move settings in blocks rather than one at a time. Our review of Microsoft Intune for MSPs covers where Intune fits and where it runs short for multi-client work.
Some policies won't move at all. Printer deployment through Group Policy Preferences, logon scripts and a long tail of legacy settings have no direct CSP. Group Policy analytics lists them under "Not supported", which is the list to plan around before promising a client a domain-free future.
The Short Version
The Group Policy Editor is three tools: gpedit.msc for one machine, GPMC for placing domain policy, and the Management Editor for writing it. Policy stacks local, site, domain, OU, and the last writer wins unless a GPO is Enforced. Scoping lives in links, security filtering, WMI filters and loopback, and MS16-072 means computers still need Read on user GPOs.
Windows refreshes on its own every 90 minutes plus up to 30. gpupdate /force reapplies everything but can't install software or redirect folders without a restart or sign-out. When something doesn't land, run gpresult /h before you run gpupdate again. For a practical next read, the same fleet-wide approach applies to BitLocker key escrow, a setting admins often push through Group Policy.

Aliaska Varieva
Head of Platform
Hi! I’m Aliaska, and I’ve been working as a software engineer (mostly Java + a bit Kotlin) for over 8 years now. I mostly spend my time building backend services, integrating systems, fixing bugs (the fun part 🙃), and making sure things don’t fall apart behind the scenes.
