Fix ERROR_DS_GCVERIFY_ERROR 0x000020E1 – GC verification

The Global Catalog verification check failed during domain controller promotion or replication. This happens when the GC can't reach another DC or when DNS records are stale.

Quick answer for advanced users: Run repadmin /syncall to check replication status, verify DNS records for the GC SRV entry under _gc._tcp, and force a net stop netlogon && net start netlogon on the source GC. If that doesn't work, manually delete the stale GC record from DNS.

What's really going on with error 0x000020E1?

This error pops up most often when you're trying to promote a new domain controller (DC) and the installer can't verify that an existing Global Catalog server is reachable. The process sends an LDAP ping to a GC, and if that GC doesn't respond—or responds but with incorrect data—you get this error.

I've seen this on Windows Server 2016 and 2019 builds, usually right after the “Verifying that the remote Global Catalog is available” line in DCPromo hangs for 45 seconds then fails. The root cause is almost always DNS: either the GC's A record points to a retired IP, or the SRV record under _gc._tcp.<yourdomain> is missing or stale.

Sometimes it's just a transient network blip. But in production, you can't afford to retry and hope. Here's the exact order I'd walk you through.

Primary fix: Clean up DNS and refresh GC advertisement

Open DNS Manager on an existing DC (ideally the one holding the GC role). Right-click the server and pick View → Advanced so you can see all record types.
Expand _tcp folder under your domain zone. You'll see a subfolder named _gc. Click it. You should see one or more SRV records like _gc._tcp.yourdomain.local pointing to GC servers by hostname.
Check each SRV record against the actual GC's IP. If the hostname in the record doesn't exist or the IP has changed, delete that SRV record. Right-click it, choose Delete, confirm.
Force the GC to re-register its SRV records. On the server that *should* be a GC, open an admin Command Prompt and type:
net stop netlogon && net start netlogon
After it restarts, wait 15 seconds. The Netlogon service rewrites DNS records automatically.
Verify the new SRV record appears. Back in DNS Manager, right-click the _gc folder and choose Refresh. You should see the correct entry now. If not, manually add an SRV record:
Service: _gc Protocol: _tcp Port: 3268 Host: your-gc-server.domain.local
Test GC reachability from the server where you're seeing the error. Run:
nslookup -type=srv _gc._tcp.yourdomain.local
It should return at least one IP. Then confirm that port 3268 (GC port) is open:
Test-NetConnection your-gc-server -Port 3268 (or telnet your-gc-server 3268 on older systems). If it says TcpTestSucceeded : True, you're good.
Retry the promotion or whatever action triggered the error. It should pass now. If it still fails, move to the alternative fixes.

Alternative fixes if the main one didn't work

Fix 1: Force replication before promotion

Sometimes the error is a red herring for deeper replication latency. On the target server, run this to force inbound replication from all partners:

repadmin /syncall /AdeP

Wait for it to finish (could take minutes in a large domain). Then check event logs for any 1925 or 1988 errors. Address those first.

Fix 2: Temporarily promote without GC verification

If you absolutely need to get this DC promoted and the GC is actually fine (verified by port 3268 being open), you can bypass the GC check using an unattended install file. But I don't recommend this as a first choice—it can lead to orphaned metadata if something else is broken. Here's the risk: you skip the check, promotion succeeds, but the new DC can't sync because the source GC has bad data. You've just doubled your problems.

If you're determined, create a text file called promote.txt with this content (adjust for your environment):

[DCInstall]
InstallDNS=Yes
ConfirmGc=No
ReplicaDomainDNSName=yourdomain.local
ReplicaOrNewDomain=Replica
SafeModeAdminPassword=YourSafePass123
AutoConfigDNS=Yes

Then run dcpromo /answer:promote.txt from an elevated prompt. Again—last resort only.

Fix 3: Remove and re-add the GC role on the source server

If the GC server itself is misconfigured—maybe someone unchecked the box then re-checked it—the advertisement gets stuck. Go to Server Manager → AD DS → right-click the server → Add Roles and Features and ensure the Global Catalog checkbox is checked under AD DS services. If it already is, uncheck it, click OK, let the server replicate (wait 30 minutes), then re-check it. This triggers a full re-registration of GC records.

Prevention tip: Keep your DNS clean

The single most common cause of this error is stale DNS. Set up scavenging on your DNS zones. In DNS Manager, right-click your forward lookup zone → Properties → General → Dynamic updates set to Secure only. Then on the server properties under Advanced, enable scavenging and set a no-refresh interval of 7 days and a refresh interval of 7 days. This automatically purges old records when a server is decommissioned or its IP changes.

Also, every time you demote a DC, run repadmin /options +DISABLE_NTDSCONN_XLATE and then manually delete its DNS records from the _msdcs forest zone. Don't rely on demotion alone to clean up—I've seen it miss SRV records in _gc more times than I can count.

If you follow that, you'll almost never see 0x000020E1 again.