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

Sometimes things don't appear to be what they are in reality. When I discovered that the Default MRM Policy in my Office 365 tenant was blank, I was sure that a bug had stripped the policy of its retention tags. I couldn't possibly have had anything to do with this sad state of affairs. Right?  Well, not so much. It turns out that the blank policy had been created by someone after renaming the original policy to be something else. The bad news is that Exchange Online administrative auditing couldn't help because this happened more than 90 days ago. The good news is that Office 365 Support was able to deduce what had happened by finding some other clues. This still leaves me feeling like an idiot, but at least I'm a knowledgeable idiot.

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:


Name                      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:03
Default MRM Policy                        11/04/2015 18:31:27 11/04/2015 18:31:27
Business Executives                       13/02/2015 12:59:08 13/02/2015 12:59:08
Management retention policy               27/01/2014 20:36:50 14/02/2016 13:01:18
Retention Policy 2                        29/05/2015 16:30:38 29/05/2015 16:30:38
Business Analysts                         15/01/2015 11:13:09 15/01/2015 11:19:07
Office 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-RetentionPolicy

ObjectModified     : Management retention policy
CmdletName         : Set-RetentionPolicy
CmdletParameters   : {Identity, RetentionPolicyTagLinks}
ModifiedProperties : {}
Caller             :
ExternalAccess     : False
Succeeded          : True
Error              :
RunDate            : 14/02/2016 13:01:18
OriginatingServer  : AMXPR04MB134 (15.01.0403.019)
IsValid            : True
ObjectState        : 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, RetentionPolicy

Name                                                          RetentionPolicy  
----                                                          ---------------  
ExchangeOnline-12c139bc-eafa-4a43-b4d2-e285f83e075d           Office 365 Exchange Book Retention Policy
ExchangeOnlineDeskless-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

Discuss this Blog Entry 2

on Mar 22, 2016

Tangentially related: In Hybrid mode, It's actually a good idea to leave your Default MRM/Retention Policy devoid of tags. Since there's no way to "map" onprem policies to EXO policies, when you migrate a mailbox to EXO, they're going to get that Default EXO policy - dangerous if you have some sort of on-prem variance policy that allows for longer retention than the default.

on Mar 23, 2016

That's a reasonable and logical suggestion. Good idea!

Please or Register to post comments.

What's Tony Redmond's Exchange Unwashed Blog?

On-premises and cloud-based Microsoft Exchange Server and all the associated technology that runs alongside Microsoft's enterprise messaging server.


Tony Redmond

Tony Redmond is a senior contributing editor for Windows IT Pro. His latest books are Office 365 for Exchange Professionals (eBook, May 2015) and Microsoft Exchange Server 2013 Inside Out: Mailbox...
Blog Archive

Sponsored Introduction Continue on to (or wait seconds) ×