Ignore the title, I rarely find the exact words. Here’s the issue, which I encountered on a question asked over at Experts Exchange: the person asking the question was unable to remove the Online archive for a user synced from their local AD. Trying to disable the archive from the EAC or PowerShell resulted in error:
The action ‘Disable-Mailbox’,’Archive’, can’t be performed on the object ‘user’ because the object is being synchronized from your on-premises organization. This action should be performed on the object in your on-premises organization.
Now, this error basically indicates that the Source of Authority in this case is the on-prem AD, and this is nothing uncommon when running Hybrid and you try to deprovision the archive from the cloud service. This was not the case however, as the author confirmed that no Hybrid is in place. One additional piece of information further contributed to the confusion – changing the value of the msExchArchiveStatus attribute was being overwritten by the WAAD sync back feature. Since no Hybrid configuration was in place, this made no sense and the first step was to make sure that dirsync has been correctly reconfigured without the “hybrid” checkbox.
The mystery was solved after the author provided the value of the RemoteRecipientType and again assured me that there is no local Exchange server, and one never existed. It turns out that during the migration from Lotus Domino, the existing mailboxes were provisioned in the cloud by changing the value of the msExchRemoteRecipientType on-prem. While this will certainly work, provisioning an Archive mailbox using the same method will transfer the SOA for the archive to on-prem and will result in having to administer the archive from AD. When you do not have an on-prem Exchange server, this is certainly not something you want, and instead you should simply follow the normal way of provisoning mailboxes and archives directly in the cloud.
The solution was simple enough: locate the object on-prem, clear the value of the msExchRemoteRecipientType attribute and run a dirsync. As in some cases the dirsync client might fail to register the attribute change, it’s best to also ‘touch’ the on-prem object, by changing the value of say extensionAttribute10. Of course, you can just monitor the MIISClient and check whether the changes have actually been synchronized. After the sync, the Online archive for said object will be deprovisioned.
Guess the lesson learned here is to always plan ahead and make sure that you fully understand the design choices made. If you are not planning to keep any on-prem Exchange, or you are migrating from another messaging system, the best thing to do is to provision any mail related objects directly in the cloud. That includes user mailboxes and archives, shared mailboxes, resource mailboxes, distribution or mail enabled security groups, etc. Some people will probably argue that having on-prem Exchange is mandatory for proper management, but investing in hardware and licensing for something that you will be well equiped to manage using the cloud based tools is hardly justified for any small shop, or even organizations up to few thousand users.