Exchange Online Managed Folder Assistant and the 7 Day Limit

With Exchange on prem, there is a nice feature called the Managed Folder Assistant that runs against mailboxes to check whether or not the messages inside them adhere to the retention policy that has been applied to the mailbox, and makes the necessary changes if it does not. This can include moving old emails to an archive, or deleting them entirely.

In Exchange Online, the schedule is set to run every 7 days. According to Microsoft:

The retention policy runs automatically one time every seven days for mailboxes that are larger than 10 MB. –support.microsoft.com

Unfortunately, we cannot make it run any faster than that.

Client Request: Certain Mailboxes Need to Permanently Delete Emails in Deleted Items folder that are older than 1 Day

If you are in Office 365 and utilizing Exchange Online, you may have certain requirements where particular mailboxes need to be more controlled than your typical user mailboxes. This particular requirement needed a shared mailbox to permanently delete all items in the deleted items folder that were older than 1 Day. They needed this to happen for compliance reasons. You can certainly configure a policy for that in Office 365, but if the Managed Folder Assistant in Exchange Online only runs once every 7 days, then you are in trouble.

Solution #1: Start-ManagedFolderAssistant

There is one way to manually force it to run through PowerShell and that is to run:

Where <mailbox> is the primary SMTP address of the mailbox needing the policy run against. That’s easy enough. This client had an Exchange Hybrid Server configured in their environment, so I wrote a simple script that connects to Exchange Online through PowerShell and run the command for the required mailboxes. Done! Everything is working as expected….

Problems Arise

How could we possibly have a problem with one command?! Well, about two months later, we had an issue where the mailboxes in question were not adhering to their retention policy. I open up Task Scheduler and check out the job I configured. It says that it has been running correctly and it ran successfully less than 24 hours ago. I decide to connect to Exchange Online through PowerShell myself and run the command. It runs without error, and I check the mailbox, but it still is not meeting the retention policy I had placed on it. What is the problem?

The Answer

After opening a Cloud Partner case with Microsoft, turns out we were being throttled by Microsoft. The environment is not built to have that command run against it constantly on so many mailboxes. That is why the 7 day limit is in place. If you could imagine all their Office 365 Exchange Online mailboxes running the Managed Folder Assistant every 24 hours, there would be a huge overhead on the servers that just is not worth it to Microsoft. I understand their answer, but that does not mean I have to like it. Plus, this is a requirement for the client. Therefore, I have two options for moving forward:

  1. Get Managed Folder Assistant to work 
  2. Find Another way to achieve this retention policy
  3. Have someone log into the mailbox manually every day and clean it up

Option #3 was already in effect since the Managed Folder Assistant stopped working, and they were not happy about it. So, I went back and tried to find another way to accomplish this compliance requirement.

Solution #2: Using the EWS API

I figured instead of trying to rely on the Managed Folder Assistant, I would utilize the EWS API 2.1 on the on prem Exchange Server that was already in the environment.

Prerequisites

To accomplish this, you do need two things in particular:

  1. An account in Office 365 that has impersonation rights on the mailbox(es) you are running the script against
  2. The EWS API 2.1 installed on the server you plan to configure your script on.

Connect to Office 365

I had to store my creds for the account in Office 365 account to automatically connect to Exchange Online via PowerShell, so I choose to use the convertto-securestring command on a text document I made. Not the most secure way in the world, but I locked it down as tightly as possible. This portion makes the connection to Exchange Online.

Load the EWS API

I chose to load the DLLs into a variable just so there was nothing to output in the script. Simple and easy.

Set the Variables

This is where things get messy. I wanted to make sure the script was created in such a way that future Retention Policies could easily be added to this script to achieve the same functionality across the board. In this section, I declared as many variables as I could before the for loop below.

  • $today – this gets the date from 24 hours previous to when the script was run
  • $MailboxesPolicy – Gets all the mailboxes within a defined policy.
  • $service – gets the Exchange Service
  • $deletedFolder – gets the system folder called Deleted Items. This is one that is in every Exchange mailbox
  • $fvFolderView – Initializes a new instance of the FolderView class
  • $SfSearchFilterDeleted – creates a search filter for the DeletedItems
  • $ivItemView – Initializes a new instance of the ItemView class by using 1000 pages

Search and Delete the Mailboxes

Here’s where the real work is done. The foreach loop goes through each mailbox, searches for a message that is older than 24 hours and performs a HardDelete on it.

  • $folderId – sets the FolderID for a well known folder and for this we are going at the root.
  • $iUserID – this makes the connection to the mailbox in question.
  • $findFolderResultsDeleted – This is the search that uses the variables that we defined above
  • $fiDeletedItems – creates a variable of the items in the $findFolderResultsDeleted variable that we can then use to parse through and delete them all if they are older than 24 hours.

The Final Result

Once we put it all together, we have the script below that:

  1. Connects to Office 365 from the Hybrid Exchange Server
  2. Grabs all the mailboxes with a particular Retention Policy applied
  3. Sets the appropriate search variables that the EWS API will use
  4. Connects to each mailbox
  5. Searches through the Deleted Items folder and removes anything that is older than one day

Final Thoughts

With any PowerShell script, you need to test, test again, and finally TEST. The HardDelete this particular script performs means there is no recovery for you. You need to make sure everything is functioning as intended.

What makes the script easier than one that would go through a specific folder is the fact that we are only looking at a WellKnownFolderID, in this case the Deleted Items folder. If we were to try to achieve this on a specific user created folder, it would require more work to bind to that particular folder.

Hopefully Microsoft will get to the point where they can allow for retention policies to have retention tags that are less than 7 days and actually work. Time will tell!

Leave a Reply

Your email address will not be published. Required fields are marked *