0x00000FA6: Replication Not Allowed With Nonconfigured Partner

Quick Answer

Run repadmin /options <DC_name> +DISABLE_INBOUND_REPL on the rogue DC, then demote it properly with dcpromo /forceremoval if needed.

Why You're Seeing This

This error pops up when a domain controller tries to replicate with another DC that doesn't have it listed as an allowed replication partner. I've seen this most often after someone forces a promotion of a DC using an old backup, or when a server is reactivated after being offline for months. The replication engine checks its allowed partner list — if your server isn't on it, you get this error. It's a safety measure to prevent data corruption, but it can be a real headache.

The trigger is almost always an orphaned DC. Had a client last month whose entire print queue died because a junior admin restored a DC from snapshot without demoting the original first. The old DC came back online, tried to replicate, and both servers started spewing 0x00000FA6 errors. The real fix is to clean up the metadata or demote the problem server.

Fix Steps: The Standard Method

1. Identify the problematic DC. Open Event Viewer on both DCs involved. Look for event ID 1925 or 1926 under Directory Service. The source and destination will tell you who's the unconfigured partner.
2. Check replication topology. Run repadmin /showrepl on each DC. Note the failure direction. Usually it's inbound from the rogue DC to an existing one.
3. Disable inbound replication on the rogue DC. Run this as admin:

   repadmin /options <rogue_DC_name> +DISABLE_INBOUND_REPL

   This stops the bad replication attempts.
4. Verify the error stops. Check event logs again. If the error disappears from both sides, you've isolated the problem.
5. Demote the rogue DC. If the server is still functional but shouldn't be a DC, run dcpromo /forceremoval on it. This strips AD. After reboot, clean up metadata with ntdsutil — go to Metadata cleanup and remove the server manually.
6. Re-enable replication on other DCs. If you disabled inbound repl on any healthy DC during troubleshooting, re-enable it:

   repadmin /options <DC_name> -DISABLE_INBOUND_REPL

Alternative Fix: If the Rogue DC Is Already Gone

Sometimes the server that caused the error has already been decommissioned or crashed. You still get the error because its metadata lingers. Here's what works:

• Force metadata cleanup from a healthy DC. Open ntdsutil, select Metadata cleanup, connect to the healthy DC, and remove the dead server from all naming contexts. This is your best bet if you can't boot the rogue box.
• Use repadmin to force removal. Run repadmin /removeholdingdeletedserver <dead_DC> <healthy_DC> — this nukes the leftover references.
• Check DNS. If the dead DC's records linger in DNS, replication can still try to reach it. Delete stale A and CNAME records under _msdcs domain zone.

Prevention Tip

Never restore a DC from backup or snapshot without first demoting it cleanly. Always use dcpromo to remove the old DC before bringing a restored version online. Also set up monitoring on replication failures — I use a simple PowerShell script that checks repadmin /showrepl daily and emails me if any failures appear. Catches orphaned DCs before they cause chaos.