Another issue with archives due to msExchRemoteRecipientType populated

‚Äč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)?

This entry was posted in Exchange Online, Office 365. Bookmark the permalink.

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.