Active Directory Operations and recovery
Domain join, account reuse and offline provisioning
Find the failed join stage, check account-reuse restrictions, and understand what offline provisioning changes on each side.
Domain join is a sequence, not one LDAP write
A domain join has to discover a DC, authenticate, create or reuse a computer account, establish its password and configure local membership. The generic error at the end can hide a much more useful failure earlier in the log.
Read the failed attempt before deleting the account or trying again with a more privileged identity. On the joining computer:
Get-Content -LiteralPath (Join-Path $env:windir 'debug\NetSetup.log') -Tail 200
The log is enabled by default. Retain the whole relevant attempt, its timestamp, selected DC, return codes and the client build/update level. Compare with Microsoft’s successful join log and network analysis; do not search only the final error line.
| Failure stage | Discriminating evidence |
|---|---|
| Discover a suitable DC | Client resolver configuration, SRV responses, locator result, selected DC and site |
| Contact and authenticate | Actual protocol exchange and status; successful TCP connection alone is insufficient |
| Create a new computer object | Destination container, create permission or applicable quota path, RID allocation |
| Reuse an existing computer object | Exact object identity, owner, delegated write/reset rights and current reuse policy |
| Configure local membership | Local join result, pending restart and intended Windows installation |
| First operational use | Machine authentication, DNS registration, Group Policy and required application access |
DNS/DC Locator and RPC endpoint diagnosis help with the early stages. If object creation fails because identifiers cannot be allocated, investigate RID state; a network-shaped message is not sufficient reason to restart the DC.
Identify whether the account is new or reused
From an authorized directory workstation, query the DC named in the join log:
$dc = 'dc1.contoso.com'
$computer = Get-ADComputer -Identity 'APP01' -Server $dc `
-Properties whenCreated,PasswordLastSet,msDS-CreatorSID `
-ErrorAction Stop
$computer | Select-Object ObjectGUID,SID,DistinguishedName,whenCreated,
PasswordLastSet,msDS-CreatorSID
$security = Get-ADObject -Server $dc -Identity $computer.ObjectGUID `
-Properties nTSecurityDescriptor -ErrorAction Stop
$security.nTSecurityDescriptor.Owner
Keep any not-found error too. If the account was recently prestaged, compare another intended replica in case the change hasn’t converged. The current owner, creator and identity attempting the join can all be different. msDS-CreatorSID isn’t a universal owner field and isn’t populated for every creation path.
An object with the right name could be a prestaged account, a previous installation of this device, another active device or a newly recreated identity. Check its GUID, SID, memberships, permissions and service dependencies before deleting it. Successful reuse may be meant to preserve exactly that information.
Creation rights do not settle reuse
Creating a new account uses the permissions on its destination OU/container or the applicable workstation-join right/quota path. Updating an existing account requires appropriate permissions on that object. A build identity that can create objects in an OU is not automatically authorized to reset and reuse every computer already there.
Review the intended delegation against Microsoft’s domain join permissions. The directory ACL and the account-reuse hardening check are separate conditions. Broad group membership or raising ms-DS-MachineAccountQuota is not a diagnosis of which condition failed.
Read reuse failures in their servicing context
0xAAC / NERR_AccountReuseBlockedByPolicy identifies a deliberate reuse restriction. Examine the owner of the existing account and the effective Domain controller: Allow computer account re-use during domain join policy. The policy’s trusted owners/creators are not simply a list of everyone permitted to click Join.
KB5020276 describes the servicing phases and supported policy. Updates from August 2024 removed support for the old NetJoinLegacyAccountReuse registry workaround. An old registry value cannot establish current exemption behavior. Inspect both client and DC updates and effective policy rather than reproducing an earlier bypass.
The hardened flow also performs authenticated SAMRPC checks. Delegated LDAP rights won’t help if a remote-SAM restriction blocks that exchange. Microsoft’s existing-account failure example shows where to look in the log. Work through the policy, ownership or delegation failure with the account’s owner. Deleting the account can affect an active machine and makes the original failure harder to investigate.
Offline join separates provisioning from applying the state
Offline domain join has two phases. A provisioning system contacts AD and prepares a particular computer identity. The destination consumes the resulting provisioning data to configure its local Windows installation without requiring a DC connection for that step. Subsequent domain authentication and policy processing still have their normal network dependencies.
These are state-changing examples, not diagnostic collection. The first creates an AD account and a sensitive local provisioning file:
djoin /provision /domain contoso.com /machine APP01 /machineou "OU=Workstations,DC=contoso,DC=com" /dcname dc1.contoso.com /savefile D:\Provisioning\APP01.txt
The following applies that data to the intended destination computer’s local OS, for activation at restart:
djoin /requestODJ /loadfile D:\Provisioning\APP01.txt /windowspath C:\Windows /localos
Use the Djoin parameter reference for the installed version and target image. /reuse is significant: it resets the existing account’s password during provisioning. It is not an innocuous way to silence an account-exists warning.
Treat provisioning data as a credential dependency
Provisioning data represents a particular machine’s domain identity and secret material: Microsoft’s ODJ structure definition includes the machine-account password. Restrict its storage and transfer, deliver it to the intended device, and remove retained copies through the deployment process. Do not distribute one machine’s blob across a fleet or embed it in a reusable base image. Base64 encoding is not encryption.
If provisioning is repeated or the account password changes, check which blob the destination received and which account state it matches. Applying an older file after a later provisioning operation can leave the local and directory secrets mismatched. The offline step can succeed even though the AD account no longer exists or its state has changed.
Verify the resulting identity and service path
After the required restart and network availability, verify the expected domain/computer identity, selected DC and machine secure channel. Confirm the account’s OU, GUID, memberships, DNS/SPN registration, and applied computer policy. Test any first domain-user logon or certificate enrollment required by the deployment; those are distinct from applying offline join data.
If an already-joined machine later can’t authenticate, start with secure-channel diagnosis. Rejoining every broken member can recreate identities or hide why the secrets diverged. Keep the original state long enough to find out what needs repairing.