Exchange PrepareSchema and PrepareAD errors: permissions, schema master and AD versions

Exchange Server SE and 2019 can't be installed or updated until Active Directory is prepared, and /PrepareSchema and /PrepareAD fail fast when the account, the computer's location or replication isn't right. In this post I'll match the common errors to their causes, give you the commands that fix them and show how to verify the AD versions afterwards.

Symptoms#

Running Setup.exe /PrepareSchema, /PrepareAD or a CU upgrade stops at the readiness checks with:

The Active Directory schema isn't up-to-date, and this user account isn't a member of the 'Schema Admins' and/or 'Enterprise Admins' groups.

Or C:\ExchangeSetupLogs\ExchangeSetup.log contains:

Setup encountered a problem while validating the state of Active Directory: Exchange organization-level objects haven't been created, and setup can't create them because the local computer isn't in the same domain and site as the schema master. Run setup with the /PrepareAD parameter on a computer in the domain <domain_name> and site <Default_First_Site_Name>, and wait for replication to complete.

A third variant points at a stale reference in the Exchange configuration container:

The well-known object entry B:<guid>:CN=Recipient Management\0ADEL:<guid>,CN=Deleted Objects,DC=contoso,DC=com on the otherWellKnownObjects attribute in the container object CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=contoso,DC=com points to an invalid DN or a deleted object. Remove the entry, and then rerun the task.

Older scripts fail for a simpler reason: since the September 2021 CUs, setup no longer accepts /IAcceptExchangeServerLicenseTerms. Use /IAcceptExchangeServerLicenseTerms_DiagnosticDataON or /IAcceptExchangeServerLicenseTerms_DiagnosticDataOFF.

Why it happens#

Each preparation step has its own permission and location rules:

The errors above come down to four causes:

• The groups aren't in your token. New group memberships only apply after you sign out and back in. In a non-elevated prompt, User Account Control also filters Schema Admins and Enterprise Admins down to "deny only". Setup then sees an account without the rights, even though AD lists it as a member.
• Wrong site or domain. In a multi-site forest the schema master often sits in a different site from the Exchange servers. Setup won't create organization-level objects from there, and the setup wizard can't prepare AD in that situation at all.
• Replication hasn't finished. Each step must reach every domain controller before the next one runs; preparing domains too early can fail.
• Stale AD references. When an Exchange object such as a role group has been deleted, otherWellKnownObjects can still point to it in Deleted Objects.

How to fix it#

1. Check who and where you are#

whoami /groups | findstr /i "Schema Enterprise"
netdom query fsmo
nltest /dsgetsite

Both groups should show Enabled group; Group used for deny only means the prompt isn't elevated. Then compare the schema master's site with the one nltest returned:

$sm = (Get-ADForest).SchemaMaster
Get-ADDomainController -Identity $sm -Server $sm | Select-Object HostName, Domain, Site

2. Fix the token#

Have the AD team add your admin account to Schema Admins and Enterprise Admins for the duration of the change, sign out and back in, then open the command prompt with Run as administrator.

3. Run the steps from the schema master's domain and site#

Use a domain member in that domain and site with a supported .NET Framework and the RSAT-ADDS feature (the Visual C++ runtime isn't needed for command-line AD preparation). Mount the ISO of the build you're about to install and run each step, checking replication in between:

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

/OrganizationName is only for a brand-new organization. With a single domain, /PrepareAD already prepares it, so /PrepareAllDomains matters only for additional domains.

4. Remove stale otherWellKnownObjects entries#

For the well-known object error, download SetupAssist from Microsoft's CSS-Exchange project (aka.ms/ExSetupAssist) and run .\SetupAssist.ps1 -OtherWellKnownObjects. It saves the current entries to ExchangeContainerOriginal.txt, looks for references to deleted objects and writes ExchangeContainerImport.txt to remove them. Review that file, import it as the script instructs, then run /PrepareAD again.

5. Still failing?#

Run .\SetupLogReviewer.ps1 -SetupLog C:\ExchangeSetupLogs\ExchangeSetup.log (also from CSS-Exchange). It looks for known problems in the log and tells you what to fix.

Verify the fix#

Read the three values setup updates (requires the Active Directory PowerShell module) and compare them with the table on Microsoft Learn:

$root = Get-ADRootDSE
$schema = Get-ADObject "CN=ms-Exch-Schema-Version-Pt,$($root.schemaNamingContext)" -Properties rangeUpper
$domain = Get-ADObject "CN=Microsoft Exchange System Objects,$($root.defaultNamingContext)" -Properties objectVersion
$org = Get-ADObject -SearchBase "CN=Microsoft Exchange,CN=Services,$($root.configurationNamingContext)" -SearchScope OneLevel -Filter "objectClass -eq 'msExchOrganizationContainer'" -Properties objectVersion
'rangeUpper {0} | objectVersion (Default) {1} | objectVersion (Configuration) {2}' -f $schema.rangeUpper, $domain.objectVersion, $org.objectVersion

Reading the table: from 2019 CU14 to SE RTM only the Configuration value changes, so AD preparation must run but the schema stays the same; from 2019 CU15 nothing changes. Later SE updates can change these numbers, so check the current table. Then confirm every domain controller sees the schema value:

$schemaNC = (Get-ADRootDSE).schemaNamingContext
foreach ($d in (Get-ADForest).Domains) {
  Get-ADDomainController -Filter * -Server $d | ForEach-Object {
    $v = (Get-ADObject "CN=ms-Exch-Schema-Version-Pt,$schemaNC" -Server $_.HostName -Properties rangeUpper).rangeUpper
    '{0,-40} {1}' -f $_.HostName, $v
  }
}

Prevent it next time#

• Agree a split with your AD team: they run /PrepareSchema and /PrepareAD from the schema master's site ahead of the change window, and Exchange admins run the upgrade with Organization Management rights.
• Check AD replication health and take a system state backup of a domain controller first, because schema extensions can't be rolled back.
• Remove temporary Schema Admins and Enterprise Admins memberships afterwards.
• Clear the server prerequisites too (Exchange setup prerequisite errors), and if an upgrade fails part-way, recover it without deleting anything.

References#

• Prepare Active Directory and domains for Exchange Server (Microsoft Learn)
• Fix failed Exchange Server updates (Microsoft Learn)