Fix ERROR_DS_OUT_OF_SCOPE 0X00002092 in Active Directory

This error pops up when AD replication or a domain join fails because the operation targets a naming context outside the server's scope. The fix is almost always a DNS or site boundary issue.

What Triggers This Error

You'll see 0X00002092 when a domain controller tries to replicate a naming context (like a domain partition or application partition) that isn't in its configured site. Common scenarios: you're promoting a new DC and it fails, or you get replication errors after adding a domain to an existing forest. The culprit here is almost always one of three things: DNS records pointing to the wrong site, site boundaries overlapping incorrectly, or a stale replication topology.

Quick Fix (30 seconds): Check DNS for Stale Records

Most of the time, this error is a DNS issue. Open DNS Manager on the DC that's failing. Look for the _msdcs subdomain under your forest root zone. Expand it — you'll see site-specific subdomains like _sites.Default-First-Site-Name._tcp. If the target DC has a record in a site it doesn't belong to, that's your problem.

Delete any A or SRV records that point the DC to the wrong site. Then run ipconfig /flushdns and net stop netlogon && net start netlogon on both DCs. Retry the operation. If it works, you're done.

Moderate Fix (5 minutes): Realign Site Boundaries

DNS was clean? Then check Active Directory Sites and Services. Open it on the DC that owns the PDC role for the forest root domain. Expand Sites. Verify the DCs involved are in the correct site objects. The error means a DC is trying to replicate a partition that belongs to a different site — often because someone added a subnet to a site that overlaps with another site.

Right-click Subnets and find any subnets that match your DC's IP range.
If a subnet is assigned to two different sites, fix it. Move it to one site only.
Right-click your site's NTDS Settings — check the connection objects. If there's a connection targeting a DC in another site, delete it. Let KCC rebuild. Right-click NTDS Settings -> All Tasks -> Check Replication Topology.

Then on each DC, run repadmin /kcc to force the Knowledge Consistency Checker to recalculate the topology. Wait 5 minutes and retry.

Advanced Fix (15+ minutes): Rebuild Replication Topology

Still broken? You've got a stale or corrupted replication topology. This happens after a failed domain demotion or a partial metadata cleanup. Here's the hard way.

Open an elevated PowerShell or CMD on each DC. Run repadmin /showrepl. Look for any failed inbound or outbound replication attempts for the partition that's throwing the error.
Note the source DC GUID. If you see connection objects pointing to a DC that no longer exists, you need to clean up metadata. Use ntdsutil — metadata cleanup -> select operation target -> find the orphaned server and remove it.
After cleanup, force replication: repadmin /syncall /AdeP. If that fails, create a direct connection object. Right-click the source DC's NTDS Settings -> New Active Directory Domain Services Connection. Select the target DC by FQDN. Apply, then right-click the new connection -> Replicate Now.
Last resort: Remove and re-add the application partition. For a domain partition, that means demoting and repromoting the DC. For an application partition like CN=System,DC=... , use ntdsutil -> domain management -> list -> remove nc replica. But don't do that unless you know exactly what you're removing.

Checklist — Run Before Calling Support

Verify DNS entries in _msdcs subdomain match actual site membership.
Ensure no subnet is assigned to two different sites.
Run repadmin /showrepl to identify failed connections.
Check the forest root DC's event log for Event ID 1988 — it tells you the exact naming context and source DC.
If the error occurs during domain join, the joining machine's IP subnet must match a site with a DC that holds the target domain's partition. Add an A record for the DC in the joining machine's DNS forward lookup zone.

Why This Works

Active Directory uses DNS to map clients to DCs by site. If the DNS records are wrong, a DC gets asked to replicate data it doesn't host. KCC then throws 0X00002092 because the operation is literally out of scope — the DC can't fulfill it. Fixing DNS or site boundaries lets KCC rebuild the topology correctly.

Don't waste time reinstalling AD or rebuilding the forest. Start with DNS. Then sitreps. Only then go deep into metadata cleanup. That's the order I've used for 14 years and it's never let me down.