There are many questions asked about the impacts of moving to Microsoft Exchange Online (ExO)and there are some really great resources out there including a number of Insentra blogs. One of the less covered topics is how Messaging Record Management (MRM) works with data being migrated into ExO, specifically around retention age. Many clients have asked this question and we couldn’t find any great resources which is why we went and did some testing and I have written this blog.
Let us begin by saying Microsoft are very clear on the two attributes used to determine the date and time of when an MRM policy can be applied and can be found on this TechNet article
the two attributes being
- Date of Delivery, MAPI Property name – PR_CLIENT_SUBMIT_TIME
- Creation Date, MAPI property name – PR_CREATION_TIME
However, the question starts to become complex when archive migration occurs. We must add that all archive migration vendors do their upmost to migrate messages through the existing Exchange Web Services (EWS) API exactly as they are extracted from the source with all date and time stamps the same. The reason why the question becomes complex is that once the archive migration product pushes the message through the EWS API into the Exchange Online Mailbox the Creation Time attribute PR_CREATION_TIME is stamped with the current date of when the message was moved into the Mailbox, not the original date as stored in the source archiving solution.
So which date applies when working out retention in MRM?
To answer this, we performed the following test
- We Isolated a couple users that had archive content older than the MRM policy we were looking to use
- We setup test mailboxes in ExO and licenced them (this was a test, so we didn’t enable litigation hold)
- We then created and applied a 7 year delete retention policy to the test mailboxes, specifically setting the default policy tag (DPT) type to all, which applies over all folders.
- Using an archive migration product, we mapped the source archive to test mailbox
- We created a migration filter so not to expend any evaluation licence (this also had an added bonus that when coming to view the migrated content in the mailbox, it was easy to see whether our MRM policy had applied)
- Once the preparation had completed we started the migration and monitored the mailboxes
The results showed that although the PR_CREATION_TIME is set with the current date and time of when the messages were migrated, it had no effect on the criteria by which the MRM policy works out what action it needs to take, as the PR_CLIENT_SUBMIT_TIME (Date of Delivery) remains the same. This highlights that an earlier date on one of these attributes supersedes the other.
In summary we can be confident that MRM retention policies treat migrated data the same as if it hadn’t previously been archived.