0x80072030 during Exchange setup: Active Directory objects cannot be found

Fix it now

Setup asked a domain controller for an Exchange directory object and was told there is no such object. 0x80072030 is the directory-service error ERROR_DS_NO_SUCH_OBJECT. Either the preparation steps have not been run in order, or they have run and the change has not yet reached the controller setup happens to be using.

repadmin /replsummary
repadmin /syncall
E:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareSchema
E:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareAD
E:\Setup.exe /IAcceptExchangeServerLicenseTerms_DiagnosticDataON /PrepareAllDomains

1. Open C:\ExchangeSetupLogs\ExchangeSetup.log and find the distinguished name setup could not read. Everything below turns on that one string.
2. Decide whether the object exists. Open ADSI Edit against the Configuration naming context and look under the Services container for the Microsoft Exchange organisation.
3. If the object is there, this is replication rather than preparation. Run only the first two commands, confirm the object has arrived, and rerun setup. Do not run the preparation steps again.
4. If the object is genuinely absent, run the three Setup lines in the order shown and let Active Directory replicate between each one before starting the next.
5. Check your rights first: /PrepareSchema needs Schema Admins and Enterprise Admins, /PrepareAD and /PrepareAllDomains need Enterprise Admins, and /PrepareDomain in a child domain needs Domain Admins there.

Substitute your own installation media drive letter. Add /OrganizationName:"Contoso" to the /PrepareAD line only when you are creating the Exchange organisation for the first time; on an existing organisation the name is read from the directory.

If setup now gets past the directory step you are done. If not, the next section separates the three conditions this code covers, because they need different work.

Why it happens

Exchange keeps its entire organisational configuration inside Active Directory, in the configuration naming context under the Services container, and setup reads and writes that tree continuously. Every one of those operations lands on one domain controller. 0x80072030 is what comes back when that controller does not hold the object being asked for: the low word, 0x2030, is Win32 error 8240, ERROR_DS_NO_SUCH_OBJECT, published as “There is no such object on the server”.

Notice what the code does not say. It does not say the object has been deleted, or that your account is not allowed to see it, or that the schema is wrong. It says this server does not have it. In a healthy forest that is usually a statement about timing rather than about content, which is why the same setup run can succeed twenty minutes later with nothing changed.

The three preparation stages exist to be run in order and to be allowed to replicate between them. The schema is extended, then the organisation-level objects are created, then each domain that will hold mail-enabled objects is prepared. Running the next stage because the last one returned success is the most common route to this error, because success means the write was accepted by one controller, not that the forest knows about it.

The companion codes separate existence from permission. LDAP result 32 is noSuchObject, the protocol-level version of the same complaint. LDAP result 50 is insufficientAccessRights, which means the object is there and your account was refused; the matching directory-service error is 8344, ERROR_DS_INSUFF_ACCESS_RIGHTS. 0x8007200A is Win32 8202, ERROR_DS_NO_ATTRIBUTE_OR_VALUE, “The specified directory service attribute or value does not exist” – an attribute-level miss rather than an object-level one.

Full reference

The preparation stages, and what each one needs

The schema and organisation stages must be run from a machine in the same Active Directory domain and site as the schema master, or with /DomainController: naming the schema master. Hybrid organisations add /TenantOrganizationConfig to the /PrepareAD line. Between every stage, Microsoft’s instruction is the same and it is not decoration: wait for Active Directory replication to reach all domain controllers before running the next one.

Reading the code you were given

Where the evidence lives

• C:\ExchangeSetupLogs\ExchangeSetup.log is the primary log and it records the distinguished name that failed. Read it from the bottom.
• C:\ExchangeSetupLogs\ also holds the per-stage logs written by the preparation switches.
• The Application log on the Exchange server carries the MSExchange ADAccess entries written at the same moment, which tell you which directory server was in use.
• ADSI Edit connected to the Configuration naming context is the fastest way to answer the only question that matters: is the object there or not.

Event ID 2937 and Event ID 2501 turn up in the same window on servers hitting this error. Microsoft publishes no description for either of them, so do not try to decode the number. Read the event’s own text, which names the object and the attribute involved, and work from that.

When existence, rights and replication are all ruled out

• Confirm there is exactly one Exchange organisation in the forest. Two, created by two people running /PrepareAD with different organisation names, produce failures that look like missing objects and cannot be quietly undone.
• Confirm the domain you are preparing has not been renamed or moved since it was last prepared.
• Check that no controller is stuck in a state where it advertises itself but refuses writes, which dcdiag reports and repadmin /replsummary does not.
• If setup consistently picks a different controller each run, name one with /DomainController: so the failures become reproducible before you try to explain them.
• Repeat the object check against the controller setup actually used, not against the one your management console happens to be bound to.

Preparing a forest you did not build

Inherited estates often carry a partial preparation from a project that stopped. The symptom is a Microsoft Exchange container that exists and looks plausible, with one stage’s objects inside it and not the next. There is no supported way to tell setup to skip ahead: run the stages in order from the beginning. Rerunning a stage that has already completed is safe and quick, and it is far cheaper than guessing which one was missed.

The one thing to check before you start is the organisation name. If the container exists, the organisation already has a name, and /PrepareAD will use it. Passing a different name with /OrganizationName is how a forest ends up with two Exchange organisations, and the recovery from that is a directory restore rather than a command.

Every code this article covers

Confirm the fix worked

1. The object named in ExchangeSetup.log is present on every domain controller Exchange might use, not just on the one you inspected.
2. repadmin /replsummary reports no failures for the controllers in the Exchange server’s site.
3. The setup step you were running completes and ExchangeSetup.log ends in success rather than a rollback.
4. The Microsoft Exchange organisation object is visible under Services in the configuration naming context, and there is only one of it.
5. Get-ExchangeServer runs without a directory error from a fresh shell.

Questions people ask about this