Fix 0x00002199: Remote cross-ref op failed on domain naming master

1. DNS Resolution Failure — the most common culprit

Had a client last month whose entire AD forest was throwing 0x00002199 every time they tried to add a new domain. Their domain naming master was a 2012 R2 box that suddenly couldn't resolve its own name. Check this first.

The domain naming master needs to register a specific DNS record for crossref operations. If that record is missing or stale, the remote operation fails with this error.

How to check:

1. Run nslookup on the server that's throwing the error — query for the domain naming master's hostname.
2. Run nslookup -type=SRV _ldap._tcp.dc._msdcs.<yourdomain> — make sure the domain naming master appears.
3. Open DNS Manager, expand Forward Lookup Zones, find the _msdcs zone. Verify the _ldap._tcp.dc._msdcs record points to the right server.

If the record is missing or points to a dead DC, force a replication or clean up old records. I've seen stale records from decommissioned DCs cause this exact error — the domain naming master can't find itself.

Fix:

1. Delete the stale record manually.
2. Run ipconfig /registerdns on the domain naming master.
3. Run repadmin /syncall /AdeP to push the change.

If you're using conditional forwarders for child domains, make sure they're correct. A misconfigured forwarder is like a wrong address — the crossref request goes nowhere.

2. RPC Port Blocked — firewall or network ACL issue

The remote crossref operation uses RPC. If a firewall is blocking the dynamic RPC ports (typically 49152–65535 on newer Windows), the operation fails. This is especially common in cloud environments or when you have a DMZ domain controller.

Last year I had a client running 2016 domain naming master behind a strict firewall. The crossref error popped up every time they tried to add a child domain from another site. The fix was adding an RPC port range exception.

Check it:

• On the domain naming master, check the Windows Firewall. Look for inbound rules allowing RPC (TCP 135) and the dynamic RPC ports.
• Test connectivity with Test-NetConnection -ComputerName <domainnamingmaster> -Port 135 from the remote server.
• If that fails, open up the port range.

Fix — open the ports:

netsh advfirewall firewall add rule name="RPC Dynamic Ports" dir=in protocol=tcp localport=49152-65535 action=allow

Or better, restrict it to known RPC port range if your environment is tight. Microsoft says to use 5001–5021 for AD RPC, but in real-world, I've seen 49152–65535 work fine. Just don't open all ports — that's asking for trouble.

3. Domain Naming Master Role Not Reachable — FSMO relocation needed

Sometimes the domain naming master is a zombie. The server is alive, but the role is stuck on a DC that's been offline for weeks. The remote crossref operation tries to contact that DC, fails, and gives you error 0x00002199.

Had a client in 2020 whose DC crashed during a RAID rebuild. The domain naming master was on that dead server. Every new domain addition failed with this error. The fix was to seize the role onto a healthy DC.

Steps to seize the role:

1. Log onto a healthy domain controller.
2. Open Command Prompt as Administrator.
3. Run ntdsutil.
4. At the ntdsutil prompt, type roles.
5. Type connections.
6. Type connect to server <healthy-dc-name>.
7. Type quit.
8. Type seize domain naming master.
9. Confirm the seizure.

After that, run repadmin /syncall /AdeP to make sure replication catches up. The remote crossref operation should work now.

Warning: Seizing an FSMO role is not reversible. Only do this if the original role holder is permanently gone. I've had clients seize roles accidentally and then spend hours trying to clean up metadata.

Quick Reference Summary

If none of these work, check AD replication health with repadmin /replsum. I've seen underlying replication issues — like a tombstoned DC — cause the remote crossref to fail. Good luck.