Hello Microsoft Community,

The safest online recovery is to restore the original Password Settings Container from Active Directory Recycle Bin if it is present there; otherwise, the currently published Microsoft remediation is the KB3144809 procedure to reset the applicable DomainUpdates state and rerun adprep /domainprep on the Infrastructure Master.^1^

The container is a well-known object under CN=System in every domain naming context and holds fine-grained password-policy objects. It should not be manually recreated as a generic container.^2^

1. Perform the authoritative location check

Although LDAP queries already found no correctly located object, run Microsoft’s forest-wide class search to exclude a moved object:

repadmin /showattr . ncobj:domain: /filter:"(objectclass=msds-PasswordSettingsContainer)" /subtree

• If found elsewhere, do not run Adprep. In LDP → Browse → Modify RDN, move it to: CN=Password Settings Container,CN=System,DC=example,DC=com
• Use repadmin /showobj if modification history is needed.
• If it is not returned, continue with Recycle Bin recovery.

This is Microsoft’s documented distinction between a moved and missing container.^1^

2. Prefer Recycle Bin recovery when the deleted object exists

Because Recycle Bin is enabled, query a known healthy writable DC, not the impaired Server 2016 DC:

$dc = "healthy-dc.example.com"
Get-ADObject -Server $dc -IncludeDeletedObjects `
  -Filter 'isDeleted -eq $true -and msDS-LastKnownRDN -eq "Password Settings Container"' `
  -Properties objectClass,lastKnownParent,msDS-LastKnownRDN,ObjectGUID |
  Format-List Name,ObjectGUID,ObjectClass,lastKnownParent,msDS-LastKnownRDN

Proceed only if the result’s class/identity metadata identifies the deleted Password Settings Container and lastKnownParent is exactly:

CN=System,DC=example,DC=com

Restore that specific GUID:

Restore-ADObject -Server "healthy-dc.example.com" `
  -Identity "<ObjectGUID-from-the-query>"

Restore-ADObject restores the object to lastKnownParent when TargetPath is omitted. It cannot operate against an RODC.^3^ Recycle Bin can recover only objects deleted after it was enabled and still retained as restorable deleted objects.^4^

This branch avoids changing Adprep revision and operation markers.

3. If no restorable object exists, use KB3144809 under a change window

The current Microsoft article still publishes this recovery sequence for a missing container. Formal support eligibility for the servers themselves also depends on their current lifecycle or applicable ESU coverage.

1. Sign in to the Infrastructure Master using a Domain Admin account. Your stated FSMO placement identifies the Server 2012 R2 DC as that server.
2. Take and validate backups before modifying anything.
3. Import an LDIF that changes:

      CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System,DC=example,DC=com
   

   setting revision to 1.
4. Delete only the DomainUpdates operation container corresponding to the operation that must be rerun.
5. From an elevated prompt on the Infrastructure Master, run Adprep from the applicable Windows Server installation media:

      "<installation-media-path>\adprep.exe" /domainprep
   

6. Review:

      C:\Windows\debug\adprep\logs\<Date Time>\ADPrep.log
   

/domainprep must run on the Infrastructure Master and requires Domain Admin membership. Microsoft directs administrators to use the Adprep version included with Windows Server installation media.^5^

Do not guess the operation-container GUID. The published article gives an example but does not provide enough information here to map that GUID safely to your domain’s required update. If it cannot be positively identified from the relevant Adprep records, engage Microsoft Support before deleting it. Deleting the wrong marker could cause unrelated domain preparation operations to rerun.

Production safeguards

Before either write operation:

1. Capture health baselines from a healthy administrative host:

      repadmin /replsum
      repadmin /showrepl *
      dcdiag /e /c /v /f:C:\Temp\dcdiag-before.txt
      dcdiag /test:dns /e /v /f:C:\Temp\dns-before.txt
   

   DCDiag checks DC advertising, LDAP/RPC connectivity, replication, DNS, SYSVOL-related events, and other DC functions.^6^
2. Resolve replication, DNS, database, or SYSVOL failures first. Do not use a DC with unverified replication as the repair origin.
3. Take current system-state backups of at least the Infrastructure Master and another writable DC:

      wbadmin start systemstatebackup -backuptarget:<backup-volume-or-share>
   

   Microsoft recommends regularly backing up at least two writable DCs per domain.^7^ The documented backup workflow is available through Windows Server Backup or wbadmin.^8^
4. Confirm the backup job succeeded, the backup version appears in the backup catalog, and the destination is readable. Completion alone does not prove restorability; use an established, tested DC restore procedure rather than treating the new backup as an instant rollback.
5. Export or record the current ActiveDirectoryUpdate revision, all DomainUpdates operation objects, FSMO ownership, replication state, and relevant event logs.

Interruption and risk

The documented Recycle Bin and Adprep operations are online directory changes; they do not inherently require restarting or demoting existing DCs. However, zero interruption cannot be guaranteed, particularly because a Server 2016 DC is already exhibiting LSASS and logon failure. Schedule the change off-peak and ensure clients can reach another healthy writable DC.

The main risks are:

• replicating an incorrect directory modification to every DC;
• rerunning unintended DomainUpdates operations if the wrong marker is removed;
• exposing existing replication or DNS faults during convergence;
• affecting authentication until the restored object has replicated.

The documented repair does not directly rewrite DNS zones or GPO contents, but authentication depends on this container on Windows Server 2012 and later. After recovery, verify the object against each writable DC, then rerun the baseline tests:

$dn = "CN=Password Settings Container,CN=System,DC=example,DC=com"
Get-ADDomainController -Filter 'IsReadOnly -eq $false' | ForEach-Object {
    Get-ADObject -Server $_.HostName -Identity $dn -Properties objectClass |
        Select-Object @{n='DC';e={$_.PSComputerName}},
                      DistinguishedName,ObjectClass
}

Also confirm successful replication, DNS tests, normal DC advertising, interactive logon, and absence of new LsaSrv/Directory Service errors before closing the change.

References

1. Can't sign in to a domain controller, and the LSASS process stops responding
2. [MS-ADTS]: Password Settings Container | Microsoft Learn
3. Restore-ADObject-Description
4. Enable and use Active Directory Recycle Bin
5. Adprep | Microsoft Learn
6. DCDiag
7. Active Directory Forest Recovery - Determine how to recover the forest
8. Active Directory Forest Recovery - Back up the System State data