The curious case of the blank default retention policy in Exchange Online

Recently I had occasion to check the default retention policy (called the Default MRM Policy) for my Office 365 tenant. As you do, I ran the Get-RetentionPolicy cmdlet and saw the following:

Get-RetentionPolicyName                      RetentionPolicyTagLinks                        Guid                                          ----                      -----------------------                        ----                                          ArbitrationMailbox        {AutoGroup, ModeratedRecipients, Never Dele... b5175f79-9ff0- Default MRM Policy        {}                                             f70c00c7-5565- Business Executives       {Contacts 3650 day expiry, Inbox 30 day exp... 528d86f3-5904- Management retention p... {Remove Clutter after 30 days, Deleted Item... f15dcd7c-69a6- Retention Policy 2        {Default - 60 days to archive}                 60353519-6348- Business Analysts         {Inbox 30 day expiry, 1 Year Delete, 6 Mont... c97a5a6e-c7dc- Office 365 Exchange Bo... {5 Year Delete, 1 Year Delete, 6 Month Dele... ca726a88-94be-

It doesn’t take more than a glance to notice that the Default MRM Policy is curiously devoid of retention tags. In fact, it’s not much of a policy at all as it tells the Managed Folder Assistant (MFA) to do precisely nothing. Remember that the Default MRM Policy is assigned automatically to all mailboxes created in Exchange Online, so a non-functional retention policy is perhaps not what we need. Unless of course, you want to tell MFA to take a nice rest.

In my case, I rather like giving MFA work to do and believe that retention policies are a good thing. Having a tag-less policy didn’t seem reasonable, so I investigated further:

Get-RetentionPolicy | Format-Table Name, WhenCreated, WhenChanged Name                                      WhenCreated         WhenChanged        ----                                      -----------         -----------        ArbitrationMailbox                        27/01/2014 20:36:37 27/01/2014 20:37:03Default MRM Policy                        11/04/2015 18:31:27 11/04/2015 18:31:27Business Executives                       13/02/2015 12:59:08 13/02/2015 12:59:08Management retention policy               27/01/2014 20:36:50 14/02/2016 13:01:18Retention Policy 2                        29/05/2015 16:30:38 29/05/2015 16:30:38Business Analysts                         15/01/2015 11:13:09 15/01/2015 11:19:07Office 365 Exchange Book Retention Policy 27/01/2014 20:36:41 17/03/2015 09:56:49

This output tells us that the Default MRM Policy was created on 11 April 2015. My Office 365 tenant has been in place since mid-2011 so the relative youth of the policy seemed odd. Two questions needed to be answered. Why was the Default MRM Policy missing tags and why were the WhenCreated dates so recent?

Unfortunately, the mystery can’t be solved by checking the administrative audit log. I ran the Get-AdminAuditLogConfig cmdlet to check how long audit log entries are kept. The AdminAuditLogAgeLimit confirmed that the default 90-day limit applied. Clearly more than 90 days has passed since the policy was created (or updated), so searching the audit log won’t turn anything up. For the record, the command to look for updates to retention policies and the kind of data that is returned is shown below:

Search-AdminAuditLog –Cmdlets Set-RetentionPolicyObjectModified     : Management retention policyCmdletName         : Set-RetentionPolicyCmdletParameters   : {Identity, RetentionPolicyTagLinks}ModifiedProperties : {}Caller             : [email protected]     : FalseSucceeded          : TrueError              : RunDate            : 14/02/2016 13:01:18OriginatingServer  : AMXPR04MB134 (15.01.0403.019)Identity           : AAMkAGZkNGRjOTJiLTUxNTktNDkzMi1iMGY5LTZlMzU0NjdiZTk0MQBGAAAAAAAqzR2IbFIHQrCJAHnw+YLWBwDGvxq5r7PtSpLdyx6wPEE+AAAAl0FsAABhMVrmES2mTbiLMLLjQze4AAKfzh9eAAA=IsValid            : TrueObjectState        : New

If more than a few audit entries are found, you can pipe the output to the Out-GridView cmdlet to be able to review the output through a GUI. Not that raw PowerShell isn’t beautiful in its own way.

As auditing couldn’t tell me anything, I logged an Office 365 Service Request to see if that would reveal anything to explain the mystery. What I learned was that the “Office 365 Exchange Book Retention Policy” is the default policy for my tenant and is therefore assigned automatically to new mailboxes when they are created. How was this determined?

Exchange on-premises allows you to make any retention policy the default by setting its IsDefault property to $True. By comparison, Exchange Online uses the policy defined in the mailbox plan to assign a retention policy to new mailboxes. If you run the Get-MailboxPlan cmdlet to list the set of mailbox plans known to a tenant, you’ll see that each plan has an associated retention policy. In my case, that policy was “Office 365 Exchange Book Retention Policy”.

Get-MailboxPlan | Format-Table Name, RetentionPolicyName                                                          RetentionPolicy   ----                                                          ---------------   ExchangeOnline-12c139bc-eafa-4a43-b4d2-e285f83e075d           Office 365 Exchange Book Retention PolicyExchangeOnlineDeskless-bc1e76cc-4c0b-491c-a518-3a0a43cbf78e   Office 365 Exchange Book Retention Policy ExchangeOnlineEnterprise-8fc1c029-5e32-485e-9810-179fb4701447 Office 365 Exchange Book Retention Policy 

What seems to have happened is that the original Default MRM Policy was renamed at some point in the past. I can’t remember ever doing this nor can I come up with a good reason to rename the policy. However, a policy can be easily renamed by running the Set-RetentionPolicy cmdlet.

Set-RetentionPolicy –Identity “Default MRM Policy” –Name “Office 365 Exchange Book Retention Policy”

The only explanation seems to be that I must have been playing around with PowerShell and ended up renaming the original default policy and then created a new blank policy (with New-RetentionPolicy). All must have happened in a blur because I can’t remember anything, but software generally doesn’t do things without some human prompting. Perhaps it all occurred in a coffee-induced haze late at night. At least, that's the only excuse I can come up with. 

As to the relatively recent dates of the policies? Hari, my friendly Office 365 support engineer, explained that this can happen if an Office 365 tenant is moved between the Exchange forests that collectively make up Exchange Online. Apparently this happens from time to time for maintenance or to balance loads. Even though my tenant has been around since 2011, some parts of it were refreshed in 2014.

I hate not knowing why things happened, especially with software. I especially hate it when unexplainable events happen in an area that I know reasonably well. Oh well, there are more important things to focus on and renaming a retention policy to restore it to its original name is easy. But at least I learned about how Exchange Online know what retention policy should be assigned to new mailboxes.

Thanks to Office 365 support engineer Harikrishnan Sivaprakasam for setting my mind at ease.

Follow Tony @12Knocksinna