Fix ERROR_DS_GC_REQUIRED (0x00002163) Global Catalog

You're staring at ERROR_DS_GC_REQUIRED (0x00002163) and cursing the fact that your perfectly valid AD query just bounced. I've been there — it's frustrating because the error message is cryptic and doesn't tell you what to actually do.

The fix: Make a Global Catalog server available

The immediate solution is straightforward: either point your operation to a domain controller that already has the Global Catalog role, or enable the GC role on an existing DC. Here's the quickest path:

Check which DCs are GCs — Run this from an elevated PowerShell prompt on any DC:
```
Get-ADDomainController -Filter {IsGlobalCatalog -eq $true} | Select-Object Name, Site
```
This lists all GC-capable DCs in your forest. If you get zero results, that's your problem.
Enable GC on a DC — Open Active Directory Sites and Services, expand your site, click on Servers, find a domain controller (preferably one running DNS and close to your clients), right-click NTDS Settings, pick Properties, and check Global Catalog. Apply and wait — it takes 5-15 minutes for replication to spread.
Force replication — If you're impatient (like me), force AD replication with:
```
repadmin /syncall /AeD
```
Then verify with the Get-ADDomainController command again.
Restart your operation — Whether it's an LDAP query, a domain join, or an ADUC snap-in, retry against the now-GC-enabled DC.

If you can't change the GC role (say it's a read-only DC or you lack permissions), work around it by targeting a specific GC server in your code or tool:

For LDAP queries — Change your bind string to port 3268 (the GC port) on a known GC server: LDAP://GC-server-name.domain.com:3268
For dsquery — Use -gc flag: dsquery * -gc -limit 0
For PowerShell — Specify -Server (Get-ADDomainController -Discover -Service 6).HostName to auto-find a GC

Why this error happens (the real cause)

What's actually happening here is that Active Directory operations that need to see objects from multiple domains — like universal group membership lookups, object searches across the forest, or domain join operations — require a Global Catalog server. The GC holds a partial read-only copy of every object in every domain in the forest, which lets it answer cross-domain queries without contacting every domain controller individually.

The error code 0x00002163 translates to "The requested operation can be performed only on a GC server". The DC you hit doesn't have the GC role. The fix isn't about fixing the DC — it's about ensuring a GC exists and your tool uses it.

The reason step 3 (force replication) works is that enabling the GC flag on NTDS Settings triggers a replication of the partial attribute set from an existing GC. Without replication completing, the DC still can't serve as a GC — the flag is just metadata until the data arrives.

Less common variations of this issue

Sometimes the error shows up in unexpected places. Here are the edge cases I've seen:

Scenario	Symptom	Fix
Application using port 389 instead of 3268	Error on LDAP bind for cross-domain search	Change app config to use port 3268 on the same DC
Read-Only Domain Controller (RODC)	Can't enable GC on RODC (it's not supported)	Add a writable GC in the same site, or point clients to a writable GC
Site link failure after adding a new domain	GC replication never completes because of site topology	Check site links and bridgehead servers, then force sync
Domain join fails with 0x00002163	Client can't find a GC during join process	Ensure at least one GC per site or enable auto-discovery with `nltest /dsgetdc:domain /GC`

One weird case: I had a customer where a third-party backup agent kept throwing this error during restore operations. The agent was hardcoded to query a specific DC that wasn't a GC. The fix was adding a registry override in the agent to target port 3268 on the same server — no DC changes needed.

Prevention: Don't let this bite you again

The best prevention is planning your GC placement:

At least one GC per site — If you have multiple physical sites, each should have a local GC. Without one, cross-site authentication and searches will fail or be painfully slow. Use AD Sites and Services to assign the GC role to a DC in each site.
Monitor GC availability — Set up alerts for the NTDS performance counter DRA Replication Inbound and monitor GC-specific events like 1925 (replication failure) and 1126 (GC promotion failure). Tools like repadmin /showrepl can show pending GC changes.
Don't rely on auto-discovery alone — Some applications cache DC discovery results. If the cached DC loses its GC role or goes offline, they'll hit this error. In your code, always include a fallback that explicitly queries for a GC using DsGetDcName with the DS_GC_SERVER_REQUIRED flag.
Document your GC servers — Keep a simple text file or wiki page listing which DCs are GCs. When you decommission a DC, check if it was a GC and promote another one first.

One more thing: if you're running a single-domain forest with only one DC, that DC must be a GC. The default installation of Active Directory on the first DC in a forest automatically makes it a GC — but if someone unchecked that box during promotion (yes, it's possible), you'll see this error. Rechecking the GC box in NTDS Settings fixes it immediately.