Anyone out there remember “BaseFolderOnly”? If that term means anything to you, it may elicit feelings of rage and frustration. For those of you who may not recognize this term, please allow me to explain.
When Microsoft debuted Exchange 2007, it introduced new message retention management tools, now commonly referred to as MRM 1.0. Initially, MRM 1.0 diverged from its predecessor (“Mailbox Manager” in Exchange 2003) in that policies enacted upon folders would be propagated to all subfolders. This meant that, for example, a Managed Content Setting placed on a user’s Inbox that resulted in items deleting 30 days after receipt, would also be placed on any folders that existed beneath the Inbox, and would result in the deletion of messages contained therein. Upon the release of Exchange 2007 SP1 RU5, Microsoft enabled the BaseFolderOnly option, which allowed for the exclusion of any subfolders from the policies being applied to its parent folder.
Fast forward to Exchange 2010, and Microsoft again revamped Message Retention Management with MRM 2.0. In this toolset, Managed Folders and Managed Content Settings were replaced with Retention Policy Tags and Retention Policies. Gone, along with Managed Folders, was the ability for an organization to deploy standardized folders (outside of the Exchange default folders) to all or a subset of users. Also gone, much to the frustration of Exchange administrators everywhere, was the BaseFolderOnly option. This means that any Retention Policy applied to a folder will be enacted against each subfolder that exists beneath it. To add to the confusion, Microsoft made both MRM 1.0 and MRM 2.0 available as options in Exchange 2010, meaning that two MRM technologies, incompatible with each other and with conflicting feature sets, existed side by side on the same platform. MRM 1.0 was dropped entirely for Exchange 2013, leaving MRM 2.0 as the only option, and eliminating altogether the availability of the BaseFolderOnly option.
So that’s it, right? If I want BaseFolderOnly functionality, I am either out of luck or confined to MRM 1.0 and Exchange 2010 until Microsoft brings back the option in some future version of MRM, which may or may not happen… Luckily, the answer is no. Microsoft has provided a means for you, with a little coding skill, to do things the way you want.
Exchange Web Services
Exchange Web Services (EWS) is an API provided by Microsoft that allows you to code applications to communicate with Exchange and work with email messages, calendar items, contacts, etc. The implications of this are that you can write code to augment or supplant many of Microsoft’s native tools. Using the MRM discussion as a backdrop, here are two examples of how writing some code can enable you to get around some of the limitations in the native MRM 2.0 tools.
Custom Folder Creation:
As mentioned above, MRM 2.0 does away with the ability to define custom folders for a set of users. So let’s say that you have a team of 50 users and you want all 50 of those users to have a folder called Litigation in their mailbox. Using PowerShell or your favorite .Net language (I’m partial to C#) you can easily run some code to create such a folder at the root level of a user’s mailbox. The code will bind to the user’s mailbox, bind to the root of the mailbox folder structure, and use the “New folder” method to create a folder called litigation.
Custom retention:
Let’s say that you want to delete all items older than 30 days from all user mailboxes. This is easily achievable with Exchange’s native retention policies. Simply create a Default Policy Tag to delete items older than 30 days, add it to a Retention Policy, and deploy that policy to all users.
Now let’s add a wrinkle and say that we want all messages in all subfolders to be excluded from this policy (exactly what the BaseFolderOnly option used to do). In this case we can bind to the user’s mailbox and enumerate all folders at the mailbox root. This will return all of the default folders, as well as any additional folders created at the root level. After the list of folders is generated, the program will filter each folder for mail items that fall between the current date and the current date minus thirty days, and delete each one, ignoring all subfolders and any messages they contain. You can even elect to move the items to the Deleted Items folder instead of deleting them (something else that is not a native option in MRM 2.0).
These two examples just scratch the surface of what is possible. Other possible applications might include:
- Programmatically delete specific calendar entries
- Monitor calendar slots to build availability reports
- Programmatically move all subfolders to the root folder level
- Enable users’ Out Of Office automatically based on a trigger from another application
Again, the possibilities are vast.
As with anything this powerful, there are some considerations that need attention. First, in order to affect these type of changes across numerous mailboxes, elevated permissions will often be required, up to and including “Application Impersonation.” This is not necessarily a showstopper, but it is important to understand which accounts have this level of privilege and who has access to the account.
Second, while coding against the EWS API is very user friendly, especially if you have .Net programming experience, it is not something that should be undertaken lightly. A few lines of bad code could have drastic repercussions on a production environment. Code should be tested extensively in an isolated lab environment, and only once performance and data integrity have been thoroughly vetted should any code be slowly rolled out to production. I have seen bad EWS code wreak havoc on a production environment because the programmers didn’t understand the impact that it would have on resource utilization.
Also, take care to document all code, especially if it is something that is slated for long-term use. There is nothing worse than depending on a custom application only to find that the person who wrote it is nowhere to be found and that you are unable to make adjustments to your environment out of fear that the application will stop working.
Finally, understand that when you supplant native functionality of a product, you may not be entitled to all the bells and whistles that you would ordinarily get. For example, creating your own message retention management code may get you back the BaseFolderOnly functionality, but you will be sacrificing the message expiration notifications that appear when Microsoft tags a message for deletion. Like anything else, it’s all about balancing your needs.