Some of you might remember the issue we had with custom mailbox quotas back in the wave 14 version of Exchange Online. Namely, the UseDatabaseQuotaDefaults value was set to True for every mailbox and there wasn’t any way to change it to False. This in turn meant that any values for the ProhibitSendQuota, ProhibitSendReceiveQuota and the IssueWarningQuota parameters configured on the mailbox level were being ignored, which led to situations where people were getting the “Mailbox quota exceeded” warning, yet were able to send or receive messages even when over the respectibe quotas. Back then, the solution was to open a case with Microsoft and have someone change this on the backend. A more detailed description of the issue can be found for example here.
With wave 15, this was changed and we are now able to turn the UseDatabaseQuotaDefaults when needed (new mailboxes are also provisioned with it set to False). A similar parameter however has been largely overlooked – the UseDatabaseRetentionDefaults parameter, responsible for the Recoverable items duration. With the lack of point in time backups in Exchange Online, increasing the period for Recoverable items retention to the maximum allowed value of 30 days is a recommended step, and one that we do for each an every newly provisioned mailbox. The process is explained for example in this article.
To my surprise however, recently I run into a situation when a user asked us to recover some missing emails, and while double-checking what the retention period for this particular mailbox is, the result was listed as 14 days. So I went on double-checking our provisioning script, making sure it works as expected, and found nothing, Then I simply tried to adjust the value to 30 days and was met with a warning:
PS C:\> Get-Mailbox ChangeManagement | fl RetainDeletedItemsFor RetainDeletedItemsFor : 14.00:00:00 PS C:\> Set-Mailbox ChangeManagement -RetainDeletedItemsFor 30 WARNING: The command completed successfully but no settings of 'Change Management' have been modified.
Now I was even more puzzled, as this warning would only surface if the parameter was already set to 30 days. Yet the Get-Mailbox cmdlet still showed the value as 14 days. So I tried ‘refreshing’ the setting by switching to another value and then back to 30, here’s the result:
PS C:\> Set-Mailbox ChangeManagement -RetainDeletedItemsFor 29 PS C:\> Get-Mailbox ChangeManagement | fl RetainDeletedItemsFor RetainDeletedItemsFor : 14.00:00:00 PS C:\> Set-Mailbox ChangeManagement -RetainDeletedItemsFor 30 PS C:\> Get-Mailbox ChangeManagement | fl RetainDeletedItemsFor RetainDeletedItemsFor : 14.00:00:00
The most frustrating part was that this was happening only for *some* mailboxes in the tenant. So I went on testing this in my own Office 365 tenant, and had no issues there (apart from trying to change the value on a Discovery mailbox, but those are treated as exception). I reached out to the Exchange MVPs for some help, and they soon pointed me in the right direction. Turns out, all the older mailboxes had the UseDatabaseRetentionDefaults parameter set to True, and thus were using the default value of 14 days, not allowing it to be overwritten with the custom setting. Luckily, changing this is possible in the wave 15 version, so all we needed was to get a list of all the affected mailboxes and switch the UseDatabaseRetentionDefaults off. The good news is that any new mailbox will be created like this, and no intervention is needed. For people using old tenants – double check on this, to prevent some nasty surprises! It seems this has been common enough scenario to have a separate KB article dedicated to it: http://support.microsoft.com/kb/2714467/en-us
I wish we knew about this back when we switched UseDatabaseQuotaDefaults after the wave 15 upgrade.