Fix STATUS_CURRENT_DOMAIN_NOT_ALLOWED 0xC00002E9

You're running netdom renamecomputer on a domain controller, or you kick off the Domain Rename tool (rendom.exe), and it dies partway through with STATUS_CURRENT_DOMAIN_NOT_ALLOWED (0xC00002E9). Same thing happens sometimes when you promote a new DC into a forest that's already mid-rename or has a broken trust. The operation just stops. No partial success message, no helpful hint — just that code.

I've seen this three times in the last two years. Once on a Server 2016 DC after a botched forest prep, once on Server 2019 during a DC rename where the old name was still cached in DNS, and once in a lab where someone had cloned a VM and ended up with two DCs claiming the same NetBIOS name.

What's actually going on

0xC00002E9 isn't really about the name you're trying to set. It's the DC telling you the current domain state won't allow the operation. In plain terms, AD refuses to rename or rejoin because its own house isn't in order — DNS, FSMO roles, trust relationships, or the domain's replication state.

The rename operation runs through SamrSetInformationDomain and related RPC calls. Before it touches the name, it checks a stack of preconditions: the PDC Emulator must be reachable, the domain must be in a healthy replication state, and the target domain name must not already exist in the forest. If any of those fail, you get 0xC00002E9 and nothing else. Annoying, but it's protecting you from a half-renamed forest.

Common misconception: people think the error means the new name is bad. It almost never is. The problem is the state of the current domain, not the target.

The fix — work through it in order

Don't skip steps. I've watched people jump straight to rendom and make things worse.

Verify you're on the PDC Emulator. If you're renaming a DC or running rendom, do it from the PDC Emulator (or at least confirm it's online and reachable). Run:
```
netdom query fsmo
```
If the PDC role holder is offline or unreachable, you'll get 0xC00002E9 nine times out of ten. Seize the role or bring the DC back online first.
Check DNS — both forward and reverse. The new name has to resolve. The old name also has to stop resolving on the wrong records. This is where 90% of these errors actually live. Run:
```
nslookup <newname>.yourdomain.local
nslookup <oldname>.yourdomain.local
ipconfig /registerdns
```
Look for stale A records, duplicate PTRs, or missing SRV records under _msdcs. If the DC's own DNS registration is a mess, the rename can't complete. Flush DNS on the DC and re-register.
Confirm no duplicate computer or NetBIOS names. A cloned VM, a ghosted account in ADUC, or a leftover computer object with the same name will trigger this. In ADUC, look under Domain Controllers and also search the whole domain:
```
dsquery computer -name "<oldname>"
```
Delete or rename anything that collides. Also check the CN=<DCName>,OU=Domain Controllers object for stale attributes like msDS-AdditionalDnsHostName.
Verify the forest functional level and schema. Domain rename requires Windows Server 2003 forest functional level or higher. If you inherited a domain still at 2000 mixed mode, stop — you can't rename it. Check with:
```
Get-ADForest | Select ForestMode
Get-ADDomain | Select DomainMode
```
Raise the levels if needed. Then run adprep /forestprep and adprep /domainprep before trying again.
Make sure no domain rename is already in progress. If someone started rendom and walked away, the forest is sitting in a half-state. Look for these objects in the Configuration partition:
```
CN=Domain Rename,CN=Partitions,CN=Configuration,DC=...
CN=DomainRenameInProgress,CN=Partitions,CN=Configuration,DC=...
```
If those exist, you need to either finish the rename with rendom /end or roll it back with the state file from the original run. Do not start a new rename on top. Use ADSIEdit and be careful.
Check trust relationships. If this DC is also a trust endpoint to another forest or domain, a broken trust can block the operation. Run:
```
netdom trust <trusteddomain> /domain:<yourdomain> /verify
```
Repair or remove broken trusts before renaming.
Replication health. One last check that people skip:
```
repadmin /replsummary
repadmin /showrepl
```
Any DC with lingering replication failures in the domain can cause the rename RPC to fail. Fix replication first.

If it still fails

Grab the actual diagnostic detail — the generic error hides a lot. Check these logs:

Directory Service log in Event Viewer on the DC you're running the operation from. Look for NTDS KCC, NTDS Replication, and LSA errors within the same minute as the failure.
Netlogon.log at %windir%\debug\netlogon.log. It usually tells you which precondition actually failed.
dcdiag /v output — run it and read every FAIL. Don't skim.

If the DC was cloned (common in VMware/Hyper-V environments), check for a CloneDc marker and the msDS-RevealOnDemandGroup attributes. Cloned DCs that weren't properly finalized can't be renamed and will throw this exact code. Either properly complete the clone finalization with ntdsutil or demote and re-promote the DC clean.

Last resort: demote the DC, clean up its metadata with ntdsutil (metadata cleanup), and re-promote with the new name. It's slower but it works when nothing else does. I've had to do this twice. Not fun, but reliable.

One more thing — if you're renaming because of a merger or rebrand, seriously consider whether a rename is worth it. It touches DNS, GPOs, DFS, Exchange, SQL, and every application with a hardcoded domain name. A lot of shops regret starting. But if you have to, work the list above top to bottom and don't jump ahead.