What's Actually Happening
The 0X00002019 error means your application or domain-joined server tried to reach a Global Catalog (GC) server and couldn't. The GC is a special domain controller that holds a partial replica of every object in the forest. It's the first stop for any LDAP query that crosses domain boundaries or needs a universal group membership. If you're seeing this, either no DC has the GC flag set, or the client can't find one via DNS.
This error commonly pops up when you run an LDAP query from a member server against a domain that's not its own, or when you've demoted a GC without promoting a replacement. I've also seen it after a network team accidentally changed the DC's IP without updating DNS.
Fix 1: The 30-Second Check – Verify DNS SRV Records
Most of the time, this error is DNS. The client looks up _gc._tcp.<forestDN> SRV records to find a GC. If those records are missing or stale, you get 0X00002019.
On the machine showing the error, run:
nslookup -type=srv _gc._tcp.yourforest.com
Replace yourforest.com with your actual forest DNS name. You should see at least one entry with a hostname and port 3268. If you get a non-existent domain or no answers, that's your problem.
If you're on a DC, use the more reliable test:
repadmin /kcc
Then force a DNS update with:
ipconfig /registerdns
net stop netlogon && net start netlogon
The Netlogon service registers the SRV records. Restarting it forces a re-registration. Wait 15 minutes for propagation if you have multiple DNS servers.
Fix 2: The 5-Minute Fix – Check and Restart the NTDS Service
If DNS looks fine, the GC might be running but not healthy. On each domain controller, open Services.msc and look for NTDS (Active Directory Domain Services). Its status should be "Running" and its Startup Type "Automatic". If it's stopped or hung, restart it with:
net stop ntds && net start ntds
But before you do that, check the event logs. Open Event Viewer, go to Windows Logs > Directory Service. Look for events 1126 or 1988 – those indicate replication issues that can prevent a GC from being advertised.
Also verify the GC is actually a GC. On each DC, run:
repadmin /showattr . nc:\ /subtree /filter:"(objectCategory=nTDSDSA)" /attrs:options
Look for the value IS_GC in the options attribute. If you don't see it for any DC, then no GC exists – that's the root cause.
Fix 3: The 15-Minute Fix – Reconfigure AD Sites and Services
If DNS is fine and services are running, the issue is likely site topology. The client is probably in a site that has no GC, and the nearest GC is too far away (or a site link is broken). Open Active Directory Sites and Services.
First, check which site the client is in. On the client, run:
nltest /dsgetsite
If that returns an error, the client can't determine its site – that's a big clue. The site definition depends on the subnet-to-site mapping in AD Sites and Services.
Now on a DC, expand the client's site, then expand Servers, then each server, and right-click NTDS Settings > Properties. Check the Global Catalog checkbox. If it's unchecked, check it, click OK, wait for replication, and force it with:
repadmin /syncall /AdeP
Then verify the GC is reachable from the client with:
ldp.exe
In ldp, connect to your GC hostname on port 3268. If you can bind and browse the partial attributes, you're done.
When to Skip Straight to the Advanced Fix
If you're in a multi-domain forest and this error appeared after you decommissioned a DC, jump to the site config first. A fresh forest usually has its first DC as a GC automatically, but when you add a second domain, that DC is not a GC by default. I've seen admins forget that and then wonder why cross-domain queries fail.
Still Stuck? Check Replication Health
If none of that worked, run dcdiag /test:replications /v. If you see failures, fix replication first. A GC that's behind on replication will still answer queries, but it will return stale data – that's a different error though. The 0X00002019 specifically means no GC at all was found.
One last thing – check your firewall. If you have a distributed setup, port 3268 needs to be open between the client and the GC. Try a simple TCP connection test:
Test-NetConnection gc-server -Port 3268
If that fails, it's a network problem, not AD. Fix the firewall rules, and the error will disappear.