ERROR_DS_MACHINE_ACCOUNT_CREATED_PRENT4 Fix (0X0000217C)

This error hits when you try to rejoin a computer to an AD domain and the existing machine account predates Windows NT 4. Reset or delete the stale account, then rejoin.

You're re-imaging a workstation, you punch in the domain creds, and Windows spits back ERROR_DS_MACHINE_ACCOUNT_CREATED_PRENT4 (0X0000217C): "The machine account was created pre-Windows NT 4." This shows up when a computer account already exists in AD with a legacy pre-Windows 2000 name (SAM name) that doesn't match what modern Windows expects during a join or rejoin.

The classic trigger: someone renamed the computer in ADUC (or a script did), the sAMAccountName got mangled, or the object was restored from an ancient backup. Now your Windows 10 or 11 box can't create its secure channel because the account it's trying to use has an NT 4-era naming quirk.

What's actually going on

Every computer in AD has two name fields: cn (the display name, usually ends with $) and sAMAccountName (the legacy logon name). Pre-Windows 2000 accounts can have sAMAccountName values longer than 20 characters, missing the trailing $, or containing characters modern Windows won't accept.

When you rejoin, the workstation tries to negotiate a secure channel using its current hostname. If AD finds an object with a mismatched or malformed sAMAccountName, the DC refuses the operation with 0X0000217C. It's a safety check, not a corruption. The object is basically saying "I was born in a different era."

I've seen this most often on machines that were renamed multiple times, or on accounts that got synced from an old NT 4 backup during a domain migration years ago and nobody cleaned up.

The fix

Pick one approach. Reset is faster but sometimes fails on truly broken objects — then you delete and let the join recreate the account.

Option A: Reset the machine account password (try this first)

On the workstation, log in with a local admin account (not the domain account, since the trust is broken).
Open an elevated Command Prompt.

Run the netdom reset against your DC. Replace names as needed:

netdom reset "WORKSTATION01" /Domain:contoso.com /UserD:contoso\admin /PasswordD:*

You should see "The command completed successfully." Reboot and try the join again.

If netdom isn't installed, grab it from RSAT or run it from a DC. The /PasswordD:* flag prompts for the password so it doesn't sit in your command history in plaintext.

Option B: Fix the sAMAccountName directly

On a DC or a machine with RSAT, open an elevated PowerShell.

Check the current sAMAccountName:

Get-ADComputer WORKSTATION01 -Properties sAMAccountName | Select Name, sAMAccountName, DistinguishedName

If it's missing the trailing $ or it's longer than 15 chars, fix it. The clean form is the hostname plus $, max 15 chars total:
```
Set-ADComputer WORKSTATION01 -SamAccountName "WORKSTATION01$"
```

Reset the password too:

Reset-ComputerMachinePassword -Server dc01.contoso.com -Credential (Get-Credential)

Reboot the workstation and rejoin.

Option C: Delete and recreate

If A and B both fail, the object is too far gone. Kill it.

On the workstation, disjoin from the domain (or just switch to a workgroup).
In ADUC, find the computer object. Right-click, Delete.
Wait for replication. If you have multiple sites, give it 15 minutes or force it:
```
repadmin /syncall /AdeP
```
Reboot the workstation, then rejoin. AD will create a fresh computer account with a proper sAMAccountName.

Don't skip the replication wait. I've watched techs delete the object on DC1, immediately try to rejoin against DC2, and get the same error again because DC2 hadn't heard the news yet.

If it still fails

Check DNS. The workstation must resolve your DC's SRV records. Run nslookup -type=SRV _ldap._tcp.dc._msdcs.contoso.com. If that returns nothing, the join will fail for unrelated reasons and you'll chase the wrong error.
Confirm the workstation's hostname. If it's longer than 15 characters, AD will truncate the sAMAccountName and you can land back in this same error loop. Rename the box.
Look for duplicate objects. Use ntdsutil to check for metadata from old DCs. Duplicate SPNs on two computer objects will cause chaos:
```
setspn -L WORKSTATION01
```
Verify time sync. Kerberos is unforgiving. If the workstation clock is off by more than 5 minutes from the DC, the secure channel will fail with a misleading error. w32tm /resync from an elevated prompt.
Check the domain functional level. If you're still at Windows Server 2003 FFL, some legacy behavior persists. Not likely to be your problem in 2024, but I've seen it on forgotten lab domains.

The real fix is almost always Option C. The reset buys you time, but if an object has been sitting in AD since the Clinton administration with a mangled name, deleting it takes 30 seconds and saves you a headache. Just make sure replication completes before the rejoin.