Most enterprise forests have GPOs that pre-date the engineers running them. Twenty years of policy accretion: the original baseline from Windows Server 2003, the security tightening for SOX, the ad-hoc fix for the Outlook bug in 2013 that nobody remembered to remove. The job is not to throw it out and start over. It is to consolidate without losing settings that someone, somewhere, still depends on.

The work breaks into five stages: discover, attribute, map, consolidate, retire. Each stage has its own failure modes.

Discovery — what's actually there

Get-GPOReport -All -ReportType Xml is your starting baseline. Save it. You will diff against it later — the diff is your evidence that the consolidation actually changed something.

gpresult /h against representative target machines (one per OU pattern) shows what actually applies, as distinct from what is authored. Many GPOs are authored but filtered out by security or WMI; they show in GPMC and don't show in gpresult. Both views matter.

GPMC's reports are useful but don't surface filtered-out GPOs cleanly. PowerShell does. Beware "empty" GPOs that exist only to delegate permissions — they don't appear in gpresult but they shape the security model. Their continued existence is the security control; deleting them silently expands access.

The "who owns this GPO" problem

The Owner field on a GPO is rarely accurate — it's the SID of the engineer who created the policy, often long gone from the company. Real ownership lives in change-control systems, which most orgs lost when the wiki or SharePoint platform changed and the migration didn't preserve attribution.

The practical method: snapshot GPO ACLs, then trace from group memberships to current employees. The GPOs no current employee can be tied to are candidates for retirement. Add a "last modified" attribute review — GPOs untouched for five-plus years are higher candidates, because settings inside them may apply to systems that no longer exist in the environment.

The hardest cases are GPOs where the only "owner" is a service account that no one knows the purpose of. Those need stakeholder hunts: search every change ticket from the last five years that references the GPO, identify whoever approved them, ask their team. About half the time you will find someone who can confirm the purpose. The other half become formal candidates for the retirement queue.

Dependency mapping

Each GPO has three dimensions of dependency: where it is linked (sites, domains, OUs), what filters apply (security filtering plus WMI filters), and what scripts or external systems reference it.

Cross-reference with login scripts: many login scripts call back to GPO-set environment variables. Removing the GPO breaks the script silently — the user logs in, the script runs, the script's branch logic falls through to a default that nobody designed.

Cross-reference with Software Installation policies: legacy MSI deployments via GPO need a separate sunset plan. Modern endpoint management (Intune, ConfigMgr) is the destination; the GPO is the historical artifact.

Cross-reference with PKI: certificate auto-enrollment is GPO-driven. Auto-enrollment GPOs are the worst category to "consolidate." Get them wrong and you have a fleet of machines with expired certificates and no obvious symptom until they fail to authenticate.

Consolidation strategy

Don't merge. Layer.

Build new "purposeful" GPOs (Security Baseline, Workstation Configuration, Server Configuration, Application Settings) at the right OU level. Move settings from legacy GPOs into the new structure one category at a time — move all "Internet Explorer" settings, then audit, then move all screen-lock settings, then audit. Don't move the entire policy at once; you lose the diff.

The old GPOs stay linked but disabled — for ninety days minimum — before retirement. This creates a rollback window without changing what applies. If something breaks during the disabled period, re-enable the GPO and start the dependency hunt for what depends on the disabled settings.

The temptation is to merge two similar GPOs into one. Resist it. The merge looks clean in GPMC but loses the audit trail of why each setting was added. Layered policies preserve attribution; merged policies erase it.

Retiring safely

"Linked but disabled" is the safe state for retirement. The GPO still exists, can be re-enabled if something breaks, but doesn't apply. The setting is functionally removed; the policy object remains for forensic and audit purposes.

After ninety days of "linked but disabled" with no incidents, unlink. Wait another thirty days. Then delete. Keep the GPO XML reports archived — the setting may need to be referenced for an audit two years later, and "we deleted it cleanly" is not a defensible answer.

Special caution for: AppLocker policies (re-enabling requires testing because re-application can leave systems in an enforcement gap), security baselines (settings tombstone in unexpected ways — some persist in registry even after the GPO is removed), drive-mapping policies (users develop muscle memory around drive letters and call helpdesk when they change).

Operational discipline going forward

The cleanup is half the value. The other half is preventing the same accumulation from happening again.

New GPOs need a documented purpose, owner, and review date. The review date is the load-bearing item — without it, every GPO becomes "set and forget" and accumulates the same way the original ones did.

Quarterly "GPO health review" — run Get-GPOReport diff against last quarter, flag changes you don't recognize, demand attribution for unrecognized changes. The review is procedural, not analytical; thirty minutes per quarter prevents fifteen weeks of cleanup later.

Treat GPOs as code, not configuration in the GUI. That means version control of the GPO XML, peer review for changes to security baselines, change tickets for production changes. It will feel like overkill until the first time you need to roll back a baseline change in front of an auditor.

The second cleanup

GPO modernization is not a one-time project. It is an ongoing operational discipline that pays off only after the first painful pass. The first cleanup is hard because so many GPOs have unknown dependencies. The second cleanup is easy because you have the dependency map.

Get to the second cleanup.