STATUS_SHARED_POLICY 0XC0000299 Fix: Shared Policy Object

What Is STATUS_SHARED_POLICY (0XC0000299)?

This error pops up when you try to modify a Group Policy Object (GPO) that's been shared between domains. The message says “The policy object is shared and can only be modified at the root”—and it's frustrating because it stops you dead. Had a client last month with two domains in a migration, and their IT guy spent half a day clicking through GPMC before calling me. The fix isn't complicated, but you need to understand what's actually happening under the hood.

The core issue: Windows Server marks a GPO as shared when its gpt.ini file contains a gPCMachineExtensionNames or gPCUserExtensionNames attribute that references a cross-domain policy. That attribute locks editing to the domain where the GPO was originally created—the “root” domain. You can't just waltz into another domain's GPMC and tweak it.

Cause 1: Editing a Shared GPO from the Wrong Domain

The Fix: Edit at the Root Domain

This is by far the most common cause. Someone created a GPO in Domain A, then linked it to an OU in Domain B using cross-domain GPO linking. When you try to edit that GPO from Domain B's GPMC, you get 0xC0000299. The fix: open GPMC from the domain that owns the GPO—Domain A. Here's how to find out which domain that is:

1. Open Group Policy Management Console (GPMC).
2. Expand the forest, then the domain where you see the error.
3. Right-click the GPO and choose Edit. If it fails, note the GPO's name.
4. Go to Start → Run, type dsquery * domainroot -filter "(name=GPO_NAME)" -attr distinguishedName. Replace GPO_NAME with the actual GPO name. This shows you which domain the GPO actually lives in.
5. Open GPMC in that domain and edit the GPO there.

Pro tip: If you're in a multi-domain forest, run gpmc.msc /domain:YourRootDomain.com to launch GPMC directly against the root domain. Saves you logging in and out of servers.

Cause 2: GPO Is Unlinked but Still Shared

The Fix: Unshare the GPO via ADSI Edit

Sometimes a GPO gets unlinked from the root domain but the shared attribute sticks around. I've seen this after partial migrations—someone moves a GPO to a different domain using Backup-GPO and Import-GPO, but the original GPO still has the shared flag. You need to clear that flag manually.

Warning: This is advanced stuff. Make a backup first, or you'll break policy application.

1. Open ADSI Edit (install from RSAT if not there).
2. Connect to the domain where the GPO resides.
3. Navigate to CN=Policies,CN=System,DC=YourDomain,DC=com.
4. Find the GPO's GUID folder (match it to what's in GPMC).
5. Right-click the CN=YourGPOName object → Properties.
6. Look for flags attribute. If it's set to 0 (default), the GPO isn't shared. If it's 1, it's shared. Set it to 0.
7. Also check gPCMachineExtensionNames and gPCUserExtensionNames—if they point to a different domain, you'll need to remove those cross-domain references. Do not delete the attributes—just remove the flagged GUID that references another domain.
8. Click OK, then run gpupdate /force on the domain controller.

Real-world scenario: I had a manufacturing client with a GPO that controlled printing settings. The GPO was created in the parent domain, then moved to a child domain during a reorg. The shared flag never got cleared. Every time they tried to edit the printer settings, they hit 0xC0000299. Clearing the flag in ADSI Edit took two minutes.

Cause 3: Corrupted SYSVOL Replication

The Fix: Check DFSR or FRS Replication

This one's rarer but nasty. If your domain controllers use DFS Replication (DFSR) for SYSVOL, a corrupted replication state can cause the shared policy flag to appear incorrectly. The GPO might not actually be shared—it just looks that way because the gpt.ini file is out of sync.

How to diagnose: Compare the gpt.ini file on at least two domain controllers. They should be identical. If they aren't, replication is broken.

• On DC1, go to \\DC1\SYSVOL\YourDomain.com\Policies\{GPO-GUID}\gpt.ini.
• On DC2, go to \\DC2\SYSVOL\YourDomain.com\Policies\{GPO-GUID}\gpt.ini.
• Use fc.exe (file compare) from an admin command prompt: fc \\DC1\SYSVOL\...\gpt.ini \\DC2\SYSVOL\...\gpt.ini.

Fix: Run the DFSR diagnostic tool: dfsrdiag Backlog /RGName:Domain System Volume /SYSVOL /Member:DC1 /Partner:DC2. If there's a backlog, force replication with repadmin /syncall /AdeP. If that doesn't work, you may need to do a non-authoritative restore of SYSVOL.

Quick fix: For FRS (old systems like Windows Server 2008 R2), you can run net stop ntfrs, delete the %SystemRoot%\ntfrs\jet folder, then run net start ntfrs. This rebuilds the FRS database. Only do this if you're sure FRS is the culprit—DFSR systems will just get more confused.

Quick-Reference Summary

Bottom line: 90% of the time, this error is just you editing from the wrong domain. The other 10% is either a stuck flag or broken replication. Don't overthink it—start with the domain check, and you'll be back to fixing real problems in minutes.