Setup of first Exchange 2013 or 2016 server fails in a child domain due to AD replication

Let's say you have a parent-child Active Directory topology of and You have Exchange 2010 installed in the parent domain, and you want to install 2013 or 2016 into the child domain. You run through all the AD prep work. You then run Exchange setup to install your first mailbox server and it bombs out. Being the handy Exchange admin that you are, you know to consult C:\ExchangeSetupLogs\ExchangeSetup.log for all the gory details about the error.

You see various errorsĀ such as:

  • Couldn't find recipient "{bb558c35-97f1-4cb9-8ff7-d53741dc928c}". Reason:{bb558c35-97f1-4cb9-8ff7-d53741dc928c} isn't a mailbox user.
  • DSID-03152C45, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 200f4 (homeMDB)

There are various permutations of this issue, but the root cause is the same: slow AD replication between the root domain and the child domain. In one version of this issue, here is Exchange setup is doing:

  1. A mailbox database is created in the child domain.
  2. The arbitration mailbox (residing in the root domain) is mail-enabled which modifies its homeMDB value.
  3. The root DC processing this modification rejects itĀ because the homeMDB value does not point to a valid object.

The root DC thinks the new homeMDB value is not valid because it hasn't replicated the newly-created mailbox database object from the child domain yet. What should we do here?

Unfortunately, there are no great workarounds. One option is to wait for AD replication to catch up (at least 15 minutes usually), and then re-run setup.

The other option is a bit more involved:

  1. Install the first Exchange 2013 or 2016 mailbox server into the root domain so that the arbitration mailboxes will be staged properly.
  2. Install another Exchange 2013 or 2016 mailbox server into the child domain.
  3. Move all the arbitration mailboxes to the child domain's Exchange server (Get-Mailbox -Arbitration | New-MoveRequest -TargetDatabase MyCoolDb)
  4. Uninstall the root domain's Exchange server.

This solution is a bit tedious but it'll get the job done without potentially re-running setup multiple times.