Despite all the new features that Microsoft has introduced around Retention Policies and Archiving, some clients that I work with still long for the day of “Managed Folders”.
The “Managed Folders” feature left us with Exchange 2010 and the replacement, “Retention Policies” and “Retention Tags”, can be a difficult to adopt for some organizations.
In many cases, I’m working with clients that were previously allowing users to “archive” emails to PSTs so the users are familiar with a “drag and drop” approach to storing away messages. Tagging individual emails with a “Personal Tag” and leaving it in place can be a training struggle that the organization is not ready to take on.
Below is a script I developed for recreating some of the “Managed Folders” functionality that existed in earlier versions of Exchange.
The Use Case
This is by no means a perfect solution, ideally your organization should embrace Retention Policies and Retention Tags. However, there are times where the textbook “right” solution is not the best fit for an organization and this can get you somewhere in the middle. At a high level, we’re basically talking about automating the creation of a folder in a user’s mailbox and assigning it a Personal Tag that does not delete the folder contents.
Here are a couple of use cases:
If your users were previously allowed to use PSTs for “archiving” and you’ve rightly decided to steer away from that, this might be for you. By creating a folder and assigning a Personal Tag, you can give users a place to “drag and drop” emails in a folder protected from your Default Retention Policy tag. So you can have a policy to only keep emails for 3 years but allow users to keep records longer in the protected folder.
Import of Legacy Data
Perhaps you’ve rounded up all those PSTs and have decided to ingest them into you user’s mailbox via Microsoft’s PST Import Service. The online archive mailbox would be a good choice here as that mailbox is not cached by Outlook but if you’re not using archive mailboxes, the data is going into the primary mailbox. Another reason the archive mailbox may not be the best target is if you have Retention Policies in place to delete after a certain period of time. The Retention Policy applies to both the primary mailbox and the online archive mailbox so you wouldn’t want to ingest all the data and then have it purged out based on it’s age. Providing users with a folder for their ingested data that is protected with a Personal Tag allows you to go forward with good practices and apply more strict policies on the imported data in the future.
Some of the code in this script was inspired by examples from Glen Scales. That should be the standard disclaimer on all things related to EWS as any research in this space seems to lead back to Glen’s site.
This script uses version 2.2 of the EWS Managed API. If you don’t have it installed, you can download it from Microsoft: Microsoft Exchange Web Services Managed API 2.2. The API should install in a default folder of “C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll”, if you install it in a different location you will want to modify the script or use the command line parameter to specify the alternate location.
You will also need an account that is setup for Impersonation. If you don’t have an account with this role, you can easily set it up with these instructions: “How To: Configure Impersonation“.
Using The Script
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.
The script takes up to seven command line switches although you can specify as few as three. The parameters are as follows:
The SMTP address for the mailbox that you want to populate.
Name of the folder to create.
Name of the personal tag to assign to the folder.
If specified as $True, Autodiscover is used to determine the EWS endpoint. Default value is $True.
EWS endpoint for target mailbox. Default value is to use Office 365 if not using Autodiscover.
Location of EWS API. Default path is “C:\Program Files\Microsoft\Exchange\Web Services\2.2\Microsoft.Exchange.WebServices.dll”.
Exchange version to be used by EWS. Default is “Exchange2013_SP1” and likely does not need to be changed unless you’re using an earlier version of Exchange. Acceptable options are documented at “EWS schema versions in Exchange“.
So using the following would create a folder called “Archived Emails” in the mailbox and assign it a Personal Tag labeled “Never Delete”:
.\Create-ManagedFolder.ps1 -TargetMailbox firstname.lastname@example.org -FolderName "Archived Emails" -RetentionTag "Never Delete"
When executing the script, you’ll be prompted for the credentials of the account that has the Impersonation role.
Your user, or entire organization, now has a folder where they can “drag and drop” emails so they are protected from a Default Policy Tag that may archive or delete items.
It should be noted that the user, as the owner of the mailbox, can still manage the folder you create including changing the assigned Personal Tag or even deleting the folder. Also, during creation of the folder, if the folder is found to exist, the script will just log a message to the console and not touch the existing folder.
The script for this post can be found in the Microsoft Script Center at the following link: Create-ManagedFolder.ps1
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.