Fix ERROR_DS_NOT_CLOSEST 0x0000218C — GC Site Affinity

Quick answer

Delete the stale DNS SRV record for the wrong site, then verify site link costs make the correct GC reachable at lower cost.

Why this happens

You're seeing ERROR_DS_NOT_CLOSEST (0x0000218C) when a domain member tries to find a Global Catalog server. What's actually happening here is that Windows clients use DNS to locate a GC in their own site first — they look up _gc._tcp.<SiteName>._sites.dc._msdcs.<Domain>. If that record points to a GC that isn't physically in that site, or if the site link cost to the nearest GC is higher than the cost to a farther GC, the client falls back to a GC from a different site. The error fires because the GC the client ended up with isn't the closest one according to AD site topology.

The trigger is almost always a DNS record that was registered manually or left behind after a domain controller was moved to a different site. I've also seen this when someone created a new site but forgot to update site link costs — the new site's GC has a higher cost than a GC in a neighboring site, so the client picks the neighbor.

Fix steps

Identify the offending GC. On the client that logged the error, run nltest /dsgetsite to see the site it thinks it's in. Then run nltest /dsgetdc:<Domain> /gc — the returned server is the one causing the error.
Check DNS SRV records for that server's site. Open DNS Manager, drill into _msdcs.<Domain> → _sites → <YourSite> → _tcp. Look for _gc records. If the IP or hostname in the record doesn't match a GC that's actually in that site, delete that record. DNS scavenging might not clean these up if they were registered with a non-standard TTL.
Verify site link costs. Open Active Directory Sites and Services. Find the site link connecting your client's site to the site where the GC lives. Right-click → Properties. The Cost value must be lower than any alternate path to another GC. If the link cost is, say, 200 and there's another link to a different site with cost 100, your clients will prefer the cheaper link even if the GC in the site is closer geographically. Set the cost so the correct GC's site has the lowest cost from the client's site.
Force a re-check. On the client, run ipconfig /flushdns then nltest /dsgetdc:<Domain> /gc again. If it still picks the wrong GC, go back to step 2 — the DNS record probably isn't fully deleted or there's a cached negative response.

Alternative fixes if the main one fails

Disable site coverage on the GC. Some admins set the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SiteCoverage registry value on a GC to advertise itself in multiple sites. If you find that key on the GC, delete the site you don't want it covering. Restart the Netlogon service on the GC afterward.
Check for subnet mismatches. If your client's IP falls into a subnet that's assigned to the wrong site in AD Sites and Services, it will think it belongs there. Run nltest /dsgetsite to confirm the site name. If it's wrong, fix the subnet-to-site mapping. This is more common than you'd think — people merge subnets or renumber and forget to update AD.
Temporarily override with registry. On the client, set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\SiteName to the correct site name. This forces the client to a specific site regardless of subnet. Use this only as a short-term workaround — it breaks roaming and is a pain to maintain.

Prevention tip

Enable DNS scavenging on all zones that contain _msdcs records. Set the scavenging period to 7 days and the no-refresh interval to 3 days. Stale SRV records are the #1 cause of this error in production. Also, whenever you move a DC between sites, run repadmin /unregister on the old server's DNS records, or just delete the old site's _gc record manually. Don't rely on scavenging to clean up immediately — it can take up to the scavenging period to run.