Exchange Retention and Communication Compliance Updates

While we are eagerly awaiting the usual storm of announcements during Ignite week, some minor but essential releases have been completed over the past few weeks. So, let’s spend the next few minutes covering them in some detail.

Exchange Online support for “when labeled” retention

First, let’s briefly talk about the feature announced as part of Message Center post MC216379, namely the fact that Exchange Online now supports retention based on the date the label was stamped on an item.

Traditionally, Exchange’s retention policies have always acted based on the date the item was created or received, with some exceptions as detailed in the official documentation. When Office 365 introduced the new-style retention labels/policies, they offered some novel options, such as the ability to calculate the retention age based on the date the item was last modified or the label was stamped on it. A more advanced option that allowed organizations to configure event-based retention was released later on. Up until now, however, Exchange Online only supported the “traditional” when created approach.

In June, Microsoft announced that they’ve started rolling out an update through the service to allow this additional retention option to work against items stored in Exchange Online mailboxes. To make this possible, the Managed Folder Assistant has been patched to process items with the “stamp date” in mind.

Therefore, admins need to complete no additional actions to enable this functionality. However, you can verify that it’s working as expected by creating a retention label with the when it was labeled setting, then check whether the corresponding items are retained or deleted within the expected timeframe, based on the date the label was stamped on them. Don’t forget that the MFA in Exchange Online runs on a seven-day work cycle, so you can expect some delay here.

So how do we go about checking this new functionality? First, head over to the Security and Compliance Center or the new Compliance Center and create a retention label when it was labeled option configured, as shown on the screenshot below.

Next, publish the policy to some or all mailboxes and wait for the complete distribution process. Then you have to wait some more for Exchange’s Managed Folder Assistant to reprocess the mailbox and make the new labels/tags available. As those are “new style” retention tags, you will not find them under OWA -> Options -> Mail -> Retention policies. Nevertheless, they will become available once the mailbox has been processed.

When this happens, you will see the newly created Exchange when applied tag available in the right-click menu in OWA and/or Outlook. All you need to do then is to assign the tag to some item and wait for it to be processed. Since we want to test the when it was labeled setting, it makes sense to tag an older item with it, such for which the when created scenario would cause the item to expire immediately. If the new label works as expected, the item should remain available for three days after being tagged, give or take. Of course, you can also tag some other items to use as a control group. In my scenario, three different items were stamped with the Exchange when applied tag/label, one received (created) a minute ago, one created a week ago, and one even older.

Even though I’m running a somewhat older version of Outlook (semi-annual targeted channel, so version 2002 at the time of writing this post), the new label and corresponding expiration period are displayed correctly in the client, as shown on the screenshot below (left-hand side). OWA might not reflect the expiry date correctly initially (right-hand side). Even though the correct label information is displayed on the info tip (top of the message screen), the expiration date is shown as Never, which should not be the case given the label is configured with three-day retention period. After a relog or two, the correct date is eventually displayed.

As expected, after the retention period has expired, the three tagged messages were deleted and are currently residing in the RecoverableItems subtree (see screenshot below). The items were received (created) at different times, so their “creation” dates differ, and if we were using the old-style labels/tags, they would have been removed at different times. Since the newly created label is configured with the “when labeled” setting though, and all items were stamped at the same time, they were all processed at the same time too, which is precisely the behavior we would expect.

In a nutshell, this is how the recently introduced new option for retention labels work in Exchange Online. While this might seem like a minor change and very straightforward to implement, the important thing to note here is that Microsoft is bridging the gap between how different workloads handle retention labels, and we are now one step closer to a truly “unified” retention experience.

New Communication Compliance features

The other exciting news we’ll cover is around a few recent releases, either as previews or in GA, within the Communication compliance feature set. Let’s start with the newly introduced granular roles. Back when the Communication Compliance solution was intially launched, granting access to it was a somewhat convoluted process, as it required access to multiple different roles, which at the time were not combined into any of the default Role Groups. Microsoft has addressed this as part of Roadmap item #61068, which just finished rolling out across the service.

While we’d expect the new roles (and role groups) to be available from within the Compliance Center, where the Communication Compliance solution lives, this is not the case. Even two years after the launch of the new standalone Compliance and Security portals, the experience within those remains very limited when it comes to managing permissions, so for any permission-related tasks, you should head to the good old Security and Compliance Center.

On-Demand Webinar: Introducing Certificate-Based for Exchange Online PowerShell

Once there, you will find a total of five Role Groups related to Communication Compliance, as showcased on the screenshot below. Each of these Role Groups contains one or more Roles, correlating to the different tasks you can perform as part of the feature, with the Communication Compliance Role Group having the widest set of permissions assigned.

The set of individual roles are depicted below. Exploring them via PowerShell has the added benefit of surfacing their descriptions, which the devs have neglected to expose in the UI. Apart from the roles shown below, the Data Classification Feedback Provider role, used to provide feedback to the trainable classifiers, is added as part of the Communication Compliance Admins (shown only as Communication Compliance in the UI) Role Group.

Thanks to the new granular roles, we now have an easier separation between investigators (who can see the full message content), analysts (can only see metadata), viewers (access to reports only) and so on. You can find additional notes about the new roles and recommendations of which role to use to find scenarios in the official documentation.

Apart from the role improvements mentioned above, we now can anonymize user names within policy matches. You can toggle the corresponding setting by navigating to the Communication Compliance tab, hitting the Communication Compliance settings button on top, and landing on the Privacy page. The configuration itself is self-explanatory, as shown below:

Another recently launched improvement is the ability to detect repeated behavior over time, as detailed in Roadmap item #61067. Yet another useful feature is the ability to detect adult, racy and gory content as part of images exchanged between participants (Roadmap item #64189). Some caveats apply: the image must be between 50KB and 4MB in size, its dimensions must be greater than 50×50 pixels, and must be either a JPEG, GIF, BMP or PNG format.

The last feature we want to mention is the ability to Remove Teams messages (Roadmap item #66100) and replace them with a generic policy tip, indicating a violation. This functionality applies to Teams chats and channel messages, including those sent to private channels.

So how about testing all these? After updating my policies to include the new adult/racy/gory classifiers, I added some NSFW content in private chat and a team. The good news is that two out of the three images I inserted were flagged as violations, which is a good outcome, considering I didn’t bother to check whether they are within the accepted ranges for size/dimensions. The bad news is that the review experience currently has some issues and makes it impossible to see what content the  message was flagged for.

Not only the built-in viewer failed to display the images, but downloading the original resulted in only getting a zip file with a single summary.txt item, which contains just the below error:

Doc_Num              Doc_ID   Custodian              SubjectOrTitle       File_Name             File_Type               Error_Message

1              9543875d71744ef4a42f2cc609ff466dd0dbff433771a0b39eaffb08569076e9                      0-weu-d1-ea6ae215cd9093dabf2e5fd6e6d1c9f4.jpg                    jpg          The remote server returned an error: (404) Not Found.

This issue seems to be around the review UI, opening the underlying Supervisory mailbox in OWA, and reviewing the content there works as expected. Hopefully, the observed behavior was a temporary fluke or the result of an incomplete feature rollout.

On the positive side, the user was flagged immediately as a repeat offender, and the Remove messages from Teams functionality executed immediately and flawlessly. The screenshot below shows the experience of removing the messages via the Review UI and what the end user sees within the Teams client.

In summary, we’ve received some useful improvements to the Communication Compliance solution, both in terms of making sure the right people can see just the correct data and the overall review experience.