A topic that seems to be surrounded with much confusion in Exchange Online is the concept of “Retention Policies”. While the feature itself is not new to Exchange, for many organizations it seems that establishing their first email retention strategy is coupled with their migration to the cloud.
Even for organizations that have a well established email retention strategy, the move to the cloud changes many of the factors that may have contributed to the policy and it’s worth reevaluating.
Below are some of the commonly misunderstood functions of Retention Policies and some of the pitfalls I’ve seen in unsuccessful attempts to establish an email retention strategy.
What Retention Policies Are
Perhaps a result of the name itself, there often seems to be confusion about what retention policies even are. Part of the confusion is that a legal definition of “retention policy” probably doesn’t exactly equate to the functionality of the Exchange feature. If a client previously had a third-party system in place for “email retention”, it can add to the confusion.
The most simple definition that I provide to clients is: “Retention Policies define the maximum amount of time that an email is kept but with no guarantee that it will be kept that long.” You can see how this definition might differ from other types of retention policies or strategies in an organization. If you’re developing an “employee retention strategy”, the goal of that strategy is not to create a timeline for when you’re getting rid of your employees.
A more detailed explanation of Retention Policies would include that they are comprised of “Retention Tags” and tags can have different types actions and functionality. For more information, TechNet has a pretty good article on the topic: Retention Tags and Retention Policies.
What Retention Policies Are Not
We take you through 10 best practices, considerations, and suggestions that can enrich your Microsoft Teams deployment and ensure both end-user adoption and engagement.
Working with the above “simple definition”, we now know there is no guarantee that an email will be kept the length of time specified in the Retention Policy. This is evident when you look at the tags in the Retention Policy, you’ll see an action like “Delete After 7 Years”. So while the email will be deleted after 7 years by the system, it could also be deleted by the user after 7 days.
So Retention Policies really don’t actually “retain” anything, instead they actually remove data. If you’re looking to keep emails for a minimum period of time, regardless of user action, the feature you want is either “Litigation Hold” or “In-Place Hold”. If your corporate policy is to keep emails for 7 years (no more, no less), then a combination of Retention Policies with Litigation Hold or In-Place Hold can help you achieve this.
So How About “Retention Hold”?
The feature “Retention Hold” has a name made of two words that might make you think you’re keeping emails. While it’s sort of true, it might not be how you expect.
Basically the Retention Hold feature is designed to put your Retention Policy on “pause” for a mailbox. So if the user is gone for an extended period of time, your Retention Policy isn’t going in and clearing out emails before they were even seen. Again, it doesn’t stop a user from deleting emails because Retention Policies don’t actually retain emails.
Key Concepts To Know About Retention Policies
- Retention Policies do not prohibit a user from removing the email message from his/her mailbox.
- Every mailbox in Exchange Online is assigned a Retention Policy.
- The Default Retention Policy in Exchange Online includes a tag that will move emails to the archive mailbox (if enabled) after two years.
- When a Retention Policy is applied to a mailbox, it also applies to the online archive mailbox (if it exists).
- Retention Policies are processed by a scheduled task that runs every 7 days. This means emails could be kept up to 7 days past the expiration period.
- If a mailbox is less than 10 MB, it is not processed by the scheduled task and thus the Retention Policy does not apply unless you manually run the task (KB2627729).
Armed with the above knowledge, you’ll avoid much of the confusion around Retention Policies. That said, there are a few more areas worthy of discussion.
The Corporate Retention Policy You Can’t Implement
The most common issue I see is when a corporate retention policy is handed down by a legal department with no input on the technical capabilities of Exchange. A policy will be written and approved that says something like “emails cannot be kept in the Inbox” or “email cannot be kept on the system” for period of time. Then we dive into lengthy discussions around what exactly is the “Inbox” or “system”. Is it the folder called “Inbox” within a mailbox or are we talking about the entire mailbox itself. If it’s just the Inbox folder, what are we really accomplishing from a legal standpoint if a user can keep the email somewhere else within the same mailbox? In short, make sure your messaging administrators have some input into your corporate retention policy.
“Because We’ve Always Done It That Way…”
The next mistake is trying to carryover existing procedures to the cloud without reevaluating them. Some pretty important aspects change when you move to the cloud, top on that list is that you’re really not paying for storage anymore. Okay, you’re paying for it but your Office 365 mailbox costs are the same whether your mailbox is 50 MB or 50 GB. In the on-premises world, storage is relatively expensive so in some instances a corporate retention policy started with disk space in mind and not necessary legal. So while there is something to be said for maintaining a “tidy” mailbox, you need to be reasonable or your users will engineer their own solutions. Any time I work with a company that has an aggressive retention policy or terribly small mailbox quotas, I also find that they have GBs if not TBs of PSTs scattered across their network.
Bundled with the above, some organizations previously tried to keep the primary mailbox size small so that the OST created locally by Outlook was manageable. So they deleted emails after X number of days or moved them into the online archive mailbox which was not cached. Starting with Outlook 2013, we no longer cache the entire mailbox which should eliminate the need for this practice. While you’re at it, consider whether you even need to use the online archive anymore: “Is the Archive Mailbox Still Relevant?”
- Understand what Retention Policies are and aren’t
- Retention Policies on their own won’t stop a user from deleting an email
- Use “Litigation Hold” or “In-Place Hold” in combination with Retention Policies if necessary
- Develop a corporate retention policy that makes sense from a legal and technical standpoint
- When moving to the cloud, take the time to reevaluate the intent around your corporate retention policy
Did you find this article helpful?
Leave a comment below or follow me on Twitter (@JoePalarchio) for additional posts and information on Office 365.
Looking to do some more reading on Office 365?
Catch up on my past articles here: Joe Palarchio.