Fix ERROR_POLICY_ONLY_IN_DS (0X0000201C) in Active Directory

You're stuck with this error, and it's maddening

I know the feeling. You fire up Group Policy Management Console, run gpupdate on a domain controller, and bam — ERROR_POLICY_ONLY_IN_DS (0X0000201C). The system tells you the policy info is "only in the directory service." That's Microsoft-speak for: the policy object exists in AD but its corresponding GPT.INI and policy files are missing from Sysvol. Let me save you the rabbit hole I went down the first time.

The fix: Recreate the missing Sysvol folder for the faulty GPO

Here's the direct path. No fluff.

Open Group Policy Management Console (GPMC.msc) on a domain controller running Windows Server 2019 or 2022.
Find the GPO throwing the error. You'll see a warning icon next to it — something like "The GPO is disabled" or "The GPO may be corrupted." Right-click it and choose Save Report. Save the report as HTML to a temp folder. Open the report — it'll show you the GPO's unique GUID.
Open ADSI Edit (adsiedit.msc). Connect to the Default Naming Context. Navigate to CN=Policies,CN=System,DC=yourdomain,DC=com.
Find the folder matching the GPO GUID. Expand it — you should see CN=Machine and CN=User. If you don't see either, the policy object is half-deleted. Skip to the variation section below. If you see them, note the GUID.
Now check Sysvol on the PDCe (Primary Domain Controller emulator). Navigate to \\yourdomain\SYSVOL\yourdomain\Policies\{GUID}. If that folder is missing or empty, you've found the problem.
On the PDCe, create the missing folder structure manually. Open an elevated Command Prompt and run:

mkdir "%SystemRoot%\SYSVOL\sysvol\yourdomain.com\Policies\{GUID}"
mkdir "%SystemRoot%\SYSVOL\sysvol\yourdomain.com\Policies\{GUID}\Machine"
mkdir "%SystemRoot%\SYSVOL\sysvol\yourdomain.com\Policies\{GUID}\User"

Replace {GUID} with the actual GUID from step 3. Also replace yourdomain.com with your domain DNS name.

Create a basic GPT.INI file in the policy folder. Use Notepad and save this content as GPT.INI:

[General]
Version=0
displayName=Restored GPO

Run gpupdate /force on the PDCe, then repadmin /syncall /AdeP to force replication across all domain controllers.
Back in GPMC, right-click the GPO and choose Edit. If it opens, you're golden. If not, the policy might have deeper corruption — restore from backup or delete/recreate.

In my experience, this fixes about 80% of 0X0000201C cases. The remaining 20% involve DFSR conflicts or stale NT FRS replication.

Why this error happens

Every Group Policy object in Active Directory has two halves. The first half lives in the CN=Policies container in the directory service (AD). The second half lives in the Sysvol share on every domain controller. When a GPO is created, both halves must be written simultaneously. If the write to Sysvol fails — due to disk space, network interruption, or a DFSR backlog — the AD half persists, but the Sysvol half doesn't. Next time a client or DC tries to read the GPO, it hits the directory service side, finds no matching Sysvol files, and throws ERROR_POLICY_ONLY_IN_DS.

The error code 0X0000201C maps to ERROR_POLICY_ONLY_IN_DS in the winerror.h header. It's a status code, not a crash. The system is telling you: "I found the policy object in AD, but I can't find its files in Sysvol, so I can't apply the policy."

Version 0 in GPT.INI tells the Group Policy engine this is a fresh GPO with no previous settings. If you have a backup of the original GPO, restore the entire Sysvol folder from backup instead of creating a blank one. But if you don't, start fresh and reconfigure the policy.

Less common variations of the same issue

Variation 1: The GPO GUID folder exists in both AD and Sysvol but the Sysvol folder is empty

Same root cause — the write to Sysvol failed after AD write succeeded. Symptom: you see a folder in Sysvol but it has no Machine or User subfolders. Fix: delete the empty Sysvol folder, then recreate it using the steps above. Don't leave an empty folder — it will still trigger the error because GPT.INI is missing.

Variation 2: The GPO is visible in GPMC but you can't edit it — ADSI Edit shows the GUID policy container is empty

This is rarer. The Sysvol folder exists, but the AD policy container (CN=Machine and CN=User) is gone. This usually happens after a failed authoritative restore or a manual ADSI Edit deletion gone wrong. Fix: use ldp.exe or ADSI Edit to manually re-create the CN=Machine and CN=User container objects under the GPO GUID container. Each needs an objectClass of container. Without these, the GPO won't appear in the Group Policy Object list in GPMC — it'll show up only in ADSI Edit. After creating them, run gpupdate /force and repadmin /syncall.

Variation 3: The error appears on a specific client machine but not on the server

Check DFSR replication health. Run dfsrdiag backlog on all DCs. If one DC has a massive backlog, it hasn't received the Sysvol changes. Force replication with repadmin /syncall /AdeP. If the backlog persists, check for event ID 2212 in the DFSR log — that means a journal wrap occurred and DFSR is rebuilding the Sysvol from the PDCe. That process can take hours for large domains. In that case, you have to wait, or if you're in a hurry, use DFSRDIAG POLLAD to kick-start a poll.

Variation 4: The error happens after demoting a domain controller

When you demote a DC, its Sysvol data doesn't get deleted immediately. But if that DC was the PDCe and it held the only copy of a GPO's Sysvol data, demotion orphans that GPO. Fix: seize the PDCe role to another DC, then run the manual folder recreation steps on the new PDCe. This is nasty because you often don't notice until a month later when a client can't apply a critical security policy.

Prevention: Stop this from happening again

Three things you can do today to sleep better:

1. Enable DFSR replication health monitoring

Set up a scheduled task on every DC that runs dfsrdiag backlog and emails you if the backlog exceeds 100 files. I use a simple PowerShell script that sends an email via SMTP. This catches Sysvol replication failures before they become policy orphans.

2. Never delete GPOs from ADSI Edit

Always use GPMC to delete GPOs. Deleting from ADSI Edit leaves orphan Sysvol folders. Deleting from GPMC wipes both halves clean. This error is almost always a direct result of someone using ADSI Edit as a shortcut.

3. Back up your Sysvol regularly

Not just the AD system state — back up the Sysvol share separately. Windows Server Backup can do this if you select the Sysvol folder in the file recovery options. A corrupted GPO without a backup means you have to recreate all its settings from scratch. Trust me, you don't want to reverse-engineer a 200-setting security policy at 2 AM after a server crash.

I've seen this error on Server 2016, 2019, and 2022. It doesn't discriminate. But if you follow the fix above, you'll have it sorted in under 15 minutes. Then go fix the replication monitoring — that's what'll keep it from coming back.