Hello Microsoft Community,

Hi Pisek Siripoka,

Thank you for the detailed follow-up and for holding off on changes. Your checks are useful, but error 8240 alone does not confirm that the container is missing. The command may also be using an incorrect or unavailable search base. Microsoft’s documented search uses ncobj:domain: so you do not need to enter the domain naming context manually.

Answers to your questions

1. Read-only search: Run this command against each writable domain controller:

repadmin /showattr <DC-FQDN> ncobj:domain: /filter:"(objectClass=msDS-PasswordSettingsContainer)" /subtree

It searches the domain naming context, including for a container that may have been moved. If you use an explicit naming context instead, first verify it against the DC’s defaultNamingContext. An 8240 result from the earlier command is not, by itself, proof that the container is absent throughout the domain.

1. If the container is confirmed absent and cannot be restored: Microsoft documents resetting the applicable DomainUpdates state and then running adprep /domainprep. This is a specific recovery procedure; do not run /domainprep alone as a substitute. The procedure is performed on the Infrastructure Master by a Domain Admin. See Microsoft’s KB guidance for a moved or missing Password Settings Container and the Adprep documentation.
2. Production impact: The Microsoft article documents the recovery steps, but it does not provide a production success rate or guarantee uninterrupted authentication. It does not instruct you to restart or demote the Infrastructure Master as part of those steps, but that does not guarantee there will be no service impact.
3. Identifying the operation marker: Revision 16 is consistent with Windows Server 2016 domain preparation, but it does not identify which operation marker to remove. The KB gives 71482d49-8870-4cb3-a438-b6fc9ec35d70 as an example and says to remove the marker for the operation that needs to be rerun. Do not delete all markers or select one based only on revision 16; confirm the exact object and its full distinguished name against the KB procedure before making a change. See Microsoft’s domain-wide updates reference.

Recommended next steps

First, run the read-only search against every writable DC. If it returns the container, record its distinguished name and follow the KB guidance to move it to the expected location under CN=System.

If no result appears on any DC, check replication health before considering a repair:

repadmin /replsummary

dcdiag /e /c /v

Before making directory changes, confirm you have recent, valid system-state backups and a recovery plan. Microsoft’s AD forest recovery guidance covers system-state backups. Also record the current revision value and the objects under CN=Operations,CN=DomainUpdates,CN=System on the Infrastructure Master.

If the applicable marker is not clear from the KB and those records, pause and have an AD DS specialist review it before deleting anything or resetting the revision. If the container is confirmed absent, replication is healthy, and the correct marker is verified, schedule the KB procedure as a controlled change on the Infrastructure Master. Afterward, review ADPrep.log and confirm the container exists under CN=System and has replicated to all writable DCs.

Thank you again for gathering these results carefully. If you share the search results and replication summary—with domain and server names redacted—we can review them before you decide whether to proceed.

Hi,

Thank you for your detailed explanation and recommendations.

We have performed additional checks on our Active Directory environment.

Current findings:

1. We confirmed that the Password Settings Container is missing from its expected location on three Domain Controllers.

We searched Active Directory Deleted Objects with Get-ADObject -IncludeDeletedObjects, but no matching object was found.

Active Directory Recycle Bin is enabled.

We confirmed that the ADPrep revision value is 16 under CN=ActiveDirectoryUpdate,CN=DomainUpdates,CN=System.

We also attempted the following command against two Domain Controllers:

repadmin /showattr IFSDC01 "DC=example,DC=com" /filter:"(objectClass=msDS-PasswordSettingsContainer)" /subtree

Both attempts returned:

Win32 Error 8240 (0x2030):
There is no such object on the server.

We understand that this error may indicate an issue with the command's naming-context reference rather than conclusively proving the container is missing.

Before proceeding with KB3144809, we would appreciate clarification on a few points:

Is there an alternative read-only command to confirm whether the container has been moved elsewhere in the domain?

If the container is confirmed missing and cannot be restored from AD Recycle Bin, is rerunning adprep /domainprep the recommended approach?

Has this recovery procedure been performed successfully on a production AD environment without restarting the Infrastructure Master or interrupting user authentication?

What is the safest way to identify the exact DomainUpdates operation marker that needs to be removed?

Our main concern is avoiding disruption to the existing production Domain Controllers, particularly the Windows Server 2012 R2 Infrastructure Master, which is currently operational.

We have not made any changes to ADPrep or the directory objects.

Thank you again for your guidance.

Hi Pisek Siripoka,

Thank you for checking both domain controllers and sharing the details before making a production change.

The missing Password Settings Container is relevant to the sign-in issue. Microsoft states that on Windows Server 2012 and later, its absence or incorrect location can cause sign-in failures. Event ID 5000 alone does not confirm the cause; please compare its full details with the symptoms in KB 3144809.

Before changing ADPrep data, please check these options:

1. Search each writable DC for a moved container. The . in this command means the DC where you run it, so run it on each writable DC:

Cmd:

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

If the object is found in the wrong location, follow the move procedure in the KB.

1. Check Deleted Objects. Since the Recycle Bin is enabled, look for the exact Password Settings Container there. Restore it only if it is still restorable, its object class is correct, and its last known parent is CN=System in the domain. Recycle Bin recovery applies only to objects deleted after the feature was enabled. Microsoft documents restoring deleted AD objects and the Restore-ADObject cmdlet.
2. If the container is neither present elsewhere nor restorable, KB 3144809 documents resetting the applicable domain update state and running adprep /domainprep on the Infrastructure Master as a Domain Admin. In your environment, that is the Windows Server 2012 R2 DC. Confirm the exact object before changing anything: the KB targets CN=ActiveDirectoryUpdate under CN=DomainUpdates; CN=ForestUpdates is a different object. The reported revision value of 16 alone is not enough to identify which object it came from. Follow the KB’s operation-marker instructions exactly; do not remove other markers.

Before an ADPrep change, verify current system-state backups for both DCs and check replication and DC health:

Cmd:

repadmin /replsummary

*repadmin /showrepl **

dcdiag /e /c /v

dcdiag /test:dns /e /v

The KB does not specify a DC restart or demotion, but it does not guarantee zero service impact. Do not proceed if replication is unhealthy or you lack a recovery plan. Use /domainprep only for this repair; /gpprep is separate and changes Group Policy permissions. DNS is not directly reconfigured by this repair, though replication problems could affect AD-integrated services. See Microsoft’s Adprep guidance.

The KB remains published as Microsoft guidance. Product support is a separate matter: Windows Server 2012 R2 ESU ended on October 13, 2026, and Windows Server 2016 extended support ends on January 13, 2027. See the Microsoft lifecycle dates.

Could you share the exact distinguished name where revision 16 was read, whether the container appears in Deleted Objects, and sanitized replication and health-check results? Please include the full Event ID 5000 details, with domain names, hostnames, and IP addresses removed.

Thank you again for checking the recovery options and risks before making a production change.