A while ago, I blogged about issues with deprovisioning Online archive. The root cause behind this was attributes authored (and incorrectly provisioned from) on-prem. I’ve recently run across a similar issue, this time with the archive not able to be provisioned. The error message encountered when trying to enable the archive via PowerShell or the EAC was the following:
‘Can’t enable the archive for ‘user’ because their primary mailbox is located on an on-premises server. To enable a cloud-based archive mailbox for this user, you must use your on-premises Exchange admin center or Exchange Management Shell.’
A quick check in AD showed that the value of msExchRemoteRecipientType was populated, so the mystery was quickly solved. The other mystery remains however – why do ‘experts’ performing migration from 3rd party products insist on poking around the on-prem AD and making a mess (or don’t clean up after the migration)?