Fix 0xC00002E4 STATUS_DS_GC_REQUIRED on Global Catalog

That error is a kick in the teeth when you're mid-migration and just want Exchange to talk to AD — I get it. The fix is usually faster than you think, so let's go.

The Fix

You're talking to a domain controller that isn't a global catalog. Force the operation onto a GC, or promote the DC you're hitting. Pick the path that matches your situation.

Option 1: Point your app at a real GC

Open AD Sites and Services (dsa.msc), expand Sites > [YourSite] > Servers > [DC] > NTDS Settings, right-click the server and check Properties. If Global Catalog is unchecked, that's your culprit. Check it, apply, then wait for the KCC to update — or force it:

repadmin /kcc
repadmin /syncall /AdeP

If you're running Exchange, verify the GC list with:

Get-ExchangeServer | Format-List Name, *GlobalCatalog*
Get-ADDomainController -Filter {IsGlobalCatalog -eq $true}

Update Exchange to point only at GC-enabled DCs. In Exchange 2016/2019 you set this per-server:

Set-ExchangeServer -Identity EXCH01 -StaticGlobalCatalogs DC01.contoso.com,DC02.contoso.com
Set-ExchangeServer -Identity EXCH01 -StaticDomainControllers $null
Set-ExchangeServer -Identity EXCH01 -StaticConfigDomainController $null

Option 2: Promote the DC to a global catalog

If you actually need this DC to serve as a GC — say it's the only one in a site and Exchange lives there — promote it:

Open Server Manager on the DC.
Tools > Active Directory Sites and Services.
Navigate to Sites > [Site] > Servers > [DC] > NTDS Settings.
Right-click NTDS Settings, choose Properties.
Tick Global Catalog. Click OK.

Or do it from PowerShell on any DC:

Set-ADObject -Identity "CN=NTDS Settings,CN=DC03,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=contoso,DC=com" -Replace @{options=1}

Change options=1 to options=0 to un-GC a DC. Wait for replication — usually 15 minutes in a healthy single-site forest, longer across WAN links. You can confirm with:

repadmin /showobjmeta DC01 "CN=NTDS Settings,CN=DC03,..."

Option 3: Check the application's config

Some apps hardcode a DC. Third-party tools that do LDAP against port 389 will hit a non-GC and fail with 0xC00002E4. Point them at port 3268 (GC LDAP) or 3269 (GC LDAPS) instead of 389/636. Port 389 only answers with data local to that domain; 3268 answers forest-wide. That difference is exactly what triggers this error.

If your app throws 0xC00002E4 on port 389, the shortest fix is often just switching to 3268. No DC changes needed.

Why This Works

Global catalogs hold a partial replica of every naming context in the forest. Universal group memberships, cross-domain object lookups, and Exchange's address book generation all rely on that partial replica. A plain DC only knows its own domain. When a client asks a plain DC for forest-wide data — like resolving a user from a trusted domain or expanding a universal group — the DC replies with STATUS_DS_GC_REQUIRED. That's not a bug, that's AD refusing to answer a question it can't answer. So the fix is either to route the request to a GC or to make the DC one. There's no third option.

Exchange is the loudest offender here. Since Exchange 2013, every mailbox server must talk to a GC. If you accidentally point Exchange at a non-GC DC during maintenance or a site failover, address book sync and OAB generation start failing with this exact code.

Less Common Variations

Error appears during DCPROMO

Promoting a new DC in a child domain and getting 0xC00002E4? The parent DC you're replicating from isn't a GC. Force replication from a GC in the parent domain, or run adprep /domainprep against a GC-enabled DC.

Only one GC in the forest

If your only GC goes down, everything forest-wide breaks. Exchange, Lync/Skype, SharePoint profile sync, and any app using universal groups start throwing 0xC00002E4. Best practice: at least two GCs per forest, and one per site where Exchange or heavy universal-group traffic lives.

Universal group caching masking the issue

If Universal Group Membership Caching (UGMC) is enabled on a site, clients can log in without a GC — until UGMC's cache expires (default 8 hours) and the site has no GC. Then suddenly everything fails with 0xC00002E4. Check the site's UGMC setting in AD Sites and Services. UGMC is a band-aid, not a substitute for a real GC.

Firewall blocking 3268/3269

Your DC is a GC, but the client can't reach port 3268. Confirm with:

Test-NetConnection dc01.contoso.com -Port 3268
ldp.exe

In ldp.exe, connect to port 3268 and run a base search on DC=contoso,DC=com. If that fails but 389 works, the firewall is the problem, not the GC role.

Prevention

Document which DCs are GCs. Run Get-ADDomainController -Filter {IsGlobalCatalog -eq $true} monthly and save the output. When this error hits at 2 a.m., you'll know instantly if a GC went missing.
Never decommission the only GC in a site without promoting a replacement first. DCPROMO will warn you, but people click through.
Monitor forest-wide DC reachability. Check port 3268 as part of your DC health script. If port 389 answers but 3268 doesn't, your GC role changed.
Keep Exchange's static GC list current. Use Set-ExchangeServer -StaticGlobalCatalogs and review it after every DC promotion or demotion.
Don't rely on UGMC for sites with Exchange. Bump up the GC count instead.

One more thing: if the DC's options attribute shows 1 but apps still fail, check whether the DC is paused for replication (repadmin /showrepl). A paused DC can hold the GC role and still not answer correctly until replication catches up.