Fix STATUS_POLICY_ONLY_IN_DS (0xC000029B) in Windows

This error pops up when a policy setting only exists in the directory service, not locally. You'll fix it by checking group policy, verifying domain controller sync, or repairing the registry.

What's actually happening here

0xC000029B (STATUS_POLICY_ONLY_IN_DS) is Windows telling you that a requested policy setting exists only in the directory service (Active Directory or local security database), not in the local policy store. Think of it as a mismatch — the system expects to find a policy value locally, but the only copy lives in the DS. This usually surfaces when you're running gpupdate, opening Local Security Policy, or during a domain join.

I've seen this most often on Windows 10/11 Pro or Server 2016+ machines that were recently removed from a domain, or when a GPO references a setting that's been removed from the Central Store. It's not a crash — it's a lookup failure inside the policy engine.

Fix 1: The 30-second check — refresh policy locally

Before you touch anything else, run this in an elevated command prompt:

gpupdate /force

Wait 30 seconds. What this does is force a full policy re-evaluation. If the DS copy is reachable (you're still on the domain, or the local security database is intact), the policy gets re-written to the local registry and the error clears. The reason this works sometimes: the local policy cache went stale after a reboot or a network hiccup, and forcing a refresh rebuilds it.

If the error message appeared during a specific app install or a manual registry edit, skip this — it won't help.

Fix 2: The 5-minute fix — check group policy and domain sync

Still stuck? Verify the policy actually exists in the DS and is being applied.

Open rsop.msc (Resultant Set of Policy) and look for the policy that's failing. If it's missing or shows an error, that's your clue.
On a domain-joined machine, confirm the domain controller with the PDC emulator role is reachable:

nltest /dsgetdc:yourdomain.local

If that fails, your DC is unreachable or the DS is out of sync. Run repadmin /replsummary on the DC to check replication. Unsynced SYSVOL or a lingering tombstone can cause the policy to exist only on one DC, and your machine is pulling from the wrong one.

For workgroup machines (no domain), the “DS” is actually the local Security Accounts Manager (SAM). In that case, the problem is usually a corrupted secedit.sdb database. Rebuild it:

secedit /configure /cfg %windir%\inf\defltbase.inf /db defltbase.sdb /areas SECURITYPOLICY

This restores the default security policy database and wipes any half-written entries. Back up the existing .sdb first if you care about custom settings.

Fix 3: The 15+ minute advanced fix — registry cleanup and component store repair

If the above didn't bite, the policy is likely stuck in the registry and the DS doesn't have a matching entry. Here's the surgical approach.

Step 1: Identify the offending policy

Check the event log (Event Viewer → Windows Logs → System or Application) for the event ID that accompanies the error. It usually includes the policy path, like \Machine\Software\Policies\...\SomeSetting. Write that path down.

Step 2: Back up and delete the registry key

Open regedit and navigate to that key. Right-click → Export to save a .reg file, then delete the key. This forces the system to re-read the policy from the DS on next refresh — if the DS is healthy, it'll recreate the key with the correct value.

Be careful here: deleting a policy key that's still being enforced can cause that specific policy to revert to default. Only do this if the error is blocking a specific action (like opening Local Security Policy).

Step 3: Run DISM and SFC

Corrupted system files can break the policy engine's ability to read the DS. Run these in order, in an elevated prompt:

DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

What's actually happening: DISM fixes the component store, then SFC uses that repaired store to fix protected system files. If either reports errors that it can't fix, you're looking at a deeper issue — possibly a bad Windows update. In that case, uninstall the latest cumulative update (Settings → Windows Update → Update history → Uninstall updates) and retry.

When to skip all this

If this error appears only in a third-party app's log (like a VPN client or backup tool) and your system runs fine, ignore it. Those tools sometimes misinterpret policy lookups. The error code is a status value, not a crash — many apps log it and move on.

One last opinion

The root cause in most real-world cases I've debugged is a domain controller that lost SYSVOL replication, or a machine that was removed from the domain but left with partial policy entries in the registry. If you're on a workgroup and you've done Fix 2's secedit rebuild, that covers 90% of standalone cases. For domain machines, spend your time on replication health, not registry spelunking.

If none of this works, you're likely dealing with a hardware-independent policy corruption that needs a Windows repair install — but that's a last resort, and I'd only go there after a clean boot confirms the issue isn't a third-party service.