New Purview eDiscovery Due “by end of 2024”

eDiscovery is probably not where most Microsoft 365 tenant administrators spend a lot of time. Running eDiscovery cases is quite a specialized task. Often, large enterprises have dedicated compliance teams to handle finding, refining, analyzing, and understanding the material unearthed during eDiscovery together with liaison with outside legal and other expertise.

Starting with Exchange 2010, Microsoft recognized that eDiscovery was a necessity. SharePoint Server had its own eDiscovery center, and these elements moved into Office 365. In concert with their own work, Microsoft bought Equivio, a specialized eDiscovery company, in January 2015 to acquire the technology that became the eDiscovery premium solution.

Over the last few years, Microsoft has steadily added to the feature set of the eDiscovery premium solution while leaving the eDiscovery standard and content search solutions relatively unchanged. The last makeover that content search received was in 2021, and it wasn’t very successful. I thought it was slow and unwieldy. Things have improved since, but content searches have never been a great example of snappy performance and functionality, even if some good changes arrived, like the KQL query editor in 2022. (Microsoft has now renamed the keyword-based query lanuage to be KeyQL to differentiate it from the Kusto Query Language used with products like Sentinel).

Time marches on, and Microsoft has decided to revamp eDiscovery. In an August 12, 2024,announcement, Microsoft laid out its plans for the next generation of eDiscovery. The software is available in preview, but only in the new Microsoft Purview portal.

The new portal handles both Purview compliance and data governance solutions. Microsoft plans to retire the current Purview compliance portal by the end of 2024 (Figure 1). Whether that date is achieved is quite another matter. As reported below, there’s work to be done to perfect the new portal before retirement is possible.

Big Changes in the New Purview eDiscovery

Apart from a refreshed UI, the big changes include:

Rationalization of eDiscovery into a single UI. Today, Purview includes content searches, eDiscovery standard, and eDiscovery premium, each with their own UI and quirks. In the new portal, a single eDiscovery solution covers everything, with licensing dictating the functionality revealed to users. If you have an E5 license, you get premium eDiscovery with all its bells and whistles. If you have E3, you’ll get standard eDiscovery.

Better data source management: Microsoft 365 data sources span many different types of information. In the past, eDiscovery managers picked individual mailboxes, sites, and OneDrive accounts to search. A new data source picker integrates all sources

Support for sensitivity labels and sensitive information types within queries: The query builder supports looking for documents and messages that contain sensitive information types (SITs, as used by DLP and other Purview solutions) or protected by sensitivity labels. Overall, the query builder is much better than before (Figure 2).

The output of queries is handled differently too. Statistics are presented after a query runs (Figure 3), and the ability to test a sample set to determine if the query finds the kind of items that you’re looking for still exists.

Exporting query results doesn’t require downloading an app. Everything is taken care of by a component called the Process manager that coordinates the retrieval of information from the various sources where the query found hits. Everything is included in a compressed file that includes individual SharePoint files, PSTs for messages found in Exchange mailboxes, and a folder called “LooseFile” that appears to include Copilot for Microsoft 365 chats and meeting recaps.

Not Everything Works in the New Purview eDiscovery

Like any preview, not everything is available in the software available online. For instance, I could not create a query based on sensitivity labels. More frustratingly, I could find no trace of content searches in the new interface, despite Microsoft’s assertion that “users still have access to all existing Content Searches and both Standard and Premium eDiscovery cases on the unified eDiscovery case list page in the Microsoft Purview portal.” Eventually and after originally posting this article, a case called Content Searches appeared at the bottom of the case list. Navigating to the bottom of a case list (which could be very long) isn’t a great way to find content searches and it seems unnecessarily complicated. Perhaps a dedicated button to open content searches would work better?

Many administrators have created content searches in the past to look for data. For instance, you might want to export selective data from an inactive mailbox. In the new eDiscovery, content searches are created as standard eDiscovery cases, a change that Microsoft says improves security control by allowing the addition or removal of users from the case. Given that I have 100+ content searches in one case, I think that the new arrangement overcomplicates matters (how can I impose granular security on any one of the content searches if they’re all lumped together into one case?). It’s an example of how the folks developing the eDiscovery solution have never considered how tenant administrators use content searches in practice.

Interestingly, Microsoft says that the purge action for compliance searches can now remove 100 items at a time from an Exchange mailbox. They mention Teams in the same sentence, but what this really means is that the purge can remove compliance records for Teams from the mailbox that later synchronize with Teams clients to remove the actual messages.

Much More to Discover

Leaving aside the obvious pun, there is lots more to investigate in the new eDiscovery. If you are an eDiscovery professional, you’ll be interested in understanding how investigations work and whether Copilot (Security and Microsoft 365) can help, especially with large review sets. If you’re a tenant administrator, you should make sure that you understand how content searches and exports work. Microsoft has an interactive guide to help, but more importantly, we will update the eDiscovery chapter in the Office 365 for IT Pros eBook once the new software is generally available.

Learn how to exploit eDiscovery and the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Change in Audit Records for Teams Meeting Recordings Since 2021

Three years ago, I wrote about how to use audit records to track the creation of Teams meeting recordings. The idea was to find the audit records created when a Teams meeting recording was uploaded to OneDrive for Business or SharePoint Online.

Time marches on and old blogs rot, as do old PowerShell scripts. Three years ago, Microsoft hadn’t completed the transition from Stream classic to Stream on SharePoint. The migration finished recently and Microsoft has moved to standardize how Teams meeting recordings and transcripts are stored in OneDrive for Business. Of course, OneDrive only holds recordings for personal meetings. Recordings for channel meetings, including Meet Now in the channel, end up in the SharePoint Online site belonging to the host team.

Closing a Compliance Gap

While some might think that I spend endless hours examining audit records, this is a fallacy. I check on an as required basis, which means that I didn’t notice that my script wasn’t working quite so well because the format of the audit records changed. One important change is that the user noted in all the audit records is app@sharepoint, the ubiquitous SharePoint utility account. No trace exists in the audit records about the user who recorded the meeting, as had happened before.

From a compliance perspective, this is a big deal. Audit records exist to track the actions taken by individuals and system processes, and in this case, it seems important to know who initiated a recording.

Unfortunately, there’s nothing in the audit record to indicate who initiated the recording of a channel message, so we’re left with the SharePoint app. Recordings for personal meetings used to end up in the OneDrive account of the user who started the recording (the organizer or a presenter). Some time ago, Microsoft changed this to a more logical arrangement where recordings always go into the meeting organizer’s OneDrive account. The URL of a OneDrive account contains the site URL, like:

https://office365itpros-my.sharepoint.com/personal/jane_ryan_office365itpros_com

Figuring Out the OneDrive Site Owner

It’s easy for a human to read the URL and know that the OneDrive account belongs to Jane.Ryan@office365itpros.com. With time, I could parse the URL to extract the email address, but I went for a simpler (faster) approach. I used the Get-SPOSite cmdlet from the SharePoint Online PowerShell module to fetch the set of OneDrive accounts in the tenant and created a hash table from the site URL and site owner. It’s fast to check the hash table with the site URL taken from an audit record to return the user principal name of the site owner:

$User = $OneDriveHashTable[$AuditData.SiteURL]
If ($null -eq $User) {
   $User = "SharePoint app"
}

Changes in Search-UnifiedAuditLog Too!

Another influence on the output was the change made by Microsoft in summer 2023 to how the Search-UnifiedAuditLog cmdlet works. Microsoft have denied to me that they did anything, but the evidence shows that:

• The SessionCommand parameter must now be set to ReturnLargeSet to force the cmdlet to return more than 120 records.
• Many more duplicate records are returned than before. This necessitates sorting by the unique audit event identifier to remove the duplicates.
• Search-UnifiedAuditLog returns unsorted data. If a sorted set is important to you, make sure that you sort the audit records by creation date.

$Records = $Records | Sort-Object Identity -Unique | Sort-Object {$_.CreationDate -as [datetime]} -Descending

Of course, you can try to run high completeness searches with Search-UnifiedAuditLog, but I have not had good luck with this preview feature.

Figure 1 shows the output from the updated script, which is available from GitHub. Normal service is resumed.

A Reminder to Check Audit Log Analysis Scripts

It would be nice if a script lasted a little longer, but the ongoing change within Microsoft 365 means that PowerShell developers need to keep a wary eye on updates that might affect production scripts. In this instance, the confluence of the Stream migration and the change to the Search-UnifiedAuditLog cmdlet made a mess of a perfectly good script. I guess life is like that sometimes. Maybe now is a good time to check your scripts that use the Search-UnifiedAuditLog cmdlet.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Using Audit Events to Determine Level of Copilot Activity

Updated 9-Apr-2024

In an article reporting how Copilot usage had dropped off after the initial novelty of having a digital assistant, MVP Joe Stocker described how he used ChatGPT to analyze information about Copilot interactions using Copilot for Microsoft 365 audit events retrieved from the unified audit log. It’s an interesting technique that caused me to investigate the information captured for Copilot interactions.

Running an audit search to find Copilot interactions returns the audit events captured when Microsoft 365 apps use Copilot. Outlook is an exception. Neither OWA nor Outlook for Windows capture Copilot audit events when drafting or refining message text or summarizing a message thread. I wasn’t too surprised at this because Microsoft had said that the Monarch client would be the only supported email client for Copilot until recently.

Interestingly, despite Monarch or any other Outlook client failing to log audit events for Copilot interactions, usage data shows up for Copilot for Outlook in the usage reports section of the Microsoft 365 admin center. The usage data does not describe which Outlook client is used. I assume that the lack of audit events for Outlook interactions is an oversight that Microsoft will address soon.

Update: According to message center notification MC773621 (9 Apr 2024), Microsoft plans to ship support for eDiscovery of Copilot interactions in Outlook (all clients) in mid-April. This implies that audit events will become available.

What’s in the Copilot for Microsoft 365 Audit Events

The unified audit log is a terrific resource for Microsoft 365 administrators to learn about what really happens inside a tenant. Audit events have two parts. The first is fixed and is consistent across all workloads. This part contains properties like the record identifier, user identifier, and timestamp. The second part contains the AuditData multi-value property and is under the control of the workload developers. Audit events generated by SharePoint Online are different to those generated by Exchange Online or Teams. The inconsistency in audit content means that it takes time to understand and interpret the information contained in audit events.

Microsoft defines a schema for Copilot audit events. Regretfully, the formatting of the information written into the AuditData property is inconsistent across the different clients. Some differences are expected because of the variation in content processed by Copilot, but the inconsistencies make it more difficult to understand and analyze what happened than it should be.

Adjusting Audit Search Results for Accuracy

When reviewing audit events generated for Copilot interactions, the fundamental principle is that every prompt processed by Copilot results in an audit event. For instance, if a user asks Copilot for Microsoft Chat a question and follows up with a couple of clarifications, the audit log ingests three audit events. The overall total of Copilot interaction audit events is therefore not the total of discrete user conversations with Copilot. Rather, it is the count of Copilot prompts.

It’s also important to remove duplicates of audit events from the set returned by an audit search. To improve the accuracy of audit searches, Microsoft is introducing a high completeness mode for the Search-UnifiedAuditLog cmdlet. If you don’t use a high completeness search (which takes much longer to complete), make sure to remove duplicates before analyzing the search results. I usually sort the audit search results by unique values in the identity property to remove duplicates. The Purview audit search feature does the same when it downloads audit search results.

After some trial and error, I created a PowerShell script to extract Copilot audit events from the unified audit log and parse the information contained in the AuditData property. An example of the output is shown in Figure 1.

You can download the script I used to find and analyze Copilot for Microsoft 365 audit events from GitHub.

Using Copilot for Excel to Analyze Audit Events

Given that we’re exploring Copilot for Microsoft 365, it made sense to try to use Copilot for Excel to interpret the results. Copilot for Excel can only work with tables and the workbooks must be enabled for AutoSave. In other words, the workbooks must be stored in OneDrive for Business or SharePoint Online. I used the ImportExcel PowerShell module to generate a worksheet with a table of audit events with the following command:

$Report | Export-Excel -Path c:\Temp\Copilot.xlsx -WorksheetName "Copilot Interactions" -Title "Copilot for Microsoft 365 Interactions" -TitleBold -TableName "CopilotEvents"

Figure 2 shows some of the analysis generated by Copilot for Excel. It’s important to say that Copilot for Excel is still in preview, which accounts for the difficulties reported by many users when prompting Copilot for Excel to do something simple, like create a chart.

Some Gaps in Copilot Audit Coverage

Microsoft touts the data security and compliance coverage for Copilot in Purview solutions like auditing. Not capturing audit events for Outlook clients seems like a big gap that must be filled ASAP. Improving the consistency of the information included in the audit events to make it easier to understand and use the data. But I have been waiting for various Microsoft development groups to improve their audit events since 2016 and I suspect that I’ll be waiting before I see better Copilot events.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

High Completeness Audit Log Searches Improves Search-UnifiedAuditLog Results

Message Center notification MC736435 (published 13 March 2024, Microsoft 365 roadmap item 383741) describes the new HighCompleteness switch for the Search-UnifiedAuditLog cmdlet. The preview for the new switch is rolling out with a goal to making it generally available in mid-April 2024.

Despite an unwillingness to confirm that they had made changes to how the Search-UnifiedAuditLog cmdlet works, there’s no doubt that Microsoft has been active in this space. I suspect that the increasing number of Microsoft 365 workloads that generate audit events made the unified audit log infrastructure creak a little. Forcing administrators to include the SessionCommand ReturnLargeSet parameter in search commands might have been an attempt to ease pressure by outputting unsorted search results.

Making Sure Audit Log Searches are Complete

The announcement for the new high completeness feature contains the interesting statement that “Very large queries aimed at retrieving a large number of audit records are susceptible to timeouts and may miss some results.”

To overcome the problem, the HighCompleteness parameter instructs audit log searches to prioritize completeness over speed by performing a more exhaustive and comprehensive search of the audit log. Because the search is more exact, the performance of high completeness searches is slower than “normal” searches. However, given the focus on “very large queries,” the difference between normal and high completeness searches is acceptable if you’re sure that all matching audit records are found.

High Completeness Audit Log Searches Can Retrieve Lots of Data

Until now, the Search-UnifiedAuditLog cmdlet has been limited to returning a maximum of 50,000 records. This sounds a lot, but it’s not for large tenants where tens of thousands of users take actions that result in audit records. To fetch 50,000 records, the cmdlet must include SessionCommand ReturnLargeSet in its parameters.

To test what a high completeness audit log search can do, I ran this command:

[array]$Data = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-100) -EndDate (Get-Date).AddDays(1) -HighCompleteness -formatted -verbose

You don’t need to pass the SessionCommand parameter for high completeness audit log searches. The ResultSize parameter is supported to limit the number of audit records returned by a search. Figure 1 shows that the search returned 119,507 records in just under 17 minutes.

The results are unsorted, so to sort the records into date order, I ran:

$Data = $Data | Sort {$_.CreationDate -as [datetime]}

It seems like Microsoft limits the number of high completeness searches that an administrator can run. After running five over 20 minutes or so, my next attempt resulted in:

WARNING: Failed to process request via HighCompleteness flag, returning HttpRequestException. Exception: TooManyRequests , Reason: Too many requests. Please try after some time..

Waiting ten minutes to resubmit the search resolved the issue. During my tests, I also experienced a few 500 ‘internal server errors’ when running high completeness searches. Occasionally, a search failed with an error like:

WARNING: Failed to process request via HighCompleteness flag, returning HttpRequestException. Exception: Status: OK , Reason: The search request did not finish in time via HighCompleteness flag, returning. Execution time(seconds) :782.

These are examples of errors that are expected during previews of new functionality and I’m sure that Microsoft will resolve the underlying problems (and make the error messages more meaningful) before general availability.

Comparing Normal and High Completeness Audit Log Searches

To compare the time required to run normal and high completeness searches, I ran a test to retrieve all audit records for a user. The normal search took 11.5 seconds:

[array]$Data3 = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-180) -EndDate (Get-Date).AddDays(1)  -formatted -UserIds Sean.Landy@office365itpros.com -ResultSize 5000 -SessionCommand ReturnLargeSet

The high completeness search took 4 minutes 22 seconds:

[array]$Data2 = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-180) -EndDate (Get-Date).AddDays(1) -HighCompleteness -formatted -UserIds Sean.Landy@office365itpros.com

The normal search returned 950 records; the high completeness search returned 704. After sorting both sets by the creation date, the two sets had the same first and last record in the set. It seems that the difference is accounted for by duplicate records included in the “normal” set.

For instance, a MailItemsAccessed event appeared three times in the “normal” set. To check the theory, I created an array and used a ForEach-Object loop to populate properties in the array from the audit records, including the Id property in the AuditData multi-value property. I then sorted the array to find unique values of Id and ended up with 704 records, the same as returned by the high completeness search. Here’s the code I used:

$OutputReport = [System.Collections.Generic.List[Object]]::new()
ForEach ($Rec in $Data3) {
    $AuditData = $Rec.AuditData | ConvertFrom-JSON
    $ReportLine = [PSCustomObject][Ordered]@{
         UserPrincipalName   = $Rec.UserIds
         Timestamp           = $Rec.CreationDate
         Operation           = $Rec.Operations
         Id                  = $AuditData.Id
     } 
     $OutputReport.Add($ReportLine)      
}
$OutputReport.count
950
$O = $OutputReport | Sort-Object Id -Unique
$O.count
704

A New Way to Run Large Audit Log Searches

Administrators run audit log searches to extract information about many different types of activity. When they do, administrators expect Purview to respond with accurate and complete results. It seems that this hasn’t been the case in the past and that the likelihood of missing records grows as the number of audit records found by a query increases. That’s not good and I was surprised to find so many duplicates.

Based on what I see so far, high completeness searches do a good job of finding large quantities of audit records reasonably quickly. Being sure that 120,000 records are accurate and represent the total available set is a different matter. Checking the data fetched by more precise queries indicate that high completeness searches generate accurate results. This preview feature is worth investigating.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

Future Focused on Unified Search Log

A January 26 post in the Microsoft Technical Community announced that Microsoft intends to retire the old cmdlets that report Exchange mailbox and administrative audit events on April 30, 2024. The cmdlets involved are Search-AdminAuditLog, Search-MailboxAuditLog, New-AdminAuditLogSearch, and New-MailboxAuditLogSearch. Microsoft says that the replacement is the Search-UnifiedAuditLog cmdlet.

Microsoft’s assertion is correct. Unlike their plan to retire the Search-Mailbox cmdlet at the end of March 2024, I think it is a good idea to deprecate the four search cmdlets because they only confuse the Microsoft 365 audit search landscape. The cmdlets appeared in Exchange 2010 as part of the introduction of audit functionality for Exchange Server. Today, the audit events gathered by Exchange Online flow into the unified audit log and there’s no need to interrogate the copies of the audit events retained in user mailboxes. The unified audit log is what is searched using the Audit Log feature in the Purview compliance portal (Figure 1).

It might be the case that some old scripts exist that depend on finding mailbox or admin audit events in Exchange, but it’s relatively easy to convert those scripts to use Search-UnifiedAuditLog.

Until the Search-UnifiedAuditLog Cmdlet Changes Without Warning

At least, it would be if Microsoft didn’t change how the Search-UnifiedAuditLog cmdlet works without warning, which is what they did in late summer 2023. Unannounced and unexplained change allied to slow delivery of commitments to make some important audit events available to Office 365 E3 tenants have shaken my confidence in Search-UnifiedAuditLog recently,

Anything to do with auditing needs to be consistent and precise. As seen with unannounced change, consistency is not something that I associate with the Search-UnifiedAuditLog cmdlet. Precision is often poor too. The group that manages the flow of audit events into the unified audit log insists on consistency for the base properties, such as the timestamp, name of the operation, the user responsible for an action, and so on. Things become far murkier when it comes to the AuditData property, which holds information deemed necessary by a workload to communicate details of an action.

The Mysteries of AuditData

AuditData is a JSON-formatted structure. There’s nothing wrong with that. My objections focus on the arbitrary inclusion of information in the structure. As an example, reporting details of license assignments to Entra ID user accounts is challenging. Entra ID generates audit events, but the content of AuditData is often obscure and defies interpretation. With over 1,600 different audit events flowing into the unified audit log, insisting on coherence and clarity in all events must be like cleaning the mythical Augean stables. But without full and precise information in audit events, the unified audit log loses credibility and becomes less valuable than it could be.

I should say that I regard the unified audit log as an extraordinarily valuable source of information about what actually happens within a Microsoft 365 tenant. All tenant administrators should know how to interrogate the audit log and understand (at least roughly) what the audit events returned by a search mean. Skilled tenant administrators go deeper and use the audit log as a source of understanding for how Microsoft 365 workloads work. Not everyone has the time to master the audit log at this depth, but it’s certainly a good goal to work toward.

Remove Decrepit Cmdlets But Fix Search-UnifiedAuditLog

I have zero problem with Microsoft removing old and decrepit cmdlets from the Exchange Online management module. It’s the right thing to do. I just wish that Microsoft would fix the problems in the Search-UnifiedAuditLog cmdlet before they did anything else. Everyone who works with Microsoft 365 audit data would benefit and it would establish a solid foundation for the future. Which would be nice.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Failure to Update Compliance Search Action Capabilities Flaws Plan

Microsoft can be awfully persistent even when they are just plain wrong. The narrative around the Search-Mailbox cmdlet is a case in point. Microsoft originally announced the deprecation of the cmdlet in July 2020. However, the purported replacement (the purge action for compliance searches) has never worked and Microsoft could not remove Search-Mailbox because it is such a useful administrative cmdlet. Currently, if you run Search-Mailbox, you see the message:

WARNING: WARNING:  On September 1, 2023, the Search-Mailbox cmdlet will no longer be available.  See https://go.microsoft.com/fwlink/?linkid=2113221 to learn more.

Roll forward to January 4, 2024 and the publication of message center notification MC703706, headlined as the retirement post for the Search-Mailbox cmdlet. Or rather, the “Microsoft 365 Purview eDiscovery standard search-mailbox cmdlet.” It rather seems that the Microsoft Purview team has gained responsibility for the cmdlet and decided to progress with the retirement, despite the acknowledgement that Search-Mailbox is “a valuable tool for searching and exporting mailbox data for legal and compliance purposes.” Retirement is now scheduled to begin on March 1, 2024 and the cmdlet will disappear from all tenants by late March 2024.

Similar Functionality Promised

Microsoft then goes on to say that they intend moving “to other means of providing similar functionality” without specifying just what the replacement functionality is. MC703706 contains a link to the New-ComplianceSearch cmdlet. I think they mean the New-ComplianceSearchAction cmdlet because that’s how you add a purge action to an existing compliance search to hard- or soft-delete mailbox items (purging of documents or other types of Microsoft 365 items is unsupported).

Testing Mailbox Purges

In the past, I’ve tested the functionality of Search-Mailbox (Figure 1) against compliance search purges. To make sure that I hadn’t missed some developments in this area, I tested again using scripts to remove items from mailboxes. You can download the scripts I used from GitHub (here’s the Search-Mailbox version and here’s the compliance search actions version. Both scripts need a little setup to define the search queries, but the hardest part of testing is finding suitable test data to search for and remove followed by verification of the results. You’ll need to use the MFCMAPI utility to examine deleted items in the Purges folder in Recoverable Items.

Not much if anything has changed since I last spent some time figuring out how to use purge actions. Compliance searches are not fast and applying purge actions to the results of a compliance search isn’t fast either. Admittingly, in large environments, processing purges against a set of known search results that identify the mailboxes holding specific items offers an advantage over the need to open and search each target mailbox. Another factor is the complicated nature of creating a search, running the search, and then running a purge action against the search results. Using Search-Mailbox is simpler, especially when more than 10 items must be removed per mailbox or when you need to exclude items in the ‘dumpster’ (recoverable items). This is not surprising because the comparison is between a purpose-designed cmdlet and an add-on action processing content search results.

Both scripts search the online archive (you can disable archive searching with Search-Mailbox but not with compliance searches). Both hard-delete matching items. The big difference in the required time is because a search action can only remove 10 items per mailbox at a time whereas Search-Mailbox can remove up to 10,000 items from a mailbox. The history of Search-Mailbox in Exchange Server is as a response to the need to remove spam that ended up in user mailboxes, so it’s better able to remove many items. Compliance search actions are not intended as a method to clean up mailboxes.

Search-Mailbox can also copy items between mailboxes, which is not something that compliance search actions support.

Moving Forward

I’m not against Microsoft removing old cmdlets. The nature of Information Technology is that old components are replaced over time. Search-Mailbox only handles Exchange mailboxes and is out of touch with the trend to make compliance functionality work across all Microsoft 365 workloads. But as seen with mailbox retention policies, sometimes it is difficult to replicate workload-specific functionality (like folder-specific retention or move to archive) across all workloads. And compliance search actions can only purge mailbox items, so it’s not as if Microsoft plans to replace Search-Mailbox by workload-independent functionality.

It might make some happy (or check a box in a plan) to eradicate a vestige of Exchange Server from Microsoft 365, but if Microsoft retires Search-Mailbox without delivering comparable functionality in the Purview compliance suite, it will be a loss for customers and compliance administrators alike. I look forward to learning about what Microsoft plans in this space.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Sensitive by Default Blocks External Access Pending DLP Scanning

The ability to mark documents as “sensitive by default” achieved general availability in July 2020. Despite covering the topic in the DLP chapter of the Office 365 for IT Pros eBook, I never paid the feature much attention because sensitivity labels are often a better way to protect confidential material.

Not every tenant deploys sensitivity labels. Sometimes this is because they want to avoid the complications that can come when dealing with encrypted information, such as how to move encrypted documents between tenants during a migration. And sometimes it’s because the work to prepare to deploy and manage sensitivity labels is incomplete and pending completion. These are the kind of circumstances when the sensitive by default control is useful for tenants that have the necessary Office 365 E3 (or above) licenses to use Data Loss Prevention (DLP) policies with SharePoint Online.

The idea is simple. SharePoint Online uses background processes to implement the instructions in DLP to detect sensitive information in documents and take whatever action the policy settings dictate, such as to block sharing. Because DLP processing does not happen immediately for new files uploaded to to SharePoint Online and OneDrive for Business libraries, a short period exists when it’s possible for users to share sensitive data outside the tenant and inadvertently leak data. The sensitive by default control stops this happening by forcing SharePoint Online to consider all files as sensitive until DLP processes their content.

In effect, this means that SharePoint Online blocks external access to documents until DLP scans the contents. If external users, including guest members of a team, attempt to access a document before DLP scans its content, they see a page to tell them that scanning is in progress (Figure 1). After a few minutes, the scan should complete and access is possible.

Implementing Sensitive by Default

To implement the Sensitive by default control, you:

• Implement at least one DLP policy to scan the SharePoint Online sites that store information intended for external access.
• Run the Set-SPOTenant cmdlet in the SharePoint Online PowerShell module to block access to new files. It can take up to 15 minutes before the change is effective. The block applies to all sites in the tenant and you can’t exclude sites from its effect.

Here’s the command to implement the sensitive by default control:

Set-SPOTenant –MarkNewFilesSensitiveByDefault BlockExternalSharing

With the block in place, users can still share documents externally (if not blocked by the tenant’s sharing settings). However, external people with a sharing link cannot access the content until the document is scanned by a DLP policy.

To revert the block, run Set-SPOTenant to allow sharing without waiting for DLP processing:

Set-SPOTenant -MarkNewFilesSensitiveByDefault AllowExternalSharing

DLP Processing for Sensitive by Default

Any DLP policy that has a “contents contains” condition to process information in SharePoint Online sites can perform the check and release the block. Normally, DLP scanning either passes the document for external access (because DLP doesn’t detect a policy violation) or blocks it (because DLP detects some content that violates the policy if shared externally).

The Microsoft documentation for the feature discusses creating a form of “catch-all” DLP policy to cover all SharePoint Online sites and OneDrive for Business accounts in a tenant. The policy contains a rule to check new content for some arbitrary value. As shown in Figure 2, I use a check for the blood test sensitive information type.

It doesn’t matter that DLP is unlikely to detect this data in my tenant. Apart from that, the DLP policy doesn’t perform any action or notify anyone if it matches content. The sole purpose of the policy is to make sure that DLP processes every file uploaded to SharePoint Online and OneDrive for Business. Other DLP policies handle any problems lurking in documents.

Sensitive by Default and Sensitivity Labels

Applying the sensitive by default control is an effective way to stop external sharing from SharePoint Online and OneDrive for Business. However, it’s a broad-brush policy that covers the entire tenant. Using sensitivity labels to restrict access to documents containing important information might be a better approach, especially when auto-label policies are used to find and apply labels to documents at rest. The two approaches are not mutually exclusive and it’s a good idea to use sensitivity labels to control access to an organization’s most confidential information, including documents shared with external guests in Teams.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Replicating the Hold Report Microsoft plans to Introduce in January 2024

On 8 December, Microsoft published message center notification MC696859 to announce the preview of a tenant wide hold report for eDiscovery (Premium). This change is covered by Microsoft 365 roadmap item 93268. Preview will begin in mid-December and is expected to finish by mid-January 2024.

The report includes information about all the hold policies for eDiscovery cases (standard and premium) and will be available under the Reports tab in the eDiscovery Premium section of the Purview compliance portal. Microsoft’s report will cover holds set by eDiscovery standard and premium cases. The report lists all locations that are part of any hold policies within the tenant (whether the hold policy is turned on or off).

There’s no reports available for eDiscovery standard, and that’s likely the reason why Microsoft choose to reveal the report in the eDiscovery premium section.

Creating the Hold Report with PowerShell

I’ve been down the path of reporting compliance policies before and thought that it would be a good idea to replicate the report that Microsoft plans to deliver using PowerShell compliance cmdlets. Once Microsoft releases their version of the hold report, I’ll review what it contains and consider if any changes to the script code are necessary. Some of the information available to Microsoft through internal interfaces might be inaccessible via PowerShell, so some of the features they build into their version might be unique.

The structure of the script is straightforward:

• Connect to the compliance endpoint with Connect-IPPSession.
• Run the Get-ComplianceCase cmdlet to create arrays of standard and premium cases. Deliberately, the script ignores data subject requests (DSRs), which show up as standard eDiscovery cases. If necessary, it would be easy to add these cases to the mix by running Get-ComplianceCase -CaseType DSR.
• A case is a container for the objects (like holds) that combine together to allow investigators to manage eDiscovery cases. The next step is to find the holds, which we do by running the Get-CaseHoldPolicy cmdlet.
• Extract the information about the case holds and report the data.

Premium and standard cases have the same basic structure. The difference between the two is the level of sophistication built on the structure. As an example of what the script does, here’s the processing for standard cases:

$Report = [System.Collections.Generic.List[Object]]::new()
[int]$i = 0
Write-Host "Processing standard cases"
ForEach ($Case in $Cases) {
    $i++
    Write-Host ("Processing case {0} ({1}/{2})" -f $Case.Name, $i, $Cases.Count)
    [array]$CaseHolds = Get-CaseHoldPolicy -Case $Case.Identity -DistributionDetail
    If ($CaseHolds) {
        ForEach ($CaseHold in $CaseHolds) {
            $CaseData = [PSCustomObject][Ordered]@{
                Name            = $CaseHold.Name
                Workload        = $CaseHold.Workload
                Enabled         = $CaseHold.Enabled
                Mode            = $CaseHold.Mode
                Exchange        = $CaseHold.ExchangeLocation
                SharePoint      = $CaseHold.SharePointLocation
                PublicFolders   = $CaseHold.PublicFolderLocation
                LastUpdate      = $Rule.LastStatusUpdateTime
                CaseType        = 'Standard'
            }
            $Report.Add($CaseData)
      }
   }
}

Figure 1 shows the output. As noted above, I might refresh the code when I see what Microsoft delivers.

You can download the script from GitHub. As always, this code is to illustrate a principal rather than being a full solution. It needs better error handling and should generate a report in a more accessible fashion than a CSV file and the Out-GridView cmdlet. The PSWriteHTML module or a simple HTML file might be useful options here.

Navigating Compliance Holds

EDiscovery is one of the better areas of Microsoft Purview when it comes to PowerShell support. I suspect that this is because Exchange Server has supported holds since Exchange 2010. For whatever reason, the cmdlets are available and that’s why we have a hold report, which is nice.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Entra ID Administrative Units and Compliance Roles Limit User Access to Microsoft 365 Audit Log Data

Entra ID administrative units are a premium feature that allows organizations to create partitions within the directory (analogous to organizational units in Active Directory). Microsoft Purview compliance solutions have recently added support for administrative units to restrict access of administrators to compliance activities for certain accounts based on membership of selected administrative units.

Although administrative units can include user accounts, groups, and devices, from a compliance perspective, Exchange Online is only interested in user accounts with mailboxes. Many compliance activities such as data lifecycle management (retention processing) target mailboxes, so it makes sense that Exchange Online should respect the boundaries imposed by sets of accounts listed in administrative units when it’s asked to provide information.

To retrieve details of the user and group objects that are members of administrative units, run the script described in this article.

Exchange Online Cmdlet to Work with Administrative Units

The Exchange Online management module contains the Get-AdministrativeUnit cmdlet. The cmdlets retrieves information about Entra ID administrative units stored in the Exchange Online directory. Exchange Online doesn’t synchronize updates about administrative units and membership immediately and it can take up to ten minutes for synchronization (new administrative units, changes to membership, etc.) to happen. After synchronization, run Get-AdministrativeUnit to view the details of administrative units as known to Exchange Online:

Get-AdministrativeUnit

Name                                   DisplayName
----                                   -----------
0555a6cd-f1eb-4843-ba62-a362db719704   Project Management (Sales) dynamic administrative unit
0ee53a45-bbee-4571-a407-56acc0b944a1   Ireland
112f5e71-b430-4c83-945b-8b665c14ff25   Global HQ dynamic administrative unit
150dccad-f8b8-4e54-9246-89834b8b5a25   Group HQ Users

This output is similar to that of the Get-MgDirectoryAdministrativeUnit from the Microsoft Graph PowerShell SDK:

Get-MgDirectoryAdministrativeUnit | Format-Table Id, DisplayName

There’s no equivalent of the Get-MgBetaAdministrativeUnitMember cmdlet to return a set of members for an administrative unit, but this can be done by running the Get-Recipient cmdlet to resolve a recipient filter based on the distinguished name of the administrative unit object (the copy in the Exchange Online directory rather than Entra ID). For example:

$AUName = (Get-AdministrativeUnit -Identity 'Information Technology dynamic administrative unit').distinguishedName
[array]$AUMembers = Get-Recipient -RecipientPreviewFilter "AdministrativeUnits -eq '$AUName'"
$AUMembers | Format-Table DisplayName, PrimarySmtpAddress, ExternalDirectoryObjectId

DisplayName                      PrimarySmtpAddress                   ExternalDirectoryObjectId
-----------                      ------------------                   -------------------------
Ben Owens (DCPG)               Ben.Owens@office365itpros.com        a3eeaea5-409f-4b89-b039-1bb68276e97d
Andy Ruth (Project Director)   Andy.Ruth@office365itpros.com        fdc6b121-44b8-4262-9ca7-3603a16caa3e

Using a recipient filter might seem convoluted, but it’s no more complicated than the steps required to retrieve membership information for an administrative unit with the Graph SDK:

$AUMembers = Get-MgBetaAdministrativeUnitMember -AdministrativeUnitId (Get-MgDirectoryAdministrativeUnit -Filter "displayName eq 'Information Technology dynamic administrative unit'" ).Id -All
[array]$MemberUsers = $AuMembers.additionalProperties | Where-Object {$_.'@odata.type' -eq "#microsoft.graph.user"}
$Memberusers | ForEach-Object { Write-Host $_.displayName “ “ $_.mail}

Some of this is due to the way that Graph requests return information, and part is due to some SDK foibles. It’s especially annoying in this case that the property names are case sensitive. “displayName” works but “DisplayName” does not.

Connecting Exchange Online and Purview Audit

The Audit Log search feature in the Microsoft Purview compliance portal supports administrative units. In other words, you can assign the Audit Reader compliance role to users to allow them to manage one or more administrative units. Purview Audit searches will limit the records retrieved from the Microsoft 365 audit log to those generated by members of the selected administrative units.

Figure 1 shows the parameters for a new search, which is limited to the United States administrative unit. Administrators can only choose administrative units that they have access to or search for audit events across the entire organization (the previous default).

When the search completes, the audit events are for actions performed by members of the selected administrative unit. The search works by looking at the AssociatedAdminUnits property in audit events. The property stores the identifier of the administrative units a user account is a member of (accounts can belong to multiple administrative units) and is updated for events when the Microsoft 365 audit log ingests data from workloads. You can see the administrative unit information in the details of audit events found by Audit search (Figure 2).

Very importantly, changes made to administrative unit membership do not replicate to previous audit events. For instance, if a user joins the United States administrative unit, none of the audit events captured for previous actions are available to administrators limited to searching for audit events associated with the United States administrative unit.

Limiting Access for the Search-UnifiedAuditLog Cmdlet to the Microsoft 365 Audit Log

The Search-UnifiedAuditLog cmdlet is part of the Exchange Online management PowerShell module. Its purpose is to run audit log searches, but currently the cmdlet does not respect administrative unit restrictions imposed by compliance center roles. This might change in the future.

The workaround is to use Role-Based Access Control (RBAC) to limit the data the cmdlet can process, specifically by creating management role assignments. For instance, to assign the Audit Logs management role to a user, run the New-ManagementRoleAssignment cmdlet and specify the user (alias, display name, external directory object id, or primary SMTP address) and the identifier for the target administrative unit.

New-ManagementRoleAssignment -User Ken.Bowers@office365itpros.com -Role "Audit Logs" -RecipientAdministrativeUnitScope "4d3ae8ee-212b-4be4-965c-8b5111d4488e"

Searches run with the Search-UnifiedAuditLog cmdlet by the user holding the role will now respect the administrative unit limit based on the AssociatedAdminUnits property in audit events. For instance, here’s an extract of an audit record generated for an account that belongs to three administrative units.

],
                 "AssociatedAdminUnits": [
                   "8a703400-7086-4e13-943a-7ed8df9ecd41",
                   "4d3ae8ee-212b-4be4-965c-8b5111d4488e",
                   "150dccad-f8b8-4e54-9246-89834b8b5a25"
                 ]

To resolve the identifiers and check that the correct administrative units are used, extract the data to an array and run the Get-AdministrativeUnit cmdlet against each identifier:

$AdminUnits = ($Records[0].AuditData | Convertfrom-Json).AssociatedAdminUnits
ForEach ($AU in $AdminUnits) { (Get-AdministrativeUnit -Identity $AU).DisplayName }

Group HQ dynamic administrative unit
United States
Group HQ Users

Summarizing Support for Administrative Units in Purview Audit

To summarize, organizations can use administrative units to limit user access to Microsoft 365 audit log data. The limitation depends on the compliance role assigned to the account and the data stamped into audit log records. An Exchange management role assignment is required to apply the same limitation to searches run using the Search-UnifiedAuditLog cmdlet.

Loop Component eDiscovery is Possible Without Being Easy

Following yesterday’s article about using Loop components in Teams channel conversations, I was asked how I felt about how well Loop supports Microsoft 365 compliance solutions. The point is that Microsoft emphasizes the collaboration capabilities of Loop within an organization (but not outside because of the lack of external access) without delivering full support for basic compliance functionality like eDiscovery.

My view is simple. Loop components have been around for two years. In that time, there hasn’t been much change in how these components support compliance. In November 2021, when I wrote about Loop component support for Teams chat, I noted that the compliance records generated for chat messages contained pointers to the Loop files stored in OneDrive for Business. This is enough to find Loop components, but not in the context of the chat.

Loop Component eDiscovery with Content Search

In May 2022, I followed up by examining the topic of eDiscovery for Loop components in more detail and noted that it’s possible to run a content search for a keyword included in a Loop component but can’t open the file from preview. You can download the file and open it in OneDrive for Business, but only after giving the file a .fluid extension. The same is true for the components used in Teams channel conversations. I don’t remember searches ever finding retained copies of previous versions of chat components (stored in the site preservation hold library). This happens for components used in channel conversations (Figure 1).

In all cases, I could open the downloaded copy of a component. OneDrive for Business calls the web version of the Loop app to open the files (Figure 2).

In yesterday’s article, I used a compound message to illustrate Loop components in channel conversations. A compound message includes text and embedded elements, like a Loop component or a Stream video. You’ll notice that the results shown in Figure 1 only list the Loop components. To find the complete message, you must use keywords that are in the message and Loop components (the same or different keywords). You can then see the message posted to the channel (Figure 3).

Downloading Messages With Pointers to the Loop Component

There’s no trace of the Loop component because content search preview only displays text (including links and emojis). But when you download the compliance record and view the resulting message item, you can see the attachments. The loop component is represented as ‘card.html.’ The channel post was an announcement, so the other attachment is the graphic used in the announcement header.

For those wondering why the downloaded compliance record is displayed as an Outlook message, that’s because Teams compliance records are simplified copies of the actual Teams data stored as message items in Exchange Online mailboxes (a group mailbox in this case). Microsoft Search indexes the message items to make them available for eDiscovery. However, Loop components used in channel conversations are indexed separately in SharePoint Online and that’s why the search has two hits: one for the message, and one for the component.

Loop Component eDiscovery Premium

The situation is a little better in Purview eDiscovery Premium. Instead of a simple content search, eDiscovery Premium uses review sets retrieved from a collection of sources. The presentation of information from a review set is more insightful (Figure 5). In this instance, we can see that the content of the card.html attachment reveals that the Loop component is presented in an adaptive card called FluidEmbedCard.

Work to Do to Improve Loop Component eDiscovery

Microsoft is obviously enthused with Loop components. The technology is interesting and does a good job of making collaboration more accessible for users within a single tenant. However, it’s disappointing that eDiscovery of Loop components is still challenging two years after the first introduction of the technology in a Microsoft 365 application. You can certainly find the components, but investigators have too much work to do to knit everything together to create a seamless picture of how people use Loop components in Teams channel conversations.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Analyze Sensitivity Label Policies to See Who Gets What Labels

A question in the Microsoft Technical Community asked about the best method to find which sensitivity label policies are assigned to specific users. Vasil Michev weighed in to recommend using the information recorded by Exchange Online about inplace holds in user mailboxes and the organization configuration. The information includes entries for the policies which publish retention labels and sensitivity labels to users. Exchange Online and its clients use this data to figure out the precise set of labels available to users.

Checking In-Place Holds for Sensitivity Label Policies

As an example, these commands retrieve the in-place hold information applicable to all users from the organization configuration and the identifiers and display names for sensitivity label publishing policies. A match exists for policy 19200b9a-f084-4252-9be0-70dae2fd54d3, so we can say that all users receive the labels published by the General sensitivity policy.

Get-OrganizationConfig | Select-Object -ExpandProperty InPlaceHolds

grpd34273e9a8504c6c965d947f152d13c2:2
mbxf6a1654abdba4712a43c354e28a4d56c:1
mbx95c7ff3a9a344cb49b4116180c9e975a:3
grp95c7ff3a9a344cb49b4116180c9e975a:3
grp85eb38087b2642619b79161788f5b81b:1
grp5d763f9615e8424a8190b49687c65f46:1
grpfcab5f8ef3e74a778c33a744d686b010:1
mbx19200b9af08442529be070dae2fd54d3:1
grpf6a1654abdba4712a43c354e28a4d56c:1
mbxc1e2d6f1785d4bf8a7746a26e58e5f66:1

Get-LabelPolicy | Format-Table Name, Guid

Name                        Guid
----                        ----
Eyes Only Policy            5de1c9f6-ca28-402a-81b7-89177755897b
Black Matter Policy         4f8ff12c-5665-4e45-b7bc-3e9fc1bbc91c
Container Management Labels fac260a8-1bc4-44bd-9735-7ab0072bcfc4
General sensitivity policy  19200b9a-f084-4252-9be0-70dae2fd54d3

However, that’s not the whole story because publishing policies can include per-user exclusions that block those users from being able to use labels published by policies targeted at all users.

Scripting a Solution to Reveal Policies that Publish Labels

Anyway, looking at lists of GUIDs is not a user-friendly way to figure out information about how users gain access to sensitivity labels. A different approach is to analyze the sensitivity label publishing policies to find what labels each policy publishes and the target users to figure out where the labels available to a specific user come from. The code below:

• Defines the user to check.
• Connects to Exchange Online and the compliance endpoint.
• Fetches details of the sensitivity labels defined in the tenant and store them in a hash table to allow the script to resolve the label identifiers stored in policies to label names.
• Fetches details of the sensitivity label publishing policies and sorts them so that the policy with highest priority is processed first.
• For each policy, check if the user is targeted individually (as a named location) or because the policy covers all users.
• Check if the policy excludes the user. Exclusion means that even if the policy covers all users, the specified user cannot see and use the sensitivity labels contained in the policy.
• If the user is within the scope of a policy, the script fetches details of the sensitivity labels published by the policy and resolves the identifiers to display names.
• Outputs the results.

Here’s the code:

If ($Null -eq (Get-ConnectionInformation)) {
    Connect-ExchangeOnline
}
Connect-IPPSSession
$User = "Lotte.Vetler@office365itpros.com"

Write-Host "Finding details of sensitivity labels and policies…"
Write-Host ""
# Get set of sensitivity labels in tenant
[array]$Labels = Get-Label
$LabelsHash = @{}
ForEach ($L in $Labels) { $LabelsHash.add([string]$L.ImmutableId,[string]$L.DisplayName) }

# Get policies in order of importance
[array]$Policies = Get-LabelPolicy | Where-Object {$_.Type -eq 'PublishedSensitivityLabel'} | Sort-Object Priority -Ascending

Clear-Host; Write-Host (“Checking {0} against sensitivity label policies…” -f $User)
Write-Host ""

ForEach ($Policy in $Policies) {
   $UserFound = $False
   [array]$LabelNames = $Null
   If ($User -in $Policy.ExchangeLocation.Name) {
      $UserFound = $True
   }
   If ($Policy.ExchangeLocation.Name -eq "All") {
      $UserFound = $True
   }
   If ($User -in $Policy.ExchangeLocationException.Name) {
       $UserFound = $False
       Write-Host ("User {0} blocked from labels published in policy {1}" -f $User, $Policy.Name) -foregroundcolor Red
   }
   If ($UserFound) {
      ForEach ($Label in $Policy.ScopedLabels.Guid) {
         $LabelName = $LabelsHash[$Label]
         $LabelNames += $LabelName
      }
           Write-Host ("Policy {0} (Priority {1}) gives {2} access to the labels {3}" -f $Policy.Name, $Policy.Priority, $User, ($LabelNames -join ", "), $Policy.Name) -Foregroundcolor Yellow
    } 
} # End ForEach Policy

Figure 1 shows the output. It’s a little more human-friendly than looking through lists of GUIDs.

PowerShell Knowledge Key

This discussion proves once again that there’s usually multiple ways to solve a problem in Microsoft 365. It also reinforces the worth of knowing how to use PowerShell to interact with system data. All in a day’s work…

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

FileRecycled Audit Event Replaces FileDeleted

In December 2021, I wrote about using events captured in the unified audit log to analyze file deletion activity in SharePoint Online and OneDrive for Business. Recently, some readers complained that the script (available from GitHub) wasn’t finding events for file deletions. A major advantage of PowerShell is that you see all the code and can modify the code to meet your needs. This also means that you can debug the code. My usual response to people who report problems with scripts is to prompt them to do some basic debugging by running the code line-by-line until the problem becomes apparent. Apart from learning how the script works, debugging is a great way to improve PowerShell skills.

In any case, a quick check revealed the problem. Microsoft changed the name of the operation captured in file deletion audit events from FileDeleted to FileRecycled. The change seems to have come into force in March 2023. At least, that’s the date of the first FileRecycled audit event generated by SharePoint Online I can find in my tenant. Microsoft didn’t say anything about the change. It just happened without warning.

File Deletion or Recycling

A case can be argued that FileRecycled is a more accurate description of the action than FileDeleted is (see this documentation update request from August 2022). SharePoint Online doesn’t actually delete an item until it goes through the two-stage recycle bin and exceeds the 93-day retention period that items remain in the recycle bin. The initial action is to move an item from a document library to the site recycle bin, hence the justification to use the FileRecycled name in audit records.

I wouldn’t have a problem if Microsoft told people about the change. Not everyone scans the documentation to detect name changes for audit log activities. Unless you checked the data returned by the Search-UnifiedAuditLog cmdlet or noticed the details for file deletions (or rather “recycled file”) operations returned by the audit log search in the Purview compliance portal (Figure 1), the change would probably have escaped undetected.

Microsoft also changed the UI of the audit search solution so that if you select “Deleted file” from the list of activities to search for, you’ll find events logged when SharePoint Online removes files from the recycle bin.

The Impact of Unannounced Changes

The problem here is that when Microsoft makes unannounced changes to audit data, it potentially affects scripts written by organizations to move data from the audit log to an external repository like Splunk. Among the reasons why organizations populate external repositories with audit data are:

• Long-term retention of audit data. Until recently, Microsoft only kept audit data for 90 days. On July 19, 2023, Microsoft announced a doubling of the audit data retention period to 180 days for Audit standard (Office 365 E3) customers. Audit premium customers have a 365-day audit data retention period with an optional add-on license available to increase the period to 10 years.
• Better search and investigation facilities. Although organizations have built tools to interrogate the unified audit log, the fact remains that the contents of audit log entries often need processing to extract useful information (like this example of extracting information about changes made to Entra ID account properties).

Obviously, if a new name is introduced for a common auditable activity like file deletion, it’s likely that processes to export audit data will ignore these events. I haven’t found any other activity renames but suspect that some might be lurking in the audit log.

Updates without Warning Reduce Confidence

The bottom line is that reliable audit data is an important part of a compliance ecosystem. If audit data is missing or becomes difficult to interrogate, those who work with audit data lose a little faith because it isn’t as comprehensive and accurate as they expect. And that’s a great pity.

A New Method to Handle GDPR DSRs

This one is for the compliance purists, or at least, those concerned with dealing with GDPR data subject requests (DSRs). Message center notification MC664475 (3 Aug 2023) announces that Microsoft is retiring the User data search tool (previously called the Data subject requests tool) with effect from August 30, 2023. Active cases will move to eDiscovery (standard) and can be processed to completion there.

DSRs came about when GDPR gave individuals (the data subjects) the right to recover any information an organization held about them. A DSR is a formal request for that information which the receiving organization must respond to within a month. Microsoft’s user data search solution is a wizard that creates a special form of a standard eDiscovery case with a search designed to find the relevant information.

Microsoft says that there’s been an increase in DSRs and note that the User data search tool is not as functional as eDiscovery standard. The tool doesn’t take advantage of changes and improvements added to eDiscovery standard recently, so it makes sense to replace the tool and concentrate on a single set of features.

Search Query to Find All User Data

To help with the transition, Microsoft published a sample Keyword Query Language (KQL) query to find emails and documents authored by the subject of a user data search. The query is:

participants:"<user name>" OR author:"<user name>" OR createdby:"<user name>"(c:c)(ItemClass=IPM.Document)(ItemClass=IPM.Note)(ItemClass=IPM.Note.Microsoft.Conversation)(ItemClass=IPM.Note.Microsoft.Missed)(ItemClass=IPM.Note.Microsoft.Conversation.Voice)(ItemClass=IPM.Note.Microsoft.Missed.Voice)(ItemClass=IPM.SkypeTeams.Message)

The query can be used with a content search or eDiscovery case search. The important thing is to make sure that the search covers all Exchange Online and SharePoint Online locations.

I tested the search query with a content search. I made three changes. First, I entered the user principal name of the user to search for. Second, I removed the “(c:c)” entry from the search as this term is usually only inserted by the query editor when it checks the syntax and completeness of queries. Finally, I removed the trailing double quotation mark as it wasn’t needed. Figure 1 shows the query as input into the KQL editor. The syntax check advises that the query is quite dense and difficult to read, but that doesn’t affect the effectiveness of the query.

Figure 2 shows the search statistics. Remember that content searches always perform an initial estimate based on search indexes, which is what we see here. The final output for a search is generated when exporting search results. However, the estimate creates a good picture of where content related to the user is present. In this instance, it’s mostly in Exchange Online mailboxes, which implies that the user didn’t create many documents stored in SharePoint Online or OneDrive for Business.

Searching is Only the Start

Running a search to find information is only the start of satisfying a DSR. Among points that should be considered are:

• Content searches and eDiscovery standard can only find information in cloud locations. In hybrid environments, you might need to run searches against on-premises servers.
• Because of the way that Exchange Online delivers separate messages to recipient mailboxes, there’s likely to be many duplicates in the search results.
• When you export search results, Exchange Online decrypts protected messages. Only eDiscovery premium decrypts protected documents when exporting those files, so some other arrangements might be needed to remove sensitivity labels from protected documents before their content is checked and the files can be passed to the user.
• Searches do not address the need to remove information about a data subject (the right to be forgotten defined in Article 17 of the GDPR). However, the reports generated for a search tell you where data matches are found and act as a guide for checking individual locations and items to decide whether items are relevant and what content should be removed. Remember, not all data found for a data subject needs to be removed from locations as it is legally permissible to keep data under certain circumstances, such as the requirement to comply with a legal obligation.

The work to prepare to handover information to the person who requested the DSR starts when the search export finishes. Unlike the search and export operations, reviewing the exported material is a manual process that can become very time consuming, especially for people who aren’t accustomed to responding to DSRs.

Sensible Change

Compliance nerds (like me – as evident in this article about using targeted collections in content searches) will understand why Microsoft removed a specialized tool in favor of a more generic approach. Let’s hope that the engineering resources released by the move help to improve content searches and eDiscovery standard. Better performance for content searches would be a start. They haven’t improved much in that respect since the introduction of the new UI in 2021.

Preservation Hold Library Now Holds Files With Version History

During a recent content search for some documents, I noticed that the search found far fewer versions of SharePoint Online files than was the case in the past. This is the effect of the change introduced in mid-2022 (or rather, delayed until August 2022) documented in message center notification MC288633 (Microsoft 365 roadmap item 82062). I discussed the potential for the change when Microsoft first announced their intention to implement it in October 2021. Now it’s time to see how things work in practice.

In a nutshell, from the time Microsoft deployed the change to a tenant, SharePoint Online stops storing multiple copies of retained files in the Preservation Hold Library. Instead, SharePoint follows the same approach as taken for regular files stored in document libraries and stores a single file containing its full version history. Files end up in the Preservation Hold Library when SharePoint must retain them because of a retention policy applied to the site, a retention label applied to individual files, or eDiscovery holds. In all cases, files remain in the Preservation Hold Library until the hold applied by retention or eDiscovery lapses.

Site owners don’t have to create the Preservation Hold Library as SharePoint creates it automatically when required. To view Site items in the Preservation Hold Library, add /PreservationHoldLibrary to the site URL in the browser bar.

Difference in File Storage

Figure 1 shows how SharePoint used to store Office documents in the Preservation Hold Library. Each version is stored as a separate file with no versions. If the user updates the file, SharePoint creates a new version in the Preservation Hold Library to capture the changes and make them available for eDiscovery.

The example in Figure 1 comes from January 2022, before Microsoft deployed the change. Examining a more recent entry in the Preservation Hold Library, we see that different versions of the file are available (Figure 2).

It’s easy for changes like this to pass by without being noted, especially when Microsoft delays the deployment of an update for one reason or another (in this case, it was to give customers more time to prepare).

A practical effect of the change is that eDiscovery searches find the latest version of retained files. If investigators want to see previous versions, they can view or restore that version.

Storage Quotas

One of the issues with the way that SharePoint Online captures files for retention is the large amount of storage consumed for this purpose. Given that SharePoint storage is expensive, this is bad news.

In Figure 3, we see that SharePoint uses 20.6 GB or 21.87% of the overall site storage. Even though I know that this site holds many copies of large chapter and book files for the Office 365 for IT Pros eBook, 20.6 GB of retained content is quite a chunk.

The good news is that the advent of multi-version storage seems to have reduced the storage used by retention by a couple of percentage points over what it was in 2021. It’s probably too early to be definite on this point, but the signs are good. My expectations are that the overall storage used by the preservation hold library should reduce over time as older files reach the end of their retention period and SharePoint removes them from the library. We’ll see.

It’s taken me too long to comment on the Preservation Hold Library change. Sometimes life gets so busy that good changes go by ignored. This is a good change.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Find SharePoint Documents to Decrypt Before Tenant Divestiture

A reader wanted to know the best way to find a bunch of files protected by a sensitivity label. The scenario is that the organization had divested an operating division. Sites used by that division had protected files that needed to be decrypted before they moved to a new tenant. If this failed to happen, the protected files would be inaccessible in the new tenant because the users signing into that tenant didn’t have the right to access their content. The question therefore is what’s the best way to find SharePoint documents protected by sensitivity labels so that administrators can remove the labels before the divestiture.

Office documents store label information in their file attributes, so the basic task is to search those attributes to find files protected with one or more specific labels. You could try and do the job with PowerShell and the Graph API. For instance, I have a script to report the files in a SharePoint document library, including the labels assigned to files. Another script uses the Unlock-SPOSensitivityLabelEncryptedFile cmdlet from the SharePoint Online management module to remove labels from documents. The two could be combined to find and remove labels from protected files.

The PowerShell approach is viable if the exercise spans several thousand documents in a few sites. Things become more problematic as the numbers scale up. For instance, sites with document libraries configured to apply default sensitivity labels to new documents (requires Office 365 E5 licenses) could accumulate thousands of protected documents in each library.

Using eDiscovery Searches to Find SharePoint Documents Protected by Sensitivity Labels

eDiscovery searches could solve the problem. Microsoft Purview eDiscovery (Premium) supports finding protected content. The documentation says that files “located on a SharePoint or OneDrive account are searchable and decrypted when the search results are prepared for preview, added to a review set in eDiscovery (Premium), and exported.” Figure 1 shows search preview displaying a protected document found by eDiscovery (Premium).

eDiscovery Premium can’t process documents protected by sensitivity labels with user-defined permissions (permissions assigned by the document author when they apply the label to the document) or when user access granted by the sensitivity label has an expiration date. In addition, eDiscovery Premium can’t decrypt files protected by the Azure Information Protection unified labeling client that are subsequently uploaded to SharePoint Online or OneDrive for Business.

Purview eDiscovery (Standard) and content searches can also find items protected with sensitivity labels. However, these solutions do not decrypt the content unless an unprotected document is an attachment for a protected email. That’s OK, because if you find and export the protected files, an Azure Information Protection (AIP) super-user can remove labels from files using the Set-AIPFileLabel cmdlet from the Azure Information Protection module. Although this is feasible, if you’re contemplating processing thousands of documents, I would buy some Office 365 E5 licenses and use Purview eDiscovery (Premium).

Configuring Content Searches to Find SharePoint Documents with Sensitivity Labels

To search for SharePoint files through Microsoft Search or a Purview content search, you use sensitivity label identifiers (GUIDs). The SharePoint Online search schema includes a managed property called InformationProtectionLabelId, which holds the GUID (identifier) for the sensitivity label assigned to a document. You can use this property to search for documents with a specific sensitivity label in SharePoint search or content searches by using the form InformationProtectionLabelId:GUID. For example, InformationProtectionLabelId:2fe7f66d-096a-469e-835f-595532b63560. The search results are trimmed and only display documents whoever performs the search can access.

An alternative approach is to remap the Sensitivity property, which stores the local language value of the label, to one of the 200 customizable RedefinableString managed properties available in SharePoint Online. This approach allows users to search using label names like “Public” and “Confidential,” but the downside is that it’s possible to assign multiple local language values for sensitivity label display names. If this happens, the searches would need to look for all defined values. By comparison, the identifier is unique and immutable, so using label identifiers is a better choice for search criteria.

To find the label identifiers, connect a PowerShell session to the compliance endpoint and run this command:

Get-Label | Format-Table ImmutableId, DisplayName

ImmutableId                          DisplayName
-----------                          -----------
2fe7f66d-096a-469e-835f-595532b63560 Public
8b652c9a-a8b7-40ec-bb1a-c5334b1b7fef No Encryption
a49e1277-93db-4a2f-8105-43c5196b4fef Non-business use
fb0975b2-1ea1-4c3c-850c-e859e690d282 Partner-Accessible Content
e42fd42e-7240-4df0-9d8f-d14658bcf7ce General Access

Now create a content search and input the label identifier into the search conditions, prefixed with InformationProtectionLabelId, just like shown in Figure 2:

To search for documents with different sensitivity labels, separate the label identifiers with OR. For example, here’s the Keyword Query Language (KQL) query to find documents with either of two labels created between 19 May 2023 and 23 June 2023:

InformationProtectionLabelId:1b070e6f-4b3c-4534-95c4-08335a5ca610 OR InformationProtectionLabelId:2fe7f66d-096a-469e-835f-595532b63560(c:c)(date=2023-05-19..2023-06-23)

Dealing with Protected Content

Searching for protected files isn’t difficult. The real question is what you do with the files that the search uncovers. Having a bunch of encrypted files (with or without the new and improved encryption cipher) isn’t much good unless you can decrypt them. That’s where most of the problems lie, which is why Microsoft might have included the feature in Purview eDiscovery (premium).

Learn about using sensitivity labels, eDiscovery, and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.

Use Entra ID Administrative Units to Scope Compliance Administrator Responsibilities

In a development designed to give complex organizations extra flexibility in managing Purview solutions, Entra ID (Azure AD) administrative units can now be used to assign segregated responsibility for policy management. This feature is available in information protection and data loss prevention, and now (Microsoft 365 message center notification MC541152 (13 Apr 2023, Microsoft 365 roadmap item 117354) data lifecycle management (retention and label policies). The functionality is in preview and is expected to roll out in June 2023. For now, the functionality is only available in commercial tenants.

Limiting Scope for Administrators

Microsoft Purview uses administrative role groups to define what the members of each group can do. Each role group has a set of one or more roles to break down the scope of what an administrator can do into smaller tasks. For instance, the compliance administrator role group includes roles like “compliance search” (needed to run eDiscovery searches) and “retention management” (needed to work with retention labels and policies).

The default situation for a Microsoft 365 tenant is that compliance role groups have an organization-wide scope. In other words, once someone is in a role group, they can use the roles assigned to the group to perform administrative operations across the entire organization. This approach works well for small to medium organizations. It becomes less satisfactory as the size and complexity of organizations grow. For instance, a company might have IT administrators based in separate countries or assigned to handle work for different departments or operating units. In these situations, it might not be appropriate to have an administrator whose primary focus is dealing with French operations handle retention policies for German accounts.

Administrators and Entra ID Administrative Units

Administrative units allow an organization to logically organize directory objects into smaller units for management purposes. User accounts can be in multiple administrative units. For example, a user account could be in an administrative unit for their department and another for their country.

It’s very easy to create an administrative unit and add user accounts to it manually. It’s even easier and more powerful to use dynamic administrative units where Entra ID maintains the membership of the administrative unit based on object properties. And once you set up and populate the administrative units, you can assign them to members of Purview compliance role groups. In Figure 1, two members of the role group can work across the organization while the other three are limited to one or more administrative units.

Entra ID Administrative Units and Adaptive Scopes

Data lifecycle management already has adaptive scopes, introduced in late 2021. Adaptive scopes allow organizations to target specific users, groups, and sites based on certain properties like a user’s country or department. It seems like an overlap might exist here but that’s not the case. Administrative units are all about limiting what an administrator can do when managing policies. Adaptive scopes are all about limiting the scope of processing when background jobs come to process the policies.

Looking back to Figure 1, Jessica Chen is an administrator whose limit is defined by the United States administrative unit. Any retention policy created by Jessica can only apply to accounts within that administrative unit. Figure 2 shows how to scope a retention policy to an administrative unit.

By contrast, my account is scoped for the organization, meaning that the policies I work with apply to everyone in the organization. Remember, an account can come within the scope of multiple retention policies, including Exchange Online mailbox retention polices and individual items can have retention labels. The background jobs which apply policies follow principles of retention to decide how to resolve the retention requirements for items.

Behind the scenes, the introduction of administrative units into the mix means that the background jobs (like the Exchange Managed Folder Assistant and the Retention assistant) make sure that a policy scoped to administrative units is not applied to accounts that are not in those administrative units.

One way of thinking about this is that all data lifecycle management use adaptive scopes and that the background jobs enforce the scopes when they run. In terms of flexibility, scoping runs from least adaptive to most adaptive:

• Organization-wide with static locations (the default, available in Office 365 E3)..
• Organization-wide with adaptive locations (requires Office 365 E5).
• Administrative-unit with static locations.
• Administrative unit with adaptive locations.

Policies that use administrative units only process locations (like a mailbox) belonging to the administrative unit even if administrators add other locations to the policy.

Support for Entra ID Administrative Units in Other Purview Solutions

Administrative unit support is available in the following Microsoft Purview solutions:

• Data Loss Prevention (DLP): Management of DLP policies, including restricting the visibility of DLP alerts to administrators.
• Information Protection: Management of sensitivity label publishing policies. This includes the ability to see label actions in the Activity Explorer.

Licensing

To use administrative units, you need Entra ID Premium P1 licenses for every account in an administrative unit. Given that Enterprise Mobility and Security (EMS) now has 250 million users, the large enterprises likely to want to use administrative units have these licenses.

To assign administrative units to Purview administrators, you need (Microsoft 365 E5/A5, Microsoft 365 E5/A5/F5 Compliance and F5 Security & Compliance, or Microsoft 365 E5/A5/F5 Information Protection & Governance) licenses for each administrator. This requirement is as surprise as usually Office 365 E5 is sufficient to cover advanced functionality.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

No Remote PowerShell Connections for Compliance Endpoint

Following the December 15, 2022 announcement to deprecate Remote PowerShell connections to Exchange Online, the news in MC541649 (April 14) that the connection to the compliance endpoint with Connect-IPPSSession cmdlet will follow suit is no surprise. The only surprise is that the text of the announcement is quite so confusing.

Connect-IPPSSession establishes a PowerShell connection to what used to be called the Security and Compliance endpoint (SCC). Microsoft also refers to EOP in the announcement because some cmdlets loaded (like Get-PhishSimOverridePolicy) are associated with Exchange Online Protection.

Today, the endpoint might be called the Microsoft Purview endpoint or compliance endpoint because the cmdlets loaded after establishing the connection allow access to objects like retention labels, sensitivity labels, and their respective publishing policies.

REST Rather than Remote PowerShell

Microsoft says that “in line with our vision to enhance the security of our cloud,” the compliance cmdlets will now use a REST API instead of the traditional (established in Exchange 2010) Remote PowerShell approach. Once you install V3.2 of the Exchange Online management module (apparently available on May 1, 2023), the REST-base cmdlets are available and Remote PowerShell is no longer required. You won’t see this kind of message when connecting to the endpoint:

WARNING: Your connection has been redirected to the following URI:
"https://eur01b.ps.compliance.protection.outlook.com/Powershell-LiveId?BasicAuthToOAuthConversion=true;PSVersion=5.1.22621.963"

Existing scripts don’t need to be updated. As Microsoft says “Simply using the new module will ensure REST is used rather than RPS.”

Part of the confusion in this announcement is the need to use a version of the Exchange Online management module that is currently unavailable. The current version doesn’t support the UseRPSSession parameter mentioned by Microsoft in their text:

Connect-IPPSSsession -UseRPSSession:$false

Microsoft says that Remote PowerShell connections to the compliance endpoint will not be available after July 15, 2023. This is a tad ahead of the announced schedule for the depreciation of Remote PowerShell for the main Exchange module (due on October 1, 2023).

Using a REST API instead of Remote PowerShell should make cmdlets more reliable and better performing. Remote PowerShell is very much a mechanism rooted in a period when Microsoft needed to support management of Exchange servers from workstations without the need to log into the servers. It worked well for Exchange 2010 and 2013 but its deficiencies are obvious with cloud services when connecting to a service is more important than connecting to a server.

More to Do

Welcome as it is to see the compliance cmdlets transition to a REST-based endpoint, there’s still more to do to fully modernize these cmdlets. Adding support for Azure managed identifies is a big step that needs to happen. It can be argued that the compliance cmdlets are less heavily accessed than those in the main Exchange module, but this ignores the fact that many of the tasks that you might want to run on a scheduled basis using an Azure Automation runbook might need to access compliance elements, like the list of sensitivity labels defined in a tenant (Figure 1).

Good Change

There’s no doubt that moving the compliance endpoint away from a dependency on Remote PowerShell is a good thing. Throwing away the baggage of on-premises implementations to make things work smoother in the cloud is always positive for those who need to automate Microsoft 365 operations. This is especially so when discussing compliance because the range of compliance functionality available in Microsoft 365 is so much wider and deeper than in the on-premises servers.

At this point, we don’t have the V3.2 release of the Exchange Online management module available so it’s hard to verify Microsoft’s assertion that nothing needs to be done to move the compliance cmdlets from Remote PowerShell to REST-based APIs. However, given the progress seen in the main Exchange Online management module, Microsoft is progressing down a well-known path and the change should be smooth. At least. I hope it will be.

Export Details of Disposition Review Items

Message Center notification MC521457 (Microsoft 365 roadmap item 106102) might have passed you buy on February 27 when Microsoft announced a new PowerShell cmdlet for disposition review. Relatively few people are concerned with Microsoft Purview Data Lifecycle Management to care that a new cmdlet is available to export (not just “to support”) disposition review items, so it’s entirely natural that you might have gone on to read about other announcements occurring around the same time, like Exchange Online’s improved message recall feature.

Roll-out of the new Get-ReviewItems cmdlet is now complete. The cmdlet is available after loading the latest version of the Exchange Online management module.

Disposition Items

Microsoft 365 retention labels often result in the deletion of items after the lapse of their retention periods. This is enough for most organizations, but those that want oversight over the final processing of selected items can configure retention labels to invoke a disposition review, part of the Microsoft Purview records management solution. Disposition reviews are often used to retain messages and documentations such as those for project documentation until the organization is absolutely sure that it’s safe to remove individual items.

Using a disposition review with retention labels requires advanced licenses, like Office 365 E5. An organization can put items through a single-stage or multi-stage review (Figure1) leading to final deletion, retention for another period, or assignment of a new retention label. The reviewers who decide on the disposition of content are selected by the organization because they have the expertise and experience to know if items are still needed or can progress to final disposition. It’s also possible to configure a custom automated disposition process using Power Automate.

Exporting Disposition Review Items

The Get-ReviewItems cmdlet doesn’t affect disposition outcomes. It’s a utility cmdlet to export details of disposition review items for a specific retention label in a pending or disposed (processed) state. The reason why the cmdlet exists is that the Purview GUI (Figure 1) supports export of up to 50,000 items. Although it’s unlikely that an organization will have more than 50,000 items awaiting disposition review, it is possible that they might have more than 50,000 disposed (processed) items. The Get-ReviewItems cmdlet can export details of all those items.

Microsoft’s documentation for Get-ReviewItems includes examples of using the cmdlet. One in particular is noteworthy because it explains how to fetch pages of review items until all items have been recovered. Fetching pages of data is common practice in the Graph API world and it’s done to reduce the strain on the service imposed if administrators requested very large numbers of items at one time.

I expanded the example to create a report of all disposition review items for a tenant (all items for all retention labels with a disposition review). Here’s the code:

Connect-IPPSSession

[array]$ReviewTags = Get-ComplianceTag | Where-Object {$_.IsReviewTag -eq $True} | Sort-Object Name
If (!($ReviewTags)) { Write-Host "No retention tags with manual disposition found - exiting"; break }

Write-Host ("Looking for Review Items for {0} retention tags: {1}" -f $ReviewTags.count, ($ReviewTags.Name -join ", "))

$Report = [System.Collections.Generic.List[Object]]::new() 

[array]$ItemsForReport = $Null
ForEach ($ReviewTag in $ReviewTags) {
 Write-Host ("Processing disposition items for the {0} label" -f $ReviewTag.Name)
 [array]$ItemDetails = $Null; [array]$ItemDetailsExport = $Null
 # Fetch first page of review items for the tag and extract the items to an array
 [array]$ReviewItems = Get-ReviewItems -TargetLabelId $ReviewTag.ImmutableId -IncludeHeaders $True -Disposed $False  
 $ItemDetails += $ReviewItems.ExportItems
 # If more pages of data are available, fetch them and add to the Item details array
 While (![string]::IsNullOrEmpty($ReviewItems.PaginationCookie))
 {
    $ReviewItems = Get-ReviewItems -TargetLabelId $ReviewTag.ImmutableId -IncludeHeaders $True -PagingCookie $ReviewItems.PaginationCookie
    $ItemDetails += $ReviewItems.ExportItems
 }
 # Convert data from CSV
 If ($ItemDetails) {
   [array]$ItemDetailsExport = $ItemDetails | ConvertFrom-Csv -Header $ReviewItems.Headers 
   ForEach ($Item in $ItemDetailsExport) {
     # Sometimes the data doesn't include the label name, so we add the label name to be sure
     $Item | Add-Member -NotePropertyName Label -NotePropertyValue $ReviewTag.Name }
   $ItemsForReport += $ItemDetailsExport
 }
}

ForEach ($Record in $ItemsForReport) {
  If ($Record.ItemCreationTime) {
   $RecordCreationDate =  Get-Date($Record.ItemCreationTime) -format g 
  } Else {
   $RecordCreationDate = "Unknown" }
 
   $DataLine  = [PSCustomObject] @{
     TimeStamp       = $RecordCreationDate
     Subject         = $Record.Subject
     Label           = $Record.Label
     AppliedBy       = $Record.LabelAppliedBy
     RecordType      = $Record.RecordType
     'Last Reviewed' = Get-Date($Record.ItemLastModifiedTime) -format g
     'Review Action' = $Record.ReviewAction
     Comment         = $Record.Comment
     'Deleted Date'  = $Record.DeletedDate
     Author          = $Record.Author
     Link            = $Record.InternetMessageId
     Location        = $Record.Location
   } 
   $Report.Add($DataLine)
}

Everything works – until you meet an item with a comma in its subject or the comment captured when a reviewer decides upon a disposition outcome. After discussing the issue with Microsoft, its root cause is that the export is in CSV format and the comma in these fields causes problems when converting from CSV format. Microsoft is working on a fix which might be present as you read this.

The Lesson of Export

The Get-ReviewItems cmdlet will be a useful tool for those involved in disposition processing. They can extract details of items and report that information in whatever way they wish. The comma issue proves that documentation is not always perfect. It’s important to test examples to make sure that they work as they should.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Sensitivity Bar Informs Users About the Labeling Status of Office Documents

I guess I was surprised when I saw message center notification MC515530 appear on February 15 all about the new sensitivity bar (or sensitivity labeling bar) for the Microsoft 365 apps for enterprise (the subscription version of the Office desktop apps). The surprise didn’t come from not knowing about the bar, because I’ve been using it for months as it’s in the Current Channel Preview release. It’s more that it seems to have taken forever to get a relatively simple (and good) change to general release. The update is Microsoft 365 roadmap item 88517 and will appear in the standard release of Word, PowerPoint, and Excel in March 2023. The Microsoft 365 Insider blog (September 20, 2022) explains how the sensitivity bar works.

It makes sense to show users details of the sensitivity label applied to a document. Office apps show the information shown in Figure 1 when a user clicks on the file name in the application window. You can update the file name, choose a different sensitivity label, save the file to a different location, or see the version history. This functionality is available even if you choose to hide the sensitivity bar (see below). What we’re concerned about here is the addition of the sensitivity label name and the colored shield in what’s displayed.

The display of the sensitivity label name in the sensitivity bar now means that Office apps display sensitivity labels in three separate places in the UI: the bar, the sensitivity button, and in the information bar at the bottom of the screen. The lock icons shown in the sensitivity and information bars are visual indicators that the sensitivity label protects the document with rights management.

Eliminating the Unified Labeling Client

Introducing the sensitivity bar is part of Microsoft’s ongoing effort to eliminate the unified labeling client (also known as the Azure Information Protection client). This add-on client was the original software installed to allow users to label Office documents and it included an information bar to display label properties.

The Office apps include native labeling capabilities, meaning that they include the necessary Microsoft Information Protection code to interact with labels, apply rights management encryption, and so on. Native protection means that there’s no need for an add-on client, but before it’s possible to transition all customers off the unified labeling client, Microsoft needs to provide equivalent functionality in the Office apps. Microsoft has been working to give the Office desktop apps equivalent functionality to that gained by installing the unified labeling client since at least 2018. A big step forward happened in 2019 when the Office apps gained native protection support. Now we’re in the final stages of the process when tweaks to the UI like this one and the introduction of colors for sensitivity labels apply the final fit-and-finish.

Hiding the Sensitivity Bar

If you don’t want the Office apps to display sensitivity label names, you can amend the label policy that publishes sensitivity labels to users to add a setting to hide the sensitivity bar. Microsoft’s documentation suggests that this might be appropriate if people use very long file names and want to see that information displayed (they can always see information about labels through the Sensitivity button).

In any case, you can’t disable the sensitivity bar through the Purview compliance center. Instead, run these PowerShell commands to connect to the compliance endpoint, select all label policies, and add the setting:

Connect-ExchangeOnline
Connect-IPPSSesssion
[array]$LabelPolicies = Get-LabelPolicy
ForEach ($Policy in $LabelPolicies) { 
  Set-LabelPolicy -Identity $Policy.Name -AdvancedSettings @{HideBarByDefault="True"}
}

To check the setting, run:

Get-LabelPolicy | Format-List Name, PolicySettingsBlob

You should see the setting shown like this:

<setting key="HideBarByDefault" value="True" />

Figure 2 shows the effect, which is quite subtle. Everything that was there before is still present but the label is now represented by a colored shield (meaning it’s a protected document) instead of the shield and label name.

To reverse the setting, set its value to False. The Office apps pick up changes made to label policies the next time they refresh their label cache, so it might take several hours before apps hide the sensitivity bar.

Useful Change for Those Interested in Sensitivity Labels

For most users, the addition of the sensitivity bar is a minor improvement that I find useful (but maybe only because I label every document). The bar serves a useful purpose in highlighting the presence of a sensitivity label (which might have been applied automatically by a label policy), and might help to raise awareness about the need to exercise care when handling confidential information. On the other hand, the sensitivity bar might fade into the background like many other elements of the Office GUI that people only access when they really need to. Of course, if your organization doesn’t use sensitivity labels, you don’t need to worry about the sensitivity bar.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Report a Concern about a Message in a Teams Personal or Group Chat

Communication Compliance policies are part of the Microsoft Purview suite designed to help organizations monitor the content of messages. Originally known as supervision policies (which gives an indication of their purpose), communication compliance policies could only process email until Microsoft introduced support for Teams in early-2020.

Communication Compliance Basics

The basics of communication compliance revolve around the analysis of messages captured in special supervision mailboxes against conditions defined in policies. Settings include:

• The accounts that come within the scope of the policy (the monitored mailboxes).
• Direction of message traffic (inbound, outbound, or both).
• The percentage of traffic captured for analysis. Although it’s possible to examine every message sent and received by the accounts within a policy scope, it’s more usual to examine a percentage. Purview extracts messages at random to meet the selected percentage.
• Whether to use Optical Character Recognition (OCR) to examine attachments and images sent in email and Teams.
• The classifiers and conditions used to select messages for further review. Microsoft Purview includes a default set of trainable classifiers such as Profanity and Threat to detect these conditions in messages. Organizations can train their own classifiers as required. Conditions (like those used in DLP and mail flow rules) can focus the review to specific messages such as those coming from certain domains.
• The supervisors responsible for reviewing messages detected by the policy.

Exchange Online redirects copies of messages needed for communication compliance as email passes through the transport service. Purview uses the compliance records created by the Microsoft 365 substrate to process Teams messages.

Teams Report a Concern

In mid-2022, Microsoft introduced the ability for Teams users to report a concern with messages sent in personal and group chats. By August 31, 2022, the feature reached all tenants with Office 365 E5 or Microsoft 365 E5 compliance licenses who had communication compliance policies. It can take up to 30 days before the feature appears in tenants after they start to use communication compliance policies.

Visibility of the Report a Concern option (Figure 1) is controlled by the AllowCommunicationComplianceEndUserReporting setting in the Teams messaging policy for an account. The setting is available in the Teams admin center or PowerShell. By default, the setting is enabled. To see the setting for all messaging policies, run:

Get-CsTeamsMessagingPolicy | Format-Table Identity, AllowCommunicationComplianceEndUserReporting

When a user reports a concern (Figure 2), Teams tags the message and up to five messages preceding the reported messages and five messages afterward (if available). Many messages sent in Teams chats are short and concise. The extra messages provide the context to allow a reviewer to decide if a problem really exists.

Reviewing Reported Messages

Apart from exposing the Report a Concern option in Teams chat, the other major piece of functionality is the automatic creation of the User-reported messages policy. The only change an organization can make to the User-reported messages policy is to update the supervisors responsible for reviewing reported messages.

As with all communication compliance policies, to review reported messages, head to the communication compliance section of the Purview compliance portal (Figure 3) and select the policy to review. The policies available to a user depends on the communication compliance administrative role assigned to their account.

Select the policy and open the Pending tab to see the messages requiring investigation. The default view is to see the summary, meaning the message reported by the user. The conversation view exposes the messages before and after the reported message to give context to the reviewer (Figure 4).

Like any other message detected by a communication compliance policy, the role of the investigator is to decide if the content violates the acceptable norms for communication. Because individual users make a subjective decision to report a message, the variation in content is likely broader than in the set of messages selected using a trainable classifier. This underlines the need to understand the tone and flow of the conversation within which the problem message occurred.

After reviewing the message, the investigator can resolve the problem (for instance, decide that the user overreacted when they reported the concern), notify the user (and others) about their assessment, or escalate the issue for further investigation. The Remove message in Teams option (available through the down arrow menu in Figure 4), replaces the reported message with a notification that the message “was blocked due to organizational policy” for the recipient and “This message was blocked” for the sender (Figure 5).

This action, which is similar to the way that Teams handles messages blocked by DLP policies, allows the organization to withdraw a problem message during an investigation. However, there’s no way to withdraw the block and expose the message again if it’s deemed acceptable.

Keeping Things Clean

Report a Concern is a useful feature (Teams Free has a similar feature where Microsoft takes care of investigations) if you have the right licenses. Then again, if the organization needs something like communication compliance, the cost probably doesn’t matter. In which case, it’s nice to have a way to keep everyone polite in their Teams chat.

Keep up to date with developments like the app support for sensitivity labels by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Use PowerShell to Monitor Group Membership Changes

A reader asks how to monitor specific Azure AD groups so that they are notified if anyone updates the membership of these groups. Because of the pervasive use of Teams in Microsoft 365 tenants and the range of resources available to team members, it’s quite common to find that organizations want to keep an eye on some sensitive groups, like those used by senior management or for confidential purposes, like merger and acquisition activities. Various commercial products include this functionality but it’s always fun to see if you can create a solution from the out-of-the-box components available to tenants.

I’ve been down a similar road in the past, such as reporting the deletions of Microsoft 365 groups, but this request is a little different because it involves marking groups to be monitored. My initial thought was if this could be a scenario to use Azure AD custom security attributes? Administrators can define attribute sets and assign attributes to Azure AD objects. Unfortunately, Azure AD currently only supports custom security attributes for user objects, managed identities, and service principals (for apps). Azure AD custom security attributes are still in preview and the range of supported object types is likely to change before general availability but doesn’t help in this situation.

Exchange Online Custom Attributes for Groups

Exchange Online mail-enabled objects, like groups, have fifteen custom attributes capable of storing single values and five multi-value custom attributes. It should be easy to assign a custom attribute to mark groups for monitoring. In this example, I’m checking for membership changes to marked Microsoft 365 groups.

The first thing is to update the targeted Microsoft 365 groups with the flag. This is easily done with the Set-UnifiedGroup cmdlet (neither the Exchange admin center nor the Microsoft 365 admin center support access to the custom attributes):

Set-UnifiedGroup -Identity "Contract Workers" -CustomAttribute15 "Monitor"

After marking the groups, it’s possible to find the groups with a server-side filter. This is important because we don’t want to have to retrieve every group and then check its properties:

[array]$Groups = Get-UnifiedGroup -Filter {CustomAttribute15 -eq "Monitor"}

Writing the Code

The code to report membership changes to monitored groups has the following steps:

• Find the set of monitored Microsoft 365 Groups.
• Build a hash table of the group object identifiers and display names. For maximum performance, the script uses the hash table to check if an audit record relates to a monitored group.
• Define a variable holding the set of audit events to look for.
• Define the start and end date for the search. In this example, we look back 30 days.
• Run the Search-UnifiedAuditLog cmdlet to perform the search.
• Examine each event returned by the search to check if it’s related to a monitored group. If it is, capture information about the event.

Here’s the code to monitor group membership changes:

Connect-ExchangeOnline
Write-Host "Finding groups to monitor..."
[array]$Groups = Get-UnifiedGroup -Filter {CustomAttribute15 -eq "Monitor"}
If (!($Groups)) {Write-Host "No groups found to monitor - exiting" ; break }

$GroupIds = @{}
ForEach ($G in $Groups) {
   $GroupIds.Add($G.ExternalDirectoryObjectId,$G.DisplayName) }

$Operations = 'Add member to group', "Remove member from group"
$StartDate = (Get-Date).AddDays(-30); $EndDate = (Get-Date) 

Write-Host "Finding audit records for group member adds and deletes..."
[array]$Records = (Search-UnifiedAuditLog -Operations $Operations -StartDate $StartDate -EndDate $EndDate -ResultSize 1000 -Formatted)
If (!($Records)) { Write-Host "No audit records found for add or delete members from monitored groups - exiting" ; break }

$Report = [System.Collections.Generic.List[Object]]::new() # Create output file 

ForEach ($Rec in $Records) {
   $AuditData = ConvertFrom-Json $Rec.Auditdata
   Switch ($AuditData.Operation) {
    "Remove member from group." {
       $GroupId = $AuditData.ModifiedProperties | Where-Object {$_.Name -eq 'Group.ObjectId'} | Select-Object -ExpandProperty OldValue }
    "Add member to group." {
       $GroupId = $AuditData.ModifiedProperties | Where-Object {$_.Name -eq 'Group.ObjectId'} | Select-Object -ExpandProperty NewValue }
   }
   $GroupName = $GroupIds[$GroupId]
   If ($GroupName -ne $Null) { # Update is for one of the monitored groups
      
      $ReportLine = [PSCustomObject] @{
        TimeStamp = Get-Date($AuditData.CreationTime) -format g
        User      = $AuditData.UserId
        Group     = $GroupName 
        Member    = $AuditData.ObjectId
        Action    = $AuditData.Operation }        
      $Report.Add($ReportLine) 
  } #End if  

} # End ForEach audit record

$Report | Out-GridView

Figure 1 shows the result of the search and analysis of the audit records to find events relating to membership changes in the monitored groups.

Monitor Group Membership Changes Automatically

This is an excellent example of the kind of periodic check that’s suitable for execution by an Azure Automation runbook with the results delivered by email or posted to a Teams channel for action by whoever’s responsible for monitoring the membership of the groups.

The point is that the audit log holds a lot of useful information that can answer questions about Microsoft 365 operations. All you need to do is take advantage of the available data.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work, including how to monitor group membership changes without paying for another product.

If You Have Office 365 E3 Licenses, Check the Flow of Mailbox Audit Events

A reader contacted me to report some problems that a compliance exercise had thrown up when it was discovered that the Office 365 audit log did not contain mailbox audit records for some Exchange Online mailboxes. As it turned out, all the affected mailboxes belonged to Azure AD accounts with Office 365 E3 licenses. Not having some expected mailbox audit events available in the audit log is not a great situation for any compliance officer or tenant administrator to find themselves in.

When the customer organization contacted Microsoft support, they were told that a bug existed in Exchange Online that stops the AuditEnabled setting being accurately reported for mailboxes with Office 365 E3 licenses. When administrators examined the setting with the Get-Mailbox or Get-ExoMailbox cmdlets, Exchange Online reported $True, meaning that auditing is enabled for the mailbox:

Get-ExoMailbox -Identity Brian.Weakliam -Properties AuditEnabled | Format-Table DisplayName, AuditEnabled

DisplayName                 AuditEnabled
-----------                 ------------
Brian Weakliam (Operations)         True

However, the mailbox audit events remain in Exchange Online and never make it into the Office 365 audit log. Everything works perfectly for mailboxes assigned Office 365 E5 licenses.

What Microsoft Says

Microsoft’s documentation says:

Although mailbox audit logging on by default is enabled for all organizations, only users with E5 licenses will return mailbox audit log events in audit log searches in the Microsoft Purview compliance portal (Figure 1) or via the Office 365 Management Activity API by default.

The page also says:

Even when mailbox auditing on by default is turned on for your organization, you might notice that mailbox audit events for some users aren’t found in audit log searches by using the compliance center, the Search-UnifiedAuditLog cmdlet, or the Office 365 Management Activity API. The reason for this is that mailbox audit events will be returned only for users with E5 licenses when you [use] one of the previous methods to search the unified audit log.

Apparently, Microsoft doesn’t consider it a bug when audit data from mailboxes with Office 365 E3 licenses doesn’t reach the Office 365 audit log. The justification is that:

• The audit events are available in Exchange Online (in the Audits folder in the Recoverable Items part of each mailbox) and can be found there.
• If the organization wishes to ingest the audit events into the Office 365 audit log, all they need to do is run the Set-Mailbox cmdlet to update the AuditEnabled setting to $True. In other words, the $True value reported by Exchange Online is accurate because it reports that mailbox events are available. Running Set-Mailbox to update the setting to $True (again) doesn’t change anything (the setting is still $True) but Exchange Online takes the hint and will ingest mailbox events into the Office 365 audit log thereafter.

Clearly, this is a non-optimal situation. I wrote about the same issue in March 2020 when Microsoft rolled out mailbox auditing by default across Exchange Online. It seems like the same documentation is online and people are still running into problems. And that this Exchange Online functionality hasn’t progressed much since.

Audit Events Appear to Flow for New Mailboxes

Or has it? I created a couple of new Azure AD accounts and assigned them Office 365 E3 licenses and then signed into each mailbox to perform several actions that I knew should generate audit records. After waiting 30 minutes to allow ingestion to occur, I ran the Search-UnifiedAuditLog cmdlet to see if any events existed in the Office 365 audit log. They were!

[array]$records = Search-UnifiedAuditLog -StartDate 18-Aug-2022 -EndDate 19-Aug-2022 -Formatted -userids michael.king@office365itpros.com
$records | ft creationdate, operations
 
CreationDate        Operations
------------        ----------
18/08/2022 12:54:31 SoftDelete
18/08/2022 12:54:23 MoveToDeletedItems
18/08/2022 12:54:19 SoftDelete
18/08/2022 12:53:19 SoftDelete
18/08/2022 12:53:14 MoveToDeletedItems

This result is exactly what you’d hope to see. No administrator intervention was necessary to have events flow from Exchange Online to the Office 365 audit log. I obtained the same results with mailboxes in another tenant. I asked Microsoft about the issue and learned that mailbox auditing was enabled by default because of the configuration of the Exchange Online forest that hosts the mailboxes. For performance reasons (to reduce the number of audit events processed by Office 365), this is not the situation for every Exchange Online forest. This is why Microsoft’s documentation recommends that you should re-enable auditing for the E3 mailboxes to force ingestion of audit events for these mailboxes into the Office 365 audit log.

The conclusion is there might be many mailboxes with Office 365 E3 licenses running in tenants around the world that don’t feed data into the Office 365 audit log. The only solution is to run Set-Mailbox. And you might as well run the cmdlet for all mailboxes with Office 365 E3 licenses just to be sure.

The script included in my previous post will do the job of finding mailboxes with Office 365 E3 licenses and updating their audit settings. The script uses the Get-AzureADUser cmdlet to find the relevant accounts. If you’ve switched to the Microsoft Graph PowerShell SDK, the updated code is:

[array]$Mbx = Get-MgUser -filter "assignedLicenses/any(s:s/skuId eq $Office365E3)" -All

Good for the Future?

If you use Office 365 E3 licenses, be sure to check that mailbox auditing works as you expect. It’s odd that Microsoft forces customers to go through the additional step to enable auditing for mailboxes that appear to be already enabled for auditing, but that’s the way the system works.

Make sure that you’re not surprised about changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Document Label Mismatches With Sensitivity Labels of Different Priorities

Two years ago, Microsoft launched support for sensitivity labels in SharePoint Online, including the ability to detect a mismatch between the label assigned to an Office document and the label assigned to the site storing the file. The mismatch occurs when the document library has a higher priority than the site label. For instance, someone might upload a document labeled Highly Confidential to a site labelled General Access, or they might update a document to assign it with a label with a higher priority than the site label.

A document label mismatch mightn’t be a problem. Storing sensitive material in a site designated for less sensitive information could be exactly what the user intended to do. However, a mismatch might also create a potential issue when users with access to a site might see highly confidential material. In practical terms, the users might not be able to open the files because they don’t have the necessary rights, but they can see file metadata such as titles, authors, and so on.

Audit Record for Mismatch Missing Important Data

When it detects a document label mismatch, SharePoint Online generates a DocumentSensitivityMismatchDetected audit record in the Office 365 (unified) audit log. The audit record contains information about the:

• The file name.
• The site URL and relative location (full URL).
• Sensitivity label and priority for the document label.
• Sensitivity label and priority for the site label.

The big piece of missing information is the account name (user principal name) of the user who caused the document label mismatch. It’s not as if SharePoint Online doesn’t know who caused the problem. After all, SharePoint Online sends the miscreant an email notification (Figure 1) about the issue to prompt them to consider if a label change is necessary.

Dealing with Missing User Information

The solution exists in other audit data. When someone updates or uploads a document, SharePoint Online captures an audit event for the action. These events capture user information. Later, SharePoint detects the mismatch. SharePoint Online stores documents in lists, and each item in the list has a unique identifier. The identifier is in the audit event for the upload or change. It’s also in the event generated when SharePoint finds the mismatch. Therefore, we can reference the upload/change event to find who created the mismatch.

To illustrate the point, I wrote a PowerShell script to:

• Connect to the compliance endpoint to collect information about the labels used in the tenant.
• Build a hash table of the label identifiers and display names. The audit events log label identifiers, so we can use the hash table to find the display name.
• Search the audit log for FileUpdated, FileModified, and DocumentSensitivityMismatchDetected events. The script looks back over the last 80 days. Given the volume of FileUpdated events often found in tenants, you could reduce this period.
• Split the audit records into those for document mismatches and the other events.
• Create a hash table composed of list identifiers and usernames from the document upload and change events.
• For each of the document mismatch events, lookup the hash table to match against the list identifier and return the username responsible for the mismatch. Also resolve the sensitivity labels assigned to the document and site to the label display names.
• Report the results. Figure 2 shows typical results as viewed through Out-GridView.

The full script is available from GitHub.

Some people like to block the messages sent by SharePoint Online using an Exchange Online mail flow rule so that they can send their own notifications to users. It would be easy to take the report data generated by the script and use that information to create and send appropriate messages, perhaps using the Microsoft Graph PowerShell SDK.

Blocking Email Notifications

To stop SharePoint Online sending emails to advise users about label mismatches, you can update the tenant configuration:

Set-SPOTenant -BlockSendLabelMismatchEmail $True

The setting affects all sites. It isn’t possible to block the notification emails about mismatched labels for selected sites. Blocking emails also stops SharePoint Online writing audit events to record document label mismatches. Microsoft plans to break the link between the two actions so that a tenant can block emails without stopping the creation of the audit records, but no date is available for this update.

Audit Mystery

It’s a mystery why Microsoft decided that the DocumentSensitivityMismatchDetected shouldn’t contain the user information, I see no logic in that decision, but once you know about it, you can compensate. Isn’t PowerShell wonderful?

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Default Sensitivity Label for SharePoint Document Libraries Now Rolling Out Worldwide

Update 2 April 2023

In January 2022, I explained the process to assign a default sensitivity label to a document library in a SharePoint Online site. At the time, Microsoft was in the early days of the feature’s development and the configuration was a very manual process. Now, the public preview software is generally available worldwide. Documentation to set up and use the feature also available.

Setting a default sensitivity label is very simple. Select Library settings from the cogwheel menu and choose the desired sensitivity label (Figure 1). Naturally, you can only select a label that’s configured for file and email protection rather than those set up for container management. If you have multiple document libraries in a site, each library can use a different default sensitivity label. That’s a nice touch because usually if a site has multiple libraries, the libraries serve different purposes, and the chosen label can reflect that purpose instead of being a one-size fits-all selection.

Licensing

Although Microsoft hasn’t confirmed this, assigning a default sensitivity label to a document library will follow the usual line of regarding anything that performs an automatic action as a premium feature. Accordingly, you’ll need Office 365 E5 or Microsoft 365 E5 Compliance licenses to use the feature when it is generally available.

Update: The feature is now available and requires one of these licenses:

• Microsoft Syntex – SharePoint Advanced Management
• Microsoft 365 E5/A5/G5
• Microsoft 365 E5/A5/G5/F5 Compliance
• Microsoft 365 F5 Security and Compliance
• Microsoft 365 E5/A5/G5/F5 Information Protection and Governance
• Office 365 E5/A5/G5

PDF Files and Existing Documents

As Microsoft’s documentation explains, the reference to support for PDF files in the UI is incorrect. New Office documents uploaded by users receive the default label within a few minutes, but PDFs are ignored for now. It’s likely that Microsoft will address this issue when the feature is generally available toward the last quarter of 2022.

New documents that have labels are ignored. Existing documents already present in the library are also ignored. In other words, SharePoint Online doesn’t scan all documents and apply the default sensitivity label to any without an assigned label. However, when users edit Office documents that don’t have an assigned label, SharePoint Online will apply the default sensitivity label defined in the policy applicable to the site. This change is due in mid-October 2022.

More Changes Coming for PDFs

In June, Microsoft announced that Office applications would maintain sensitivity label support when used to create PDFs. This is part of Microsoft’s work to remove the need for organizations to deploy the now-deprecated unified labelling client to apply sensitivity labels to PDFs. According to MC387639, the public preview for this functionality should be available around about now.

An associated message center notification (MC411677, August 10 2022) lets Visual Basic for Applications (VBA) developers know that soon PDFs generated when VBA scripts use Office features will also maintain sensitivity labels for the output files. This is Microsoft 365 roadmap item 93406. Microsoft is warning that some VBA add-ins will need to be updated when the change is effective in December 2022.

Meanwhile, Adobe is running a preview program to allow its Acrobat product to apply, remove, and update sensitivity labels to PDFs. The free Adobe Acrobat DC reader product has been able to read protected PDFs (if the user has the appropriate rights granted by the sensitivity label) for several years. The new functionality is currently understood to be limited to Adobe’s paid-for products.

Sensitivity Labels Increasingly Mainline

It takes time for a new technology to become mainline. Sensitivity labels are getting there. Native (built-in) support for encryption, decryption, and rights management within apps are important steps forward. Office and PDF documents are the most common formats used within Microsoft 365. Their increasing embrace of sensitivity labels makes it easier for people to protect their most sensitive information, and that’s a good thing, even if it makes it a little harder for ISVs to process encrypted user data.

Keep up to date with developments like the app support for sensitivity labels by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Move to Clarify Microsoft 365 Compliance Licensing

Many of the new features created for Microsoft 365 compliance technology, like allowing Data Loss Prevention policies to use trainable classifiers, rely on high-end or add-on licenses. Microsoft doesn’t develop much new for the baseline Office 365 E3 enterprise plan. Everything seems to be bundled into Office 365 E5 or Microsoft 365 E5 or a new service plan.

This isn’t by accident. Microsoft is trying to drive the average revenue per user (ARPU) higher to increase cloud revenues and margin, something that CFO Amy Hood emphasizes to the market analysts every time Microsoft discusses its quarterly results. Making new features available only in high-end plans seems to be working. In their FY22 Q4 results, Microsoft reported that 12% of its Office 365 installed base now uses E5 and cloud revenues reached an annualized run rate of $100 billion.

Microsoft 365 Compliance Licensing Defined via Capability

It’s putting it mildly to say that Microsoft licensing guidelines for its compliance offerings were opaque. Confusing, misleading, inaccurate, poorly worded, and just plain wrong are other descriptions rightfully applied to Microsoft 365 compliance licensing over the years. Things weren’t helped by the way that many compliance features ignored licensing completely and allowed anyone who wanted to use a feature to go ahead and use it. Of course, using something without the right license isn’t the most intelligent strategy, especially when a software vendor tightens its code and introduces license restrictions, which is the case now.

I’ve been critical about Microsoft’s slipshod approach to licensing for Microsoft 365 compliance and security products in the past. Improvements have been coming, especially the introduction of a helpful spreadsheet to help tenants understand when they needed licenses for different features. The spreadsheet is now available in versions covering Enterprise and Frontline worker plans and Small to Medium Business plans.

Now, Microsoft has revamped their documentation for licensing guidance for Microsoft Purview Data Lifecycle and Records Management (Figure 1) to make it much clearer and easier to understand the licensing requirements for features like retention policies and retention labels. The new documentation clearly sets out the capabilities of a feature and what licenses are needed to use those capabilities.

For instance, if you want to use adaptive scopes to find locations to apply retention policies, you need Office 365 E5, Microsoft 365 E5, or either of the Microsoft 365 E5 compliance or information protection and governance add-ons. The same licenses are needed to when retention labels have settings that start retention after an event, trigger a disposition review or apply a new label when the retention period ends, or marks items as records or regulatory records.

Microsoft’s Definition of Automatic Label Processing

I like the new way of clearly setting out when advanced licenses are needed to use a feature, even if it highlights the absurdity of requiring E5 licenses to apply a default retention label to a SharePoint Online document library (Figure 2), folder, or document set. I know that Microsoft considers this to be automatic processing, and a case can be argued that the act of assigning a retention label to a document when a user uploads it to a library is automatic, but it’s hardly in the same category as auto-label policies which use artificial intelligence and machine learning (trainable classifiers) to find documents to label.

Microsoft is going down the same path with default sensitivity labels for document libraries (now in preview). I don’t agree with that decision either, but it’s likely to be the case when the feature reaches general availability.

Clarity is Best When Discussing Microsoft 365 Compliance Licensing

Now that Microsoft has clarified its license requirements for Microsoft Purview Data Lifecycle and Records Management, let’s hope that the trend continues across all aspects of Microsoft 365. Maybe even the folks who sometimes come up with the most convoluted text for message center announcements could sign up to improve their messaging. That would be very helpful indeed.

Learn about protecting SharePoint Online and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.

New SITs Focus on Credentials

Now available in tenants, message center notification MC402123 (July 19, Microsoft 365 roadmap item 88941) covers the preview of 42 new sensitive information types (SITs) designed to protect different kinds of credentials (keys, passwords, and tokens) used in IT environments, including Azure, Amazon, GitHub, Slack, and Google. Most of the new SITs are of the Credential type, and there’s one called All Credential Types that’s a bundle of all the other new credential SITs.

Microsoft has steadily been increasing the set of available SITs. In April 2021, they released a bunch of country-specific SITs, while earlier this year, they introduced the concept of a bundled entity, or a set of SITs that can be processed as a single item (hence the bundled credential entity). The new set brings the total of Microsoft-created SITs to 306.

Sensitive information types are used with data loss prevention (DLP) policies and auto-labeling policies (with the right licenses). Each SIT contains patterns and definitions to detect a specific kind of data. In this case, the new SITs focus on things like usernames and passwords, Azure AD access tokens, storage account keys, and SQL server connection strings. Using the new SITs should allow organizations to clamp down on people circulating credentials in emails and Teams messages, which is a form of data leakage that you really don’t want to happen.

Checking Out Credentials Sensitive Information Types

I cover how to create a custom sensitive information type for Azure AD passwords in this article and experienced some issues using the custom SIT in production, so I was eager to discover what Microsoft delivered in their Azure AD User Credentials SIT.

One of the ways of discovering how an SIT works is to use the Test feature built into the Purview compliance portal. Open the portal, go to Data classification, and select the SIT you’re interested in. When SITs become generally available, Microsoft usually allows you to see details of the patterns used for a SIT. For now, you can’t, but you can test an SIT by uploading a text file containing test data to see whether Purview can detect any issues with the data using the SIT.

I couldn’t get a test to work for the Azure AD User Credentials SIT, even using the guidance in the SIT documentation. To make sure that I was doing the right thing, I tried with an Azure AD access token, and that worked (Figure 1), probably because tokens follow a clearly defined structure that’s relatively easy to define in a pattern.

I’m not sure that anyone would want to cut and paste an Azure AD access token into an email or Teams chat, but I’m glad that I can detect and block this information if necessary (Figure 2).

Testing the Azure AD User Credentials SIT in a DLP Policy

To test further, I configured a DLP policy to monitor for Azure AD user credentials in Teams chat. After waiting 15 minutes or so to let the policy become effective, I made multiple attempts to share username and password information through Teams chat. As Figure 3 shows, most attempts failed.

In fact, the only time the SIT detected a problem was when I used the Microsoft 365 service domain in a username. I don’t know many tenants that use service domains for user principal names (and email addresses), so this capability is sadly disappointing to say the least. I know that creating a pattern to detect different kinds of user credentials is difficult, but it’s hardly the cutting edge of software development.

All Fixed in General Availability

Oh well, the 42 new SITs are in preview, so we can expect that everything won’t work perfectly. The fact that SITs do not do exactly what you might expect underlines the need to test sensitive information types in realistic conditions using your data. If you don’t, you might end up sadly disappointed.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Fills Gap in Current Implementation

Updated: August 15, 2022

Message center notification MC393822 (18 June – Microsoft 365 roadmap item 93209, and updated in MC412375 on August 11, 2022) informs tenants about an important change to the way sensitivity label policies apply default sensitivity labels. Up to now, if you define a default label in a policy to apply to documents (Figure 1), SharePoint Online and OneDrive for Business assign the label to new documents created in sites that come within the scope of the policy. MC412375 says that the public preview for the change will roll-out in late August and be available everywhere by mid-October.

Change Applies to Modified Files

The change Microsoft is rolling out in public preview from mid-June is to make sure that when people edit unlabeled (existing) Word, PowerPoint, or Excel files, SharePoint and OneDrive stamp the default label on the file. The functionality already works for the Office web applications and is now extending to Office on Windows and macOS.

Obviously, this is a good change for organizations that want to ensure that all documents have at least a default sensitivity label. Until now, the default label guaranteed that new documents received sensitivity labels, but this left a huge gap in terms of all the files created prior to the implementation of sensitivity labels.

Auto-label policies help close the gap because background processes can scan sites for documents and apply labels to the files if they don’t already have a label. The problem is that auto-label policies are a premium feature. However, if you have the necessary licenses, auto-label policies are a good way to achieve coverage of a large number of preexisting files.

Another change that’s coming soon is the ability to configure a default sensitivity label for a document library, much like you can do with retention labels. Again, this is a premium feature and it’s likely to require Office 365 E5 or Microsoft 365 Compliance E5 licenses.

API to Bulk Apply Sensitivity Labels

One missing piece in the puzzle is the lack of an API to allow organizations and ISVs to create applications to apply sensitivity labels in bulk. Microsoft’s AIP Scanner is an example of such an application. The scanner can apply sensitivity labels to protect information found on file shares or SharePoint on-premises sites. Other use cases include tenant-to-tenant migrations where the need might exist to apply sensitivity labels to a set of documents inherited from a tenant belonging to a company being acquired. There’s nothing off-the-shelf that can handle such a scenario today, and the prospect of having to apply labels manually is unattractive.

Apparently, an API is coming, but it will be a paid-for consumption-based API like that available for Teams Export. In other words, you’ll be able to build an application to apply sensitivity labels to a bunch of files (probably throttled at a certain level to reduce strain on the service), providing you have an Azure subscription to pay the bills.

Making Sensitivity Labels Mainstream

Sensitivity labels are still relatively uncommon inside Office 365 tenants. Microsoft is the only source that can definitively say what percentage of tenants use sensitivity labels or how much of their content have labels. Changes to allow tenants apply sensitivity labels more effectively by default, or to spread sensitivity label support more widely (like the work done to make it easier to protect PDFs) help to encourage more organizations to consider sensitivity labels to be a mainstream part of their overall information protection strategy. However, it’s still going to take time before sensitivity labels become the norm inside Microsoft 365.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

PowerShell is the Only Way to Create Policy Exclusions

In most cases, organizations want to publish sensitivity labels to all users. This makes sense because it means that everyone has access to the same set of sensitivity labels to protect content. The Microsoft Purview compliance portal makes the task easier by supporting the special All destination as a target for a sensitivity label policy, meaning that the policy includes all mailboxes. Alternatively, you can choose to publish labels to selected groups or individual users (Figure 1).

No GUI for Policy Exclusions

You might notice that the GUI for sensitivity label policy publication doesn’t support the exclusion of specific users (mailboxes) when a policy uses the special All destination. In other words, stop a few mailboxes from seeing the labels in applications like OWA and OneDrive for Business. For instance, you might want to publish organization-wide sensitivity labels to all mailboxes except those belonging to a certain department, possibly because no business reason exists for the personnel in that department to apply sensitivity labels to documents or messages.

It’s worth noting at this point that publication allows people to apply sensitivity labels to items. A user doesn’t need to be a target location in a label publishing policy to access content protected by sensitivity labels published by the policy. Any Microsoft 365 account can read content if the label protecting the content grants them the right to do so.

It’s curious that Purview doesn’t include the GUI to allow administrators to apply exclusions to sensitivity label policy. The equivalent GUI for retention label publishing policies includes exclusions, and although retention labels and sensitivity labels serve different purposes, managing their deployment is broadly similar.

Using PowerShell to Add Exclusions to a Sensitivity Label Policy

What’s also curious is that the PowerShell Set-LabelPolicy cmdlet can set exclusions for sensitivity label policies. For example, after connecting to the compliance endpoint, this command excludes the mailboxes of Terry Hegarty and Kim Akers from receiving the labels published in the specified policy:

Set-LabelPolicy -Identity "General Sensitivity Policy" -AddExchangeLocationException "Terry.Hegarty@Office365itpros.com", "Kim.Akers@office365itpros.com"

Get-LabelPolicy -Identity "General Sensitivity Policy" | Select-Object ExchangeLocationException

ExchangeLocationException
-------------------------
{Kim Akers, Terry Hegarty}

Adding a mailbox to a label publishing policy in this manner does not overwrite the set of excluded mailboxes. The exclusion of a mailbox from a label publishing policy doesn’t take effect immediately. Outlook clients must refresh their cache of information from the Information Protection service. When that happens, users won’t be able to apply the labels to new emails.

To remove an excluded mailbox, run Set-LabelPolicy and pass the mailbox name in the RemoveExchangeLocationException parameter.

Set-LabelPolicy -Identity "General Sensitivity Policy" -RemoveExchangeLocationException Kim.Akers

Processing Multiple Exclusions for Sensitivity Label Policies

Running the Set-LabelPolicy cmdlet to add more than a few excluded mailboxes can become tiresome. In these circumstances, it’s better to find the set of mailboxes using Get-ExoMailbox or another method (like reading the members of a distribution list) and pipe the set of mailboxes to Set-LabelPolicy.

For example, let’s assume that you want to exclude all the members of a department and that they’re all part of a distribution list. Finding the members of a distribution list is a well-trodden path and the Get-DistributionGroupMember cmdlet is what we need to use in this case. Adding all members of a distribution list is simple. First, extract the primary SMTP addresses for the members and store them in an array. Then, pass the array to Set-LabelPolicy. For example, this code extracts the user mailboxes from the membership of a distribution list and uses the array to create exclusions.

[array]$Members = Get-DistributionGroupMember -Identity "Planning Department" | Where-Object {$_.RecipientTypeDetails -eq "UserMailbox"} | Select-Object -ExpandProperty PrimarySmtpAddress
Set-LabelPolicy -Identity "General Sensitivity Policy" -AddExchangeLocationException $Members

Microsoft 365 Groups only support user mailboxes in their memberships, so you don’t have to filter the members from those groups.

Some formatting is necessary to make a long list of excluded mailboxes easy to read. Here’s what I normally do:

[array]$Exclusions = Get-LabelPolicy -Identity "General Sensitivity Policy" | Select-Object -ExpandProperty ExchangeLocationException
$Exclusions.Name

Andy.Ruth@office365itpros.com
Kim.Akers@office365itpros.com
Brian.Weakliam@office365itpros.com
James.A.Abrahams@office365itpros.com
Marc.Vigneau@office365itpros.com
Terry.Hegarty@office365itpros.com
Jane.Sixsmith@office365itpros.com
Lotte.Vettler@office365itpros.com

It’s possible that Microsoft might update the compliance portal GUI to support the addition of exclusions for sensitivity label policies. In the interim, you can do it with PowerShell.

Learn about protecting Exchange Online and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.

OneDrive for Business is Popular Storage for Microsoft 365 Applications

Microsoft 365 applications use OneDrive for Business for all kinds of purposes apart from being the place for users to store personal files. Whiteboards, Team meeting recordings, and Loop components are three application usages of its storage, including being deleted through the OneDrive for Business Recycle Bin. The net takeaway is that Microsoft 365 treats OneDrive for Business as a great location to hold many types of application data.

One big reason why is that once data is in OneDrive for Business instead of other repositories like the Azure-based blob storage originally used by Stream, the information is fully exposed to all the Microsoft 365 compliance, data governance, and lifecycle management functionality. Microsoft Search indexes the files stored in OneDrive for Business to make the content discoverable, and functionality like Microsoft Purview core and premium eDiscovery can interrogate the information when the need arises for an investigation.

Odd Statement in Microsoft Documentation

All of which then means that the statement in Microsoft documentation (Figure 1) saying “The Recycle Bin is not indexed and therefore searches do not find content there. This means that an eDiscovery hold can’t locate any content in the Recycle Bin in order to hold it” will probably come as an unpleasant surprise to compliance administrators.

In a nutshell, Microsoft’s text implies that people can hide information they don’t want eDiscovery searches to find or hold by keeping it in the OneDrive for Business Recycle Bin. This might happen serendipitously (the user doesn’t realize that data governance oversight doesn’t apply to files in the OneDrive recycle bin) or deliberately (they do and want to take advantage of the fact). Either way, it’s not a good situation.

OneDrive Data Found by Content Searches

Such an assertion caused me to test if Microsoft 365 content searches (separate or as part of a standard eDiscovery case) can find items stored in the OneDrive for Business Recycle Bin. All my efforts to uncover a situation where a content search couldn’t find an item failed. Holds appear to work as well, and a retention label (a form of hold) doesn’t disappear when an item moves into the Recycle Bin.

I have no idea what Microsoft’s text means in practice. Perhaps some condition exists to prevent Microsoft Purview from placing a hold on items found in OneDrive’s recycle bin, but one thing is for sure, contrary to the documentation, searches can find items in OneDrive’s recycle bin (Figure 2).

To test retention, I deleted an item from the first- and second-stage recycle bin. The item ended up in the OneDrive preservation hold library (select Site Contents from the cogwheel menu and you can open the library), and the item was there, waiting for its hold to expire.

Indexing of the Recycle Bin

It’s possible that the statement saying, “The Recycle Bin is not indexed” is accurate. It could be that the items in the recycle bin are in the index because Microsoft Search processed them in their original location. The OneDrive for Business browser interface doesn’t offer an option to create a file in the recycle bin, and while it might be possible to do such a thing using an API (those working on PnP might have a view on this), it would be an unusual thing to do. Maybe even a suspicious action too because what logical reason exists to create a file in a recycle bin?

Documentation Isn’t Always Accurate

This experience underlines once again that you cannot assume that documentation is 100% accurate, even if published with Microsoft’s imprimatur. It all depends on the knowledge and experience of the writer, especially their familiarity with the topic. And even people with bags of experience with a specific technology can screw up when it comes to describing how something works. A slip of the finger on the keyboard, a badly phrased sentence, or just an error in writing are all part and parcel of the writer’s life.

Make sure that you’re not surprised about changes that appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

But Only for Premium eDiscovery

Yesterday, I discussed how to count the Teams compliance records captured by the Microsoft 365 substrate in a tenant. I wrote about this topic because of MC387229, posted on May 31, which informs customers that Microsoft Purview Advanced (Premium) eDiscovery will soon uncover the reactions to Teams messages. This is Microsoft 365 roadmap item 65130 and it’s due for preview in June and general availability in August 2022.

The Problem of Reactions

eDiscovery searches can easily find the content of Teams messages. That’s been the case since Teams first started to accumulate these records in 2017. However, since that time, Microsoft has struggled to find a way to let investigators know about reactions to messages. This is important because someone participating in potentially problematic activities might indicate their willingness to perform an action through a reaction.

Take the example shown in Figure 1. Someone proposes murder and assent comes in the form of a thumbs-up reaction. This is an important signal that indicates the state of mind of the respondent. The problem for investigators is that compliance records don’t capture the reaction.

The Formal Story

In 2019, Microsoft commissioned a report from Cohasset Associates about how Microsoft 365 meets regulatory requirements for data lifecycle management and records management in the financial sector. Specifically, SEC17a-4(f), FINRA 4511©, and CFTC 1.31 (c)-(d). The report is available as part of Microsoft’s records management documentation, but you can only download the report from the Microsoft 365 Service Trust site if you have an account from a tenant. The latest version of the report is dated 2 November 2020, and it contains the rather startling assertion that:

“Reactions (e.g., likes, thumbs up) applied to Teams channel messages and Teams chats are tracked in the Microsoft 365 unified audit system…”

The report repeats the same statement multiple times. However, I’ve never seen any evidence of audit records for reactions. Clearly, the authors were misinformed on this point.

Later (2.4.3.1), the report says that “reactions… are not captured as a communication in Exchange. Therefore, the reaction history cannot be reproduced with the communication.”

In other words, the compliance records captured in Exchange Online don’t contain reactions. The report makes the same point in 2.4.4. and the conclusions.

Over the years, Microsoft has committed to closing this compliance gap, and that’s what is due to happen when the feature announced in MC387229 arrives.

Where are the Reactions?

All we’re told for now is that eDiscovery will be able to discover Teams reactions to provide “additional user sentiment context.” There’s no mention of how this will happen.

However, we know that responding to a chat or channel conversation with a reaction does not cause the Microsoft 365 substrate to capture any information. By comparison, if you update a message in a chat or channel conversation, the substrate captures a copy of the edited message.

This behavior makes me think that Premium eDiscovery makes a request to Teams to return reactions along with message contents when viewing items recovered in an eDiscovery collection (the set of items found by a search). This makes sense because it’s like the call made by a Teams client to load messages in a conversation.

No Luck for Standard eDiscovery

Microsoft hasn’t said if the ability to see reactions alongside Teams messages will appear in standard eDiscovery. I don’t think this will happen. Standard eDiscovery searches return relatively raw material (the compliance records captured by the substrate) and don’t attempt to present the information in context (reassemble items to form a coherent message thread), which is a big added value delivered by Premium eDiscovery. Given this logic, I’m afraid you need to invest in some Office 365 E5 or Microsoft 365 E5 compliance licenses to close this Teams compliance gap and see reactions in eDiscovery.

Keep up to date with developments like changes in eDiscovery and Teams compliance capabilities by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Options for Dealing with Leaver Mailboxes

When someone leaves an organization, a discussion often takes place about what to do with their mailbox and other data. For Exchange Online, the choice is straightforward:

• Delete mailboxes.
• Keep the mailboxes and let someone else take over the Azure AD accounts (and mailboxes).
• Change mailboxes to become shared mailboxes.
• Preserve them as inactive mailboxes.

Usually, the choice comes down to either a shared or inactive mailbox. Of course, the mailboxes belonging to ex-employees store other personal information in places like OneDrive for Business and Teams chat. Other information, like the documents kept in SharePoint Online sites, is by definition shared and remains accessible to other users. This discussion focuses on what to do about “leaver” mailboxes.

Shared Mailboxes

Shared mailboxes have existed in Exchange for a long time and are well understood. The advantages of transforming a user mailbox to be a shared mailbox are:

• The mailbox remains online and is accessible using any Outlook client. It appears in Exchange address lists like the GAL and can continue to receive inbound emails.
• Users can receive permission to access and recover mailbox contents. If necessary, administrators can grant users Send As and Send on Behalf Of permissions to allow them to send emails from the shared mailbox.
• When a user mailbox becomes shared, it no longer needs an Exchange Online license unless it is larger than 50 GB or has an archive.
• If necessary, administrators can easily change the mailbox back to become a regular user mailbox. At this point, it must have an Exchange Online license.

Changing a mailbox to be shared is a good approach when it’s necessary for other users to take over responsibility for the work of a departed employee. For example, the manager of a sales representative who leaves the organization needs to follow up on customer engagements and commitments. Privacy can be a big concern when someone gains access to another person’s mailbox because there’s probably some personal material among business-related emails. For this reason, organizations often limit access to a mailbox for a set period after which the mailbox is deleted.

Inactive Mailboxes

In an on-premises organization, it doesn’t matter if leaver mailboxes remain online. Licenses are not required because no one uses the mailboxes. If storage is available, leaver mailboxes can stay in place for as long as the organization wishes.

The situation is different within Office 365 as Exchange Online removes unlicensed mailboxes soon after the deletion of their owner’s Azure AD accounts. To make it possible for organizations to retain leaver mailboxes for compliance purposes, Microsoft introduced inactive mailboxes several years ago. If a hold applies to a mailbox or retention labels with holds exist on items in a mailbox, Exchange Online won’t delete the mailbox following the removal of its owner’s account. Instead, Exchange Online puts the mailbox into a hidden and inactive state. The content of the mailbox remains indexed and discoverable and can be found by eDiscovery searches.

The important things to remember about inactive mailboxes are:

• Inactive mailboxes remain online until the last hold (policy or retention label) lapses or an administrator removes a litigation hold on the mailbox. At this point, Exchange Online will retain the mailbox in a soft-deleted state for a further 183 days and then permanently removes the mailbox. Inactive mailboxes don’t need any type of license. Microsoft is reducing the recovery period to 30 days from September 2022 (it won’t make much difference).
• Inactive mailboxes are invisible to normal client interfaces, like OWA and Outlook desktop. They do not appear in Exchange address lists and cannot receive new emails.
• The complete content of a mailbox remains available when it becomes inactive, including its archive and the compliance records captured by the Microsoft 365 substrate for Teams, Yammer, and Planner.
• To access mailbox content, administrators must either recover or restore an inactive mailbox. Recovering an inactive mailbox makes it active and usable again. Restoring means that material from the inactive mailbox (or its archive) is merged into another mailbox.

Essentially, inactive mailboxes are a compliance tool. They facilitate long-term storage of mailbox content to ensure that the material in the mailboxes remains accessible if necessary. Inactive mailboxes are a good way to keep mailboxes of senior employees and other staff subject to regulatory oversight for extended periods. Figure 1 shows a tenant with shared mailboxes going back to February 2015 as viewed through the Microsoft 365 Purview portal.

If you have the licenses needed to use adaptive scopes with Microsoft 365 retention policies, you can create a user scope for inactive mailboxes. If the organization has the need to keep mailboxes for an extended period (say, five years), it’s a good idea to create a retention policy with a five-year retention period and an adaptive scope targeting inactive mailboxes. That way, even if the retention period for other holds and retention labels expire, you’ll know that Exchange Online will retain the inactive mailboxes for the required period.

The Choice is Clear

GUI access to inactive mailboxes is via the Microsoft Purview compliance portal. That gives you a good clue about the essential choice between inactive and shared mailboxes. If you want to keep information because it’s needed to satisfy some regulatory or legal requirements, use inactive mailboxes. But if the organization needs information in a mailbox for immediate business reasons, transforming a leaver mailbox into a shared mailbox is a better choice.

Learn about Exchange Online and the rest of Office 365 by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s important and how best to protect your tenant.

Second Major Issue with Exchange Online Audit Data

On May 19, Microsoft published Microsoft 365 message center notification MC382148 to disclose that an eight-week hiatus in generating audit events for delegated email send activity had happened. According to Microsoft, between January 28, 2022, and March 26. 2022, “some audit log entries were not generated for the Send As and Send on Behalf of delegate scenarios.” These events are captured when people use the Exchange SendAs and SendOnBehalfOf permissions to send email for other mailboxes.

Microsoft says that the root cause is a change in logging telemetry within auditing services. A fix is now in place to “help us minimize the possibility of an event like this happening again and will expedite future investigations.” However, because Exchange Online never generated the events, the Office 365 audit log never ingested the data, and the information is not in the log. Microsoft says that the missing data is irrecoverable.

This isn’t the first time that Microsoft has had a longstanding problem with ingestion into the Office 365 audit log (or unified audit log) for Exchange Online events. In September 2018, the developers knew of a problem with truncated data for group creation events. Microsoft didn’t fix that problem until May 2019.

Checking SendAs Events

To check the current situation, I searched for SendAs audit events in my tenant and found some generated during the problem period. I also ran a script that I’ve used in the past to report on these events and found some “interesting” information in the audit events. Here’s an example of a message sent by me on May 16 using Outlook mobile:

CreationTime          : 2022-05-16T11:03:47
Id                    : b5c89d0a-bb88-4620-6df9-08da372bc089
Operation             : SendAs
OrganizationId        : b662313f-14fc-43a2-9a7a-d2e27f4f3478
RecordType            : 2
ResultStatus          : Succeeded
UserKey               : 1003BFFD805C87B0
UserType              : 0
Version               : 1
Workload              : Exchange
ClientIP              : 2a01:b340:63:7141:a5cd:a160:e805:aae7
UserId                : Tony.Redmond@office365itpros.com
AppId                 : 27922004-5251-4030-b22d-91ecd9a37ea4
ClientIPAddress       : 2a01:b340:63:7141:a5cd:a160:e805:aae7
ClientInfoString      : Client=OutlookService;Outlook-iOS/2.0;
ClientRequestId       : 5009
ExternalAccess        : False
InternalLogonType     : 0
LogonType             : 2
LogonUserSid          : S-1-5-21-458367025-2064581115-2950179075-392557
MailboxGuid           : 0370f354-2752-4437-878d-cf0e5310a8d4
MailboxOwnerSid       : S-1-5-21-458367025-2064581115-2950179075-392557
MailboxOwnerUPN       : Tony.Redmond@office365itpros.com
OrganizationName      : Office365itpros.onmicrosoft.com
OriginatingServer     : DB7PR04MB4410 (15.20.4200.000)
SessionId             : 3431534d-331e-4924-b324-cbfa9cc55e24
Item                  : @{Id=LgAAAAAdhAMRqmYRzZvIAKoAL8RaDQA3tTkMTDKYRI6zB9VW59QNAAVriOkWAAAJ; InternetMessageId=<DB7PR04MB4410C9FC675493950D68FE668BCF9@DB7PR04MB4410.eurprd04.prod.outlook.com>; ParentFolder=;Sensitivity=2fe7f66d-096a-469e-835f-595532b63560; SizeInBytes=4428; Subject=Phone number}
SendAsUserMailboxGuid : 0370f354-2752-4437-878d-cf0e5310a8d4
SendAsUserSmtp        : Tony.Redmond@office365itpros.com

Three Properties with the Same Value

The problem with this audit record is that the User, MailboxOwnerUPN, and SendAsUserSmtp properties all have the same value. When a delegate impersonates another user to send a message, Exchange Online logs the delegate’s name in the User and MailboxOwnerUPN properties and captures the SMTP address of the impersonated user in the SendAsUserSmtp property. Having the same value in the three properties doesn’t make sense.

A closer examination of the SendAs events in the audit log revealed multiple cases where the three properties had the same value. Most of the events originated using the Outlook mobile client and, in all cases, the mailbox owner sent the message. There’s no reason why Exchange Online should consider this message to be a SendAs event because the mailbox owner sent the message. A common feature of all the messages logged erroneously as SendAs events is that they were addressed to external recipients.

Tests revealed that audit events for delegate messages sent using the Send As permission from the OWA and Outlook desktop clients capture the correct information. However, despite being present in the Exchange Online mailbox audit log, messages sent using delegate access from Outlook Mobile didn’t show up in the Office 365 audit log.

Interestingly, SendAs events also appeared for messages sent by mailbox owners from the preview version of the One Outlook client for Windows (Monarch). This client uses the same Microsoft sync technology connection as Outlook mobile does, so perhaps that’s where the issue lies. Figure 1 shows Exchange SendAs events from the audit log. The instances were owners sent messages rather than delegates are highlighted. All instances used the Outlook Mobile or Monarch clients.

In summary, two problems were found:

• Messages sent using delegate access from Outlook Mobile are not captured in the Office 365 audit log.
• Exchange Online captures messages sent by mailbox owners to external recipients using Outlook Mobile and Outlook Monarch in the Office 365 audit log as Send As events..

It’s an odd situation that appears to go back to at least February 2022. I guess no one noticed because we all accepted the validity of SendAs events in the audit log.

Problems Persist With Exchange SendAs Audit Data

Organizations depend on audit data to know what happens inside their tenants. Delegate email action are often examined to answer questions like “who sent that message,” and can make important contributions to compliance investigations.

Microsoft needed several attempts to fix the truncated audit record problem in 2018-2019. Now we have another instance where a longstanding problem with audit events generated by Exchange Online results in data loss and some odd results in audit data generated by Outlook mobile and Monarch clients. Testing software in the age of the cloud certainly appears to be a lost skill.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the ultimate eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Same Issue Exists for Teams and OWA

I’m still waiting for the arrival of Loop components in OWA. After writing about the announcement of Loop support for OWA in MC360766, I was asked about the eDiscovery and Compliance issue reported in the message center post and why some organizations might block the use of Loop components until Microsoft delivers a solution.

The same problem exists for Loop components created in Teams chat. Let me explain what the problem is by going through an example.

Creating a Problem in a Loop Component

First, we create a compliance issue in a Loop component posted in a Teams chat. In this case, it’s a conversation about potentially fraudulent activity (Figure 1) in a Loop paragraph. The physical storage for the component is in a fluid file stored in the originator’s OneDrive for Business account. Like other files shared in chats, the file is in the Microsoft Teams Chat Files folder.

It’s worth noting that Teams DLP policies do not currently check the content of Loop components. For instance, if the organization deploys a DLP policy to prevent users from sharing credit card numbers, it blocks this activity in regular chats, but not in Loop components.

Searching for Loops

I then opened the Microsoft Purview Compliance portal and created a new content search to look for any file or email containing the keyword “Arkana” as used in the Loop component. The search found three items, including one called “The Plan” (Figure 2).

As I note in a discussion about using Loop components in Teams chat, the Microsoft 365 substrate generates compliance records for messages posted in Teams chats. Although the substrate captures compliance records for messages containing loop components, they are empty apart from a link to the fluid file in their source OneDrive for Business account. For this reason, the compliance records do not appear in search results.

Accessing Loop Component Content

The content search preview does not support files containing loop components and displays the error:

“This document type is not supported by preview.”

To view the content, you can download a copy of the file from the search preview. This creates a file without an extension that cannot be opened. To solve the problem, I did the following:

• Gave the file the same fluid extension (e.g., The Plan.fluid) as used when Teams stores files containing Loop components in the Microsoft Teams Chat Files folder in OneDrive for Business.
• Moved the file into my OneDrive for Business account. Any folder will do.
• Double-clicked on the file. Office.com opened and displayed the contents (Figure 3).

The good news here is that an investigator can at least download Loop components from a content search preview to examine their contents. The bad news is that this needs to be done on a file-by-file basis.

Exporting Loops in Search Results

After using search preview to make sure that a search locates results that they want, the next step for compliance investigators is to export search results. A preview is just that: a snapshot of what to expect when a search runs. Before an export can happen, Microsoft 365 runs a full search. This might find items overlooked in the preview. In our test, the export included the fluid file containing the interesting content (Figure 4).

The problem now starts to become obvious. You can’t open a fluid file from exported search results. You can if you copy the file to your OneDrive for Business account, but not in its export location. I suspect that this is due to permissions. When you move or copy a fluid file into your OneDrive for Business account, you have full control over it. Left in the search export location, metadata containing permissions in the file likely stops someone from opening it unless they have permission to.

This causes a huge problem for investigators. It might be workable for internal investigators to copy discovered fluid files to their personal OneDrive for Business account to review the files there. It’s not feasible for external investigators and experts to do the same, especially if they don’t have access to OneDrive for Business or want to work offline.

I believe this is the reason why Microsoft is working on “an offline consumable export format.” In other words, as the search export process extracts copies of files containing Loop components from their source locations, it will create something like a PDF version of the files. If this doesn’t happen soon, more organizations will consider blocking Loop components for all Microsoft 365 apps, adding to Microsoft’s difficulties in convincing people that this method of collaboration is a real advance.

Same Issue for Emails

The same issue will occur in emails with embedded Loop components. These files will probably live in the sender’s OneDrive for Business account with permissions granted to all recipients to interact with the components. Microsoft will need to do the same magic to convert Loop content in emails to something consumable outside the tenant.

Of course, quite how this scheme works when external recipients are part of the addressee list remains to be seen. It might be that these recipients see a static version of the Loop content. I’ll let you know when OWA support for Loop components becomes available.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Helping People Build Better KQL Queries, One Search at a Time

In May 2021, Microsoft introduced a new user interface for content searches (including core eDiscovery) in the Microsoft 365 compliance center. At the time, I was critical about the change because the new interface is slower and (still) buggier than the old. Nevertheless, change is an ongoing influence in cloud services, and you’ve got to imagine that the developers introduce nee features or upgrades to existing capabilities for good reason. At least, that’s the theory.

Which brings me to a change which happened some time ago that I completely overlooked. Message center notification MC288050 (October 4) announced the arrival of a Keyword Query Language (KQL) editor to help compliance administrators build queries for content searches, including the searches used in core eDiscovery and advanced eDiscovery. Microsoft 365 roadmap item 88582 reports that the KQL editor is still in preview as of November 2021.

Condition Card Builder

Put simply, the value of the KQL editor is that it stops people making mistakes when they compose queries for content searches. Up to now, building a query involved handcrafting the set of keywords and conditions necessary to find information. The GUI offered some help, such as date pickers to set a date range for a query, but not much. The roll-your-own query facility is now referred to as the condition card builder and it’s still available for those who like composing KQL queries. Figure 1 shows a query using two keywords (search terms) and a condition.

The KQL Editor

You can switch between the condition card builder and KQL editor as often as you like. In this instance, switching to the KQL editor reveals the query created using the entered keywords and conditions. In effect, we have a starting point to refine the query (Figure 2).

Let’s say that we’re only interested in Word documents which contain the keywords. Type AND to add a new clause and then at least the first two characters of a property to search against. The KQL editor then proposes the matching conditions and operators (like :, for equals) which can be used. Microsoft refers to these hints as “property restrictions.” The hint used in Figure 3 is “file” because we want to search for a specific file type. The KQL editor suggests autocompletion of matching properties, and we can select Filetype: and then docx to complete the condition.

If the KQL editor notices a syntax error or some missing element, it flags the issue and tells you what the problem is (Figure 4). The experience is somewhat like that of editing code using an ISE and makes it easy to ensure that a query is valid and will run when submitted for processing.

Another interesting facility is the autocompletion for user principal names when searching based on email recipients (Figure 5). This works for the From, To, Recipients, and Participants properties. The names come from the tenant’s Azure AD and include guest accounts.

You can also copy and paste queries from other searches to use as the basis for a new search. This isn’t a huge advantage for simple searches, but it saves time when you deal with complex, multi-condition search queries. After pasting a query into the KQL editor, the editor checks the query to make sure that it doesn’t contain errors.

A Step Forward

The KQL editor is a nice addition to content searches. Even with the error checking done by the KQL editor, it’s still possible to create queries that just don’t work. For instance, I was able to compose this query in the KQL editor, which accepted the syntax without any problem:

“Azure B2B Connect*” AND “Teams” AND (filetype:”doc OR filetype:pdf”) AND LastModifiedTime=”this year” AND (from:James.Abrahams@office365itpros.com OR from:Ben.James@Office365itpros.com)

The filetype condition has quotation marks in the wrong place and the query mixes email and document conditions together (the Author property is more appropriate to search for documents).

In any case, you can’t expect to disengage your brain entirely when composing search queries. The KQL editor helps, but humans need to create and check the queries and validate that the result results are those expected.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Feature Became Generally Available in July 2022

According to a LinkedIn post by Microsoft Principal Program Manager Sanjoyan Mustafi, administrators will soon be able to assign default sensitivity labels to document libraries in SharePoint Online and OneDrive for Business. The capability is in private preview at present, but Microsoft 365 tenants can sign up to join the preview here.

Update: According to message center notification MC391948 (June 13), rollout of the public preview of setting a default sensitivity label for a document library will roll out in late June. This is Microsoft 365 roadmap item 85621.

Update 2: On July 29, Microsoft announced that the roll-out for the public preview code had begun and that all tenants would receive the update within 90 days. The documentation is also available.

Today, you can require that users add a sensitivity label to documents and define a default label to use. This is done through settings of the sensitivity label publishing policy which makes labels available to users. Requiring documents to be labelled works, but you don’t know what labels users will choose. Sometimes, it might be necessary to ensure that every document in a library receives the same sensitivity label to reflect the level of confidentiality of the library, and that’s where the new capability comes in.

The Backend to Apply Sensitivity Labels

The preview includes the back-end code to define a default label and apply it to new Office documents uploaded or copied to or saved in a library. An asynchronous thread examines new items to check if they already have a sensitivity label. The stamping of the default sensitivity label on new items by the thread can take a few minutes.

If a new item already has a user-applied sensitivity label, the thread ignores the document based on the principle that explicit assignment by users always takes precedence over automatic assignment. If the item has a label of a lower priority (sensitivity labels have a priority order from 0 to n, with 0 being the lowest) received through automatic assignment (usually because a label publishing policy mandates the application of a default label), the thread replaces the label and applies the default label defined for the library.

For now, labeling only happens for new Office documents (support for PDFs will come later). Existing documents remain untouched, and you must apply labels manually if you want all documents to have the same label. However, in the future, Microsoft plans to update the code so that SharePoint will apply labels whenever a user opens an unlabeled document in a library with a default label.

Note that a user can remove the default label assigned for the library or replace it with a label of higher or lower sensitivity. In these cases, the user-assigned label remains, again following the principle of user precedence.

Update: Figure 1 shows the UX to configure a default sensitivity label for a document library. To access this screen, go to Library settings.

Configuring for Default Sensitivity Labels

Prior to Microsoft delivering the UX to configure a default sensitivity label for a document library, you had to update the configuration of the target document library using the SharePoint API. You can do this with Postman (the tool favored by Sanjoyan), but I prefer PowerShell, which is what I used. Sanjoyan explains the procedure in his post, but briefly is:

• Get a bearer token to authenticate with SharePoint Online. You can copy the token if you’re logged into SharePoint Online by using the developer tools (F12).
• Create a header structure to hold details of the transaction, including the bearer token.
• Create a body structure to define the GUID of the sensitivity label you want to add as the default for the library. Use Connect-IPPSSession to connect to the Compliance center endpoint and run Get-Label to find the list of labels. The GUID for each label is in the ImmutableId property.

Get-Label | Format-List DisplayName, ImmutableId

• POST to the URL for the document library using the header and body defined earlier.

The commands I used to update a document library were:

$headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]"
$headers.Add("Accept", "application/json;odata=verbose")
$headers.Add("Content-Type", "application/json;odata=verbose")
$headers.Add("X-HTTP-Method", "MERGE")
$headers.Add("If-Match", "*")
$headers.Add("Authorization", "Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6IkRya21Mczl1akhnMkp1SE5CRm5vOERicXBJSSJ9.eyJhdWQiOiIwMDAwMDAwMy0wMDAwLTBmZjEtY2UwMC0wMDAwMDAwMDAwMDBAYjY2MjMxM2YtMTRmYy00M2EyLTlhN2EtZDJlMjdmNGYzNDc4IiwiaXNzIjoiMDAwMDAwMDMtMDAwMC0wZmYxLWNlMDAtMDAwMDAwMDAwMDAwIiwibmJmIjoiMTY0MzMxNTU5MiIsImV4cCI6IjE2NDMzMTkxOTIiLCJ1cG4iOiJ0b255LnJlZG1vbmRAcmVkbW9uZGFzc29jaWF0ZXMub3JnIiwicHVpZCI6IjEwMDNCRkZEODA1Qzg3QjAiLCJjYWNoZWtleSI6IjBoLmZ8bWVtYmVyc2hpcHwxMDAzYmZmZDgwNWM4N2IwQGxpdmUuY29tIiwidmVyIjoiYnJvd3NlciIsInRpZCI6ImI2NjIzMTNmLTE0ZmMtNDNhMi05YTdhLWQyZTI3ZjRmMzQ3OCIsImFwcGlkIjoiYzU4NjM3YmItZTJlMS00MzEyLThhMDAtMDRiNWZmY2QzNDAzIiwiYXBwX2Rpc3BsYXluYW1lIjoiU2hhcmVQb2ludCBPbmxpbmUgQ2xpZW50IEV4dGVuc2liaWxpdHkiLCJzY3AiOiJGaWxlcy5SZWFkV3JpdGUuQWxsIFNpdGVzLk1hbmFnZS5BbGwgU2l0ZXMuRnVsbENvbnRyb2wuQWxsIFRlcm1TdG9yZS5SZWFkV3JpdGUuQWxsIiwiaXBhZGRyIjoiNTEuMTcxLjIxMi4xMjkiLCJzZXNzaW9uaWQiOiIzYzdiMjUzYy0zNmJjLTQ1ZTctYmQ4OS1mNGRhZjdkZjZhNmEiLCJzaWduaW5fc3RhdGUiOiJbXCJrbXNpXCJdIn0.m0VNYiAPfu7GKuTcnAi0hc4ay7TAQ-KzlH1g3hRzRzJZccoLeRepey8k7ydNHsvdhO8N0E4mMEEz3dD8Tk-1qreBzNrqPkB6p2s8hGF1J04RaR6vkyTqJypFXLRXgmSsVrPsX1huNnkwZ0d_ShmPowUToZk_HN0MrDRIEleCks32pg1nQs2Umk63BkWAaUHJy_pLhYJOea0uzSc7iPeVpPaAQ8PbK8K4eRJX__DEByQueUSOd21V9O6KJ9ey-JasryPiqtncFUDGrofQ6EZztjwaCAjQubRv7RjOkMYeucgsgiI7cvfuvuCzcXjc6oqdosZwc-18Uurq_8r8ks9c4A")

$body = "{
`n `"__metadata`": {
`n `"type`": `"SP.List`"
`n },
`n `"DefaultSensitivityLabelForLibrary`": `"27451a5b-5823-4853-bcd4-2204d03ab477`"
`n}
`n"
$Uri = 'https://office365itpros.sharepoint.com/sites/Office365Adoption/_api/web/lists/GetByTitle(''Documents'')'
$Update = Invoke-RestMethod -Method 'Post' -Headers $Headers -Body $Body -Uri $Uri

Formatting of these commands must be precise, and the bearer token must be valid or the update will fail (I know, because I made many mistakes before doing it just right). The easiest way to make sure is to open the site you want to update in a private browser window to force a recent authentication and then copy the token (use F12 in Edge and access Local storage, then copy the value of the key for the identity for SharePoint Online as shown in Figure 2).

After configuring a default sensitivity label, it’s a good idea to change the default view for the library to include the sensitivity label to remind users that documents now have labels.

Steady Progress

Sensitivity Labels and SharePoint Online had a rocky start. There was a time when the content of protected Office documents was inaccessible to search and eDiscovery. That’s in the past (if you enable support) and Microsoft is busy filling out all the details that make software more useful. Adding a default sensitivity label to document libraries is a nice step forward but remember that using this capability will require Office 365 E5 or above, just like all the other auto-label application features in Microsoft 365.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.

Even For Tenants Who Don’t Use Records Management

Records management is a Microsoft solution to help enterprises manage items (email, documents, and lists) marked as formal company records. Office 365 E5 or Microsoft 365 compliance licenses are required to implement the Records management solution, but Microsoft uses the Settings section of Records management to host the GUI for controls over how SharePoint Online and OneDrive for Business work for retention processing. Today, three important controls for retention labels are available (Figure 1).

The settings apply to all sites in a tenant (no site-specific controls ae available). These are:

• Deleting content labeled for retention: Until recently, SharePoint Online blocked users from deleting labeled items while OneDrive for Business allowed them to do so. To achieve consistency across the two applications, Microsoft changed SharePoint Online to behave like OneDrive for Business, meaning that users can delete labeled items and SharePoint Online will store the items in the site’s preservation hold library until their retention period expires. Some organizations prefer the previous behavior because they believe that users should not remove labeled items. If this option is set, users see an error if they attempt to remove a labeled item. To proceed, a site administrator or user with permission must remove the label to allow deletion to happen or replace the label with one that does not have a delete action. This control is not linked to Records management.
• Configure record versioning: By default, record versioning is on, meaning that users can unlock items assigned a record label and edit their content. If off, items assigned a record label remain locked and updates are not possible after their creation. In effect, record labels then act like regulatory record labels.
• Allow editing of record properties: Apart from its content, an item has metadata like its title and other attributes. By default, users can edit items assigned a record label to update metadata. If this control is off, users cannot update item metadata after creation.

More Flexible Records Management

The last two options are needed for a new Records management capability where organizations can create retention labels for records which, when applied, leave items unlocked (MC306685, Microsoft 365 roadmap item 88509).

Up to now, when you apply a record label to a document, SharePoint Online or OneDrive for Business immediately lock the file to stop it being edited. The metadata (for instance, a document title) is changeable when a file is locked, but to update its contents, the user must first unlock it. This isn’t difficult (how hard it is to move a slider from locked to unlocked?), but it’s more convenient to keep a document in an unlocked state until its content is final, at which point it can be locked and behave as in the past.

Two options are available for organizations to decide if they want to allow users to edit locked records. Both are on by default, meaning that users can lock/unlock files and update metadata. However, if an organization wants record labels to behave much like regulatory record labels, they can toggle one or both settings to off. In this state, users cannot update the content or metadata of documents assigned retention labels marked as records. It’s not something to do on a whim, but it will make compliance administrators happy because they gain some extra flexibility in records management.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Restrict Processing to Specific File Types Using Auto-Label Retention Policies

A reader asks if it’s possible to limit the processing of a Microsoft 365 retention policy to certain file types. In this case, they wish to remove any Word documents, Excel spreadsheets, and PDF files from the SharePoint Online sites used by Teams while leaving other items stored in SharePoint like the OneNote notebook and .mht files used by the Teams wiki.

Before answering the question, it’s important to understand that Teams retention policies only process messages from channel conversations (including private channels) and chat. If you want a retention policy to process the SharePoint content owned by a team, you need the policy to process Microsoft 365 Groups. This is because Teams uses Microsoft 365 Groups for its identity and membership service.

The challenge then is how to amend a retention policy for Microsoft 365 Groups to only process certain file types. However, Microsoft 365 retention policies operate on a “whole container” basis. In other words, they apply the same retention settings to all items found in the target locations. In this case, Microsoft 365 Groups. Although you can refine a policy to process selected groups, the GUI in the Microsoft 365 compliance center doesn’t allow you to modify a policy to perform selective processing by file type.

Assigning Content Queries with PowerShell

PowerShell cmdlets are available to manage Microsoft 365 standard and auto-label retention policies. To access these cmdlets, connect to the Exchange Online management endpoint and then run the Connect-IPPSSession cmdlet to connect to the compliance endpoint. You can then run the Get-RetentionCompliancePolicy cmdlet to view the set of retention policies defined in the tenant and the Get-RetentionComplianceRule to view the rule defined for each policy. Each retention policy divides into the general policy settings and the rule dictating the retention action performed by the policy.

If you look at retention policy rules, you’ll see a parameter called ContentMatchQuery. Checking Microsoft’s documentation for Set-RetentionComplianceRule, we discover that this parameter contains a content query in Keyword Query Language (KQL) to filter the content scanned by the policy. A KQL-based content query is a commonplace object within Microsoft 365 as it’s used for SharePoint search, eDiscovery content searches, and automatic labeling policies.

It is possible to update a standard retention policy to add a content query. However, because no GUI exists for this purpose, you’ve got to add the content query with PowerShell. For example, the content query added to the target retention policy finds any Word document, Excel worksheet, or PDF file:

Set-RetentionComplianceRule -Identity "Retention for Specific File Types" -ContentMatchQuery "filetype:doc* filetype:xls* filetype:pdf"

You can test a content query by inputting it to SharePoint Search. If the search returns the expected files, you know the filter is good and will work with a retention policy.

The Problem with Standard Retention Policies

Or can it? Well, the filter works, and the retention policy will process only the specified files, but Microsoft doesn’t support this scenario. At least, they don’t include this scenario in their testing as they introduce new functionality (like adaptive scopes), which means that something might break inadvertently. That’s not a good situation for a compliance solution.

The ContentMatchQuery parameter exists because a KQL content filter is a way to select items for auto-label retention policies. Examples of the use of KQL queries in auto-label retention policies are to apply retention labels to Teams meeting recordings or to files with specific sensitivity labels.

In the earliest days of Office 365 retention policies, as they were then, you could attach a content query to a standard retention policy, but this has not been a supported scenario since Microsoft removed the GUI to enter KQL queries for retention policies. However, Microsoft left the ability to define a content query for a standard retention policy through PowerShell intact, and that’s what has created the inconsistency which exists today. To address the issue, Microsoft should update the documentation for Set-RetentionComplianceRule to say that the ContentMatchQuery parameter is unsupported with standard retention policies.

Use Auto-Label Policies

The approved solution is an auto-label retention policy. These policies accept KQL content queries like the example cited above. When SharePoint Online applies a retention policy with a content query, it finds matching files and assigns the retention label defined in the policy to the items. The retention period and action defined in the retention label controls what happens to the files. For example, the label might define a retention period of one year after which SharePoint Online should remove the labeled files.

One advantage of using an auto-label retention policy is that users see the retention label applied to matching files and can change the label if necessary. This doesn’t happen with standard retention policies because all processing happens in the background and users won’t necessarily be aware of the deletion of files.

The downside of auto-label retention policies is that any account which comes within the scope of the policy (for instance, all members of the Microsoft 365 groups processed by a policy) require Office 365 E5 or Microsoft 365 compliance licenses. This is not a problem if your organization already has these licenses, but there’s quite a step up from Office 365 E3 (needed for standard retention policies) to automatic processing, even before Microsoft’s March 1 price increase.

The bottom line is that you can live on the edge and use content queries with standard retention policies until something breaks (or Microsoft disables the capabilities) or use auto-label retention policies for selective processing based on file types. Going with a supported approach is always a better choice, even if it might cost some extra license fees.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Office Apps Check for Sensitivity Label When Opening Both New and Old Documents

Message center notification MC305436 (December 15, Microsoft 365 roadmap item 88515) informing tenants that sensitivity labels now apply to modified documents might have puzzled a few. It certainly caused me to think a little before understanding what’s going on, especially after reading Microsoft’s summary: “Coming to public preview, default labeling policies can now be applied to any supported document that a user edits, not just a new document.”

To understand the full context of what’s happening, we need to go back to the past. When Azure Information Protection came along in 2016, users needed to install a separate client, now called the unified labeling client, on Windows workstations to use labels. The client is still in use today, but only to apply labels to files stored outside Microsoft 365.

Microsoft originally developed a separate client because Office applications (online, mobile, and desktop) at the time didn’t understand how to deal with sensitivity labels. The apps couldn’t encrypt or decrypt documents and included no user interface elements to allow users to select labels to apply.

Enlightened Office Apps

Things are different today because the Office apps are “enlightened” (obviously, they were in the dark previously). In other words, they now support Azure Rights Management data protection by including Microsoft Information Protection code to handle sensitivity labels, connect to the service to fetch use licenses, display label information, and apply visual settings (watermarks, headers, and footers). Microsoft documents the current sensitivity label capabilities of Word, Excel, and PowerPoint in this page.

And if you enable support for sensitivity labels in SharePoint Online and OneDrive for Business, the content of protected files becomes available for processing by Microsoft Search, Data Loss Prevention (DLP), and other services. All in all, Microsoft has done a ton of work to build out the infrastructure surrounding sensitivity labels over the last few years. Anyone with an Office 365 or Microsoft 365 license can consume (access) content protected with sensitivity labels, but you need Office 365 E3 or above to apply sensitivity labels to content.

However, some customers invested in the unified labeling client (still only available for Windows) and paid for the necessary Azure Information Protection licenses. To help customers move away from the unified labeling client, Microsoft is steadily increasing the protection features available in Office, and the change reported in MC305436 is part of that effort.

Mandatory Labeling Via Policy

When you edit the settings for a sensitivity label publishing policy, you can choose to require users to apply a sensitivity label to new email and documents (Figure 1). Later in the policy settings, you select the default label to apply.

Because this is an automatic operation, Microsoft requires users to have Office 365 E5 licenses or above (see this guidance on Microsoft Information Protection licensing).

The change due to roll out in mid-January will allow Office to apply sensitivity labels to an unlabeled document when a user opens the file. Until now, Office only applied default labels to new documents, which meant that you could have a bunch of unlabeled but sensitive documents in a SharePoint Online document library that will never receive sensitivity labels unless a user explicitly opens and labels the documents. Now, each time Office opens a document, it checks for a label in the document metadata, and if none is present, Office applies the default label specified in the sensitivity label publishing policy. If a user comes within the scope of multiple publishing policies. Office applies the default label from the highest priority policy.

For more information about the deployment and management of sensitivity labels, see the Information Protection chapter in the Office 365 for IT Pros eBook. Or browse the Office 365 for IT Pros presentation on sensitivity labels at the recent European Collaboration Summit.

Who Deleted that Document?

Many searches of the Microsoft 365 audit log are attempts to answer questions. A good example is to search the log to discover email deletion audit events to answer a question like “who deleted a specific message in a shared mailbox?”

The equivalent question for SharePoint Online and OneDrive for Business is “who deleted that document?” You might not care too much about deletions in OneDrive for Business accounts because these are personal storage under the control of individual users; the same might not be true for SharePoint Online deletions, especially in sites used by Microsoft Teams and Outlook Groups where the simplicity of the Microsoft 365 Groups membership model mandates that all members have equal access to group data. In a nutshell, any team or group member can delete any file in the site.

SharePoint’s Deletion Process

SharePoint routes deleted items through a two-stage recycle bin process. All group members can recover items from the first stage recycle bin. Items remain in the first stage recycle bin for 30 days and then move to the second stage. Only group administrators (owners) can recover items after they reach the second stage recycle bin, where they remain for another 63 days. Ninety-three days after their original deletion, SharePoint Online automatically removes the items permanently and they become irretrievable. That is, unless SharePoint Online is forced to retain files because they have a retention label or come within the scope of a retention policy. In that case, SharePoint Online keeps a copy of the file in the site preservation hold library until the retention period lapses (users being able to delete files with retention labels is a recent change).

The audit records captured for item deletions in the Microsoft 365 audit log are often the result of user activity. In other words, someone selects a document in a folder and deletes it. SharePoint Online (including OneDrive for Business) captures a FileDeleted event when this happens. However, other processes can remove items, including:

• A retention policy applying to the site removes items after a set period.
• An administrator deletes a user account, and the SharePoint system account removes items from the user’s OneDrive for Business account.

Users can access the site recycle bin and remove items from it. Often this is an innocent activity, but it can also be evidence that someone wants to remove an item that they don’t want to be found. When someone removes an item from the first stage recycle bin, SharePoint Online captures a FileDeletedFirstStageRecycleBin audit event. Retention policies can also remove items form the recycle bin. Only site administrators can access items in the second stage recycle bin (Figure 1). If they remove items from the second stage recycle bin, SharePoint Online captures a FileDeletedSecondStageRecycleBin audit event.

In summary, SharePoint Online generates audit events as items move through site recycle bins to permanent deletion. Deletions are often user-initiated but can be the result of system processes. The Microsoft 365 audit log ingests the audit records approximately 15 minutes of them happening, and once the records are in the log, we can search for and report the events using the Search-UnifiedAuditLog cmdlet.

Of course, you can also look for these events using the audit log search feature in the Microsoft 365 compliance center but given the volume of audit events to deal with and the need to analyze information to make sense of what happened, it’s usually better to use PowerShell.

Searching for SharePoint Online Deletion Events

To illustrate the process, I created a script that you can download from GitHub. The script is very simple:

• Set up search parameters (I used a 90-day search period, you can adjust as necessary).
• Search for the three deletion events.
• Examine the AuditData payload in each record and extract relevant information.
• Sort the results by operation and date and export to a CSV file. I also output the results using the Out-GridView cmdlet (Figure 2) to make it convenient to see what’s found.

As the code is PowerShell, you can change it to meet your needs.

If you want to distribute the report in other ways, you could:

• Format the content in HTML and send it via email (see this article for details).
• Create the report in a SharePoint document library (the basics of how to do this is explained here; the scenario is a script running in a Azure Automation runbook but the technique of using PnP cmdlets is the same in “regular” PowerShell).
• Post the report to a Teams channel or post a link to it in a message card created in a Teams channel using the inbound webhook connector. See this article for more information.

Watch the Volume of Audit Events

One thing to pay attention to is the volume of deletion events in large tenants. The Search-UnifiedAuditLog cmdlet can retrieve up to 5,000 audit records without doing anything special. To fetch more, you must either:

• Break up the search to stay within the 5,000-record limit by running multiple limited searches (perhaps a daily search).
• Set the SessionCommand parameter for Search-UnifiedAuditLog to ReturnLargeSet. This allows the search to return up to 50.000 records. You need to sort the data.

It might be advantageous to export the search results to an external repository. Many organizations use Splunk for this purpose because they want to keep Microsoft 365 audit data for longer than Microsoft does (90 days for Office 365 E3, 365 days for E5) and to use the search and analysis capabilities often found in dedicated log aggregator products. If you don’t have a copy of the Office 365 for IT Pros eBook (reporting and auditing chapter), you can read this discussion in the Microsoft Technical Community to understand the process.

New Teams Meeting Audit Events in Purview Advanced Auditing

Updated 25 May 2024

In March 2020, Microsoft made the MailItemsAccessed audit event available. This was the first high-value Microsoft 365 audit event designed to help forensic investigators gain extra detail of what happened when they respond to security or internal events. We now have the first high-value Teams audit information in the MeetingDetail and MeetingParticipantDetail events. According to message center notification MC298031 (Nov 13, 2021), the events are now available in tenants.

When a meeting occurs, Teams logs a single MeetingDetail event to capture basic information about the meeting such as its start and end time. Teams also logs separate MeetingParticipantDetail events for each user (including guests) or application (like the recording bot) who joins the meeting. If the meeting starts and stops several times, Teams captures separate sets of audit events.

Licensing and Output

The important thing is that Teams captures this audit data only if users have the necessary licenses for advanced auditing. Office 365 E5 and a bunch of other Microsoft 365 products include advanced auditing. Office 365 E3 and any lower plan do not.

Update: Microsoft now generates the Teams meeting audit events for all accounts with Microsoft Purview (standard) licenses.

At least, that’s the way things are supposed to happen. My tenant uses a mixture of licenses, but the audit data captured for Teams meetings doesn’t happen as you might expect. First, the records don’t appear as quickly as other Teams audit events after a meeting ends. I think this is because a background process looks for meeting information and generates the events some time after a meeting finishes. At least, the creation date for the audit records is several hours after a meeting’s scheduled time. This might be done to ensure that the meeting is over, but it means that you should ignore the audit event creation time when tracking when meetings happen. In addition, as you’d expect, the information captured in the two events differ too, so some care is needed to parse out the audit payload.

Reporting Teams Meeting Audit Events

In any case, I wrote a script to illustrate how to find and parse the audit records for Teams meeting. You can download the script from GitHub. The code is simple:

• Set a time span to search for records. I look for the last 30 days. With Office 365 E5 or above, you can go back up to 365 days otherwise the limit is 180 days.
• Run the Search-UnifiedAuditLog cmdlet to find Teams meetings audit events.
• Parse each audit record to extract information from its payload. Use the Get-MgUser cmdlet to resolve the identifiers captured for meeting organizers and participants.
• Insert the data in a PowerShell list.
• After processing all records, generate a CSV file.

After processing a participant record (MeetingParticipantDetail) looks like this. You can see that the date recorded for the audit record is well after the person attended the meeting.

Date        : 09/12/2021 01:55:48
User        : Jack.Smith@office365itpros.com
MeetingId   : 87109282-1c08-4272-834b-16d6b9defa01
MeetingType : ScheduledMeeting
Start       : 08/12/2021 17:33
End         : 08/12/2021 17:37
User Time   : 00:03:53
Role        : 1
DetailId    : 87109282-1c08-4272-834b-16d6b9defa01
Artifacts   :
UserInfo    : SkypeSpaces/1415/1.0.0.2021120320/os=windows; osVer=10; deviceType=computer; browser=chrome;
              browserVer=96.0/TsCallingVersion=2021.42.01.1/Ovb=1c67ad38b440f3c30eadde98e59d505b1dd1c056
Type        : Participant
Operation   : MeetingParticipantDetail

While a meeting record (MeetingDetail) looks like:

Date        : 09/12/2021 01:55:48
User        : Sean.Landy@office365itpros.com
MeetingId   : 87109282-1c08-4272-834b-16d6b9defa01
MeetingType : ScheduledMeeting
Start       : 08/12/2021 17:33
End         : 08/12/2021 17:37
MeetingTime : 00:03:53
Organizer   : Sean Landy
Modalities  : Audio
MeetingURL  : teams.microsoft.com/l/meetup-join/19%3ameeting_MGRlYWRlMzctM2ViMC00OGUyLTg3NzAtMDc1MjdiZGU0MjBm%40thread.
              v2/0?context=%7b%22Tid%22%3a%22b662313f-14fc-43a2-9a7a-d2e27f4f3478%22%2c%22Oid%22%3a%2208dda855-5dc3-4fd
              c-8458-cbc494a5a774%22%7d
Type        : Meeting
Operation   : MeetingDetail

Figure 1 shows the output data created by the script (refreshed in 2024). There are both MeetingDetail and MeetingParticipantDetail records shown in the list. The point is that once you extract the set of Teams meeting audit events, you can slice and dice them as you wish.

The code works for the audit records I see in my tenant. I cannot attest that the code handles every permutation of audit data captured in these records, but as the code uses relatively simple PowerShell, it should be possible to amend the code to handle other conditions.

Investigations Will Prove the Worth of Teams Meeting Audit Events

I’m not totally convinced that the information captured in Teams meeting audit records are of high value. The basic knowledge to gain is that someone attended a meeting for a certain length of time, information that’s already in the attendance report that the meeting organizer can download. Some information that I would like to see is missing, such as the meeting title (admittingly, the meeting URL is available, so Graph API calls can find the meeting title).

It is advantageous to be able to search for and retrieve the information from the audit log along with other records of interest to investigators, especially for meetings that someone might try to hide by removing all trace from their calendar. Time will tell if investigators find the information captured in Teams meeting audit records helpful in their work and how they use the data. Remember that Teams stores attendance data for webinars in hidden Lists, so if these events are involved in an investigation, it’s probably better to go there to learn who attended the event.

Make sure that you’re not surprised about changes which appear inside Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Gem of a New Feature

Microsoft often hypes a preview feature that isn’t really worth the limelight. And sometimes, they introduce a gem without any fanfare. Such is the case of Retention Policy Lookup, which appeared in the Microsoft Purview compliance portal for my tenant over the weekend.

In a nutshell, policy lookup allows a compliance administrator to see what Microsoft 365 retention policies apply to users (mailboxes), SharePoint Online sites (including OneDrive for Business accounts), or Microsoft 365 groups (messages and documents). The reason why this is an important advance is that it solves a problem that becomes increasingly difficult as an organization develops and applies more retention policies.

Types of Retention Policies

Microsoft 365 retention policies come in three flavors:

• Label publishing policies make sets of retention labels available to end users. A user might come within the scope of multiple label publishing policies, each of which controls from one to many labels. Applications like SharePoint Online resolve all applicable policies to expose the full set of available labels to individual users.
• Retention policies apply general retention settings to target locations (users, sites, and groups). For example, keep all SharePoint content for three years. Retention policies can be org-wide (apply to all locations for one or more workloads, like Exchange Online), or non org-wide (apply to specific locations within workloads, like five selected SharePoint Online sites).
• Auto-label policies use search criteria to find specific information and apply a retention label to matching items. Using an auto-label policy to find and label Teams meeting recordings is an example of such a policy.

All contribute to making sure that messages, documents, and lists have suitable retention labels. User-applied labels have precedence over auto-applied labels, and retention policies act as a sweep to cover anything without a more specific label.

Figuring Out What’s Stopping Deletion

All’s well, except when users, sites, or groups come within the scope of multiple policies. Then it becomes difficult to understand what policies affect the ability to delete an item. Take the example of a SharePoint Online site flagged in the SharePoint admin center as having a compliance policy which blocks deletion. You know that a retention policy affects the site (Figure 1), but not which retention policy blocks deletion.

Until now, you could try to figure out what retention policies apply to a location by checking the set of policies to look for org-wide policies first (because they have the broadest coverage) followed by non-org wide policies. If you have Office 365 E5 or Microsoft 365 E5 policies, you might have to check retention policies with adaptive scopes. And finally, you’d have to figure out if the location stores any items with retention labels. Some of this work is possible using PowerShell with cmdlets like Get-RetentionCompliancePolicy, but the complexity of figuring out exactly what retains some content grows exponentially as the number of retention policies increases.

Policy Lookup

The new policy lookup feature solves the problem. Available in the Information governance section of the Microsoft 365 compliance center, the new option supports lookup for users, sites, and groups and reports back the set of retention policies which have the selected location within their scope. Policy lookup is available only for currently active mailboxes. It doesn’t lookup retention for inactive or soft-deleted mailboxes.

As an example, I checked the site shown in Figure 1 to see what retention policies might block its deletion. Figure 2 shows the result of the lookup. It would be nice if the UI showed the type of each policy, but it’s easy enough to check what each policy does. In this case, the first two are label publishing policies and the last two are auto-label policies.

The existence of a label publishing policy or auto-label policy in the list doesn’t mean that any of the labels used by these policies exist in the target location. To be sure, you’d need to check the labels applied to items in the location and remove any which might block deletion because their retention periods have not lapsed.

For retention policies, you can remove the location from the list of locations covered by the policy to allow deletion to proceed. However, this is not something that happens quickly because you need to allow time for the host workload to process the change made to the policy and recognize that the location no longer needs to be retained. The same is true if you lookup a location for the set of policies after making a change. It can take several days before a retention policy disappears from the list shown by the lookup.

Some Actions Would be Nice Too

Like any preview feature, some gaps exist that you might like to see filled. I have already noted that I’d like to see the retention policy type shown in the list of policies returned by a lookup. It would be nice to be able to generate a list of items in a location with labels published or auto-applied by a selected policy. For retention policies, it would be good to be able to have a single-click removal of a selected location from the scope of a selected policy.

After all, it’s great to know what policies exist to cover a user, site, or group. It’s so much better when you can do something with that information. Isn’t that what software exists to do?

Insight about topics like retention policies doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Policy-Controlled Access to Teams, SharePoint, and OneDrive

According to the latest version of the product documentation, Microsoft has decided to bundle Information Barriers into all the Office 365 and Microsoft 365 education plans (A1, A3, and A5). I think this is a good idea because there are obviously many situations in education tenants where information barriers might apply. For example, there’s possibly no need for students (like those in a specific year) to communicate outside their peer group. Information barriers can help by imposing blocks in communication flows between different sets of users.

What’s strange about the current state of information barriers is that, despite the dependency on Exchange Online address book policies, the barriers don’t apply to email communications. Information barriers use address book views to create organization segments (groupings) from recipient information stored in Azure AD. However, although Microsoft discussed the implementation of information barriers for Exchange as long ago as the Ignite 2018 conference, their documentation still ignores the topic and focuses on implementation for:

• Microsoft Teams.
• SharePoint Online.
• OneDrive for Business.

Directory Segments

Information barrier policies work by allowing or blocking communication between different organization segments. A segment is a defined set of Azure AD recipients (tenant and guest accounts and mail contacts) created by running a query against the directory. For instance, a segment might include all the students in a specific class or all the accounts in a department or country.

A limited set of Azure AD attributes can be included information barrier queries. If the available attributes can’t find the right target group, a workaround exists by using the membership of a distribution list or Microsoft 365 group as the basis for a segment. Microsoft’s documentation says that you can pass the name of a group when creating a segment. This has never worked for me. What does work is to pass the external directory object identifier for the group stored in Exchange Online. The identifier points to the Azure AD group. For example:

Get-UnifiedGroup "U.S. Banking Employees" | Select ExternalDirectoryObjectId

ExternalDirectoryObjectId
-------------------------
f4170c40-55d1-469f-afc9-043e1f5a8755

New-OrganizationSegment -Name "U.S. Banking Employees" -UserGroupFilter "MemberOf -eq 'f4170c40-55d1-469f-afc9-043e1f5a8755'"

After creating segments, the next step is to create information barrier policies to define how segments are blocked from communicating with each other (you can also create policies to explicitly allow communication between two segments). For example, let’s assume that we want to use the segment created above to block communications with another segment. We could use this policy:

New-InformationBarrierPolicy -Name "U.S. Banking Employees Block Ireland" -AssignedSegment "U.S. Banking Employees" -SegmentsBlocked "Ireland Banking Employees" -State Inactive

As this policy only blocks communications one-way (from U.S. employees to Irish employees), you’ll need a second policy to block communications in the other direction (from Ireland to the U.S.).

Blocking Communications Through Policy

Eventually, after background jobs run to resolve the accounts defined in organizational segments and assign address book views to accounts, the information barriers become active. For Teams, this means that:

• Users can’t add members from a blocked segment to a team or channel.
• They can’t add members from a blocked segment to a 1:1 or group chat or meeting.
• Users aren’t allowed to join meetings when other users from blocked segments attend.
• Directory lookup is scoped to stop people finding others in blocked segments.

Information barriers modify the sharing capabilities of SharePoint Online and OneDrive for Business to stop users sharing information with people in blocked segments. In a nutshell, if someone tries to share content with others, they can only do so if the sharing target is allowed by information barriers. SharePoint sites connected to Microsoft 365 groups or teams can only be shared with people in the same organization segment.

The Poorest Piece of Microsoft’s Compliance Toolkit

Information barriers have been around for several years now, and it’s disappointing to see the limited progress Microsoft has made to develop this capability. Unlike the other compliance solutions available to Microsoft 365 tenants, information barriers don’t have a GUI in the Microsoft 365 compliance center (or anywhere else). All management must be done with PowerShell cmdlets from the Exchange Online management module. The error handling and output from some of the cmdlets is unformatted and uninformative. Most of the processing done to apply information barrier policy settings happens using a background job whose activities are as clear as a black box. Although it’s possible to figure out when conflicts occur in policy application, it requires searches against the audit log and resolution of GUIDs to determine what segments and recipients are involved. All in all, information barrier policies are a mess.

Although it’s nice that Microsoft has made information barrier policies available to education tenants, it would be better if they:

• Create a GUI to manage organization segments and information barrier policies in the Microsoft 365 compliance center.
• Provide features such as the ability to test organization segments to show what recipients are in a segment (Adaptive scopes for retention policies can display similar information). In addition, have a way for administrators to see if any conflicts exist with other segments (a recipient must appear only in one segment). None of this is rocket science.
• Make the operation of the information barrier application more transparent and easier to manage, especially in the resolution of any issues thrown up by processing. Perhaps even apply some of the much-vaunted artificial intelligence that’s strewn around Microsoft 365 to help organizations understand and tweak the flow of communications controlled by policy.
• Fix the PowerShell cmdlets so that their error handling is smoother and delivers information to tell administrators how to fix problems.
• Include Exchange Online in the workloads supported by information barrier policies.

Demanding Office 365 E5 or Microsoft 365 E5 licenses for a half-baked, unfinished, and problematic solution that’s been generally available for several years is not a good position for Microsoft to be in. It would be better if they fixed the fundamentals of the information barriers solution before expanding those who might have to use it.

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem. Information barrier policies are covered in the compliance chapter.

Joins the Controls for Teams Meeting Recordings

Now that Microsoft has created the transition of storage for Teams meeting recordings (TMRs) from Stream (classic) to OneDrive for Business and SharePoint Online (ODSP), attention is focused on how to manage these files. Microsoft plans to introduce an auto-expiration policy for TMRs in January 2022 to allow organizations dictate how long these files exist in ODSP. The auto-expiration policy will work for any Microsoft 365 tenant which has licenses for Teams.

If you have Office 365 E3, users can apply retention labels to TMRs to gain more control over their retention, and if you have Office 365 E5 or Microsoft 365 E5 licenses, you can deploy an auto-label retention policy to find and label TMRs (and track the success of the policy in finding and labeling TMRs). In short, over time, organizations are gaining ways to exert compliance control over TMRs.

Blocking Sharing with Data Loss Prevention

Data Loss Prevention (DLP) for SharePoint Online and OneDrive for Business is included in the Office 365 E3 SKU. The value of DLP is that you can use a policy to protect against inadvertent data leakage caused when someone shares a TMR outside the organization. Imagine what would happen if a competitor got hold of a recording of a discussion, complete with slides, about the development of a new product!

Using much the same approach as taken to identify TMRs for the auto-labeling retention policy, we can build a DLP policy for TMRs which looks for recording files and stamps them with metadata to stop sharing happening. The DLP policy to block external sharing for TMRs is very simple. It is a custom DLP policy (i.e., not created using a template) consisting of:

• A name and description.
• Target locations. For maximum coverage, choose all SharePoint Online sites and OneDrive for Business accounts. This will stop any sharing of TMRs created for personal meetings (OneDrive) and channel meetings (SharePoint).
• A single rule. The rule looks for any file with the property value ProgId:Media.Meeting that is shared with someone outside the organization. The rule action blocks sharing with people outside the organization. Figure 1 shows what the rule conditions look like. Optionally, the rule can allow users to override the block by providing a justification to explain why they need to share a recording with an external person.

Other rule settings which you might consider include creating a custom policy tip to explain why users can’t share TMRs externally or generating an incident report to alert administrators or other people when a rule violation occurs.

The Effect of DLP

It can take up to an hour before a new DLP policy is effective. When the policy is active, the indexing process for new files detects that TMRs come within the scope of a policy and applies the policy settings to block external sharing. There might be a few minutes before the block is effective for a new file during which it’s possible to create and send a sharing link. However, once the block is in place, the sharing link is nullified.

The effect of the policy is obvious because any document which matches the policy conditions now has a small icon (circle with a line in the middle). In Figure 2, the icon is shown alongside all the TMRs in the Recordings folder. Other video files that don’t have the property set are not marked. Hovering over a TMR reveals information about the file, including a link to a DLP policy tip if set. In this case, the link reveals some custom text to explain that external sharing is not permitted for TMRs.

If the user ignores the warning and goes ahead to try and share the recording anyway, they won’t be able to do this because OneDrive for Business blocks the attempt to create and send a sharing link (Figure 3).

Easy Update

Even if internal users don’t often go back to relisten to what was discussed in a conference call, there’s no doubt that some external people might find that content interesting, perhaps even to the detriment of your company. The time required to create and deploy a DLP policy to block external sharing of TMRs is roughly ten minutes (including a pause to drink coffee). It’s a quick and easy update to make it easier to manage the security of information contained inside these files. This is a good example of the value of DLP.

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Second Example of Trend Emerges with Offer to Use Communications Compliance

I don’t like the trend now emerging in Microsoft 365 Data Loss Prevention (DLP) where Microsoft uses DLP policies as a conduit to sell other Microsoft 365 solutions. A case can probably be made to extend a DLP policy to cover Teams, but the October 21 announcement in MC293000 that Microsoft will “surface” recommendations to use Communications Compliance within the DLP workflow (Figure 1) is a step too far.

You might think it is awfully helpful for Microsoft to make suggestions about making better use of DLP. This feeling would be justified if the recommendations improved DLP. However, as I point out when discussing the need to move away from Exchange DLP policies, extending a policy to Teams is not something which can often be done automatically. Likewise, gaining “the ability to apply DLP policy insights to your insider risk practice to better identify user behavior and intent” by configuring a communications compliance policy is not something that should happen as the result of a prompt at the end of updating a DLP policy.

Monitoring Communications

Communications compliance policies monitor interactions between people to detect problems like using offensive or threatening language. The communications covered are email, Teams, Yammer, and Skype for Business conversations (soon to disappear). For Teams and Yammer (only networks configured in Microsoft 365 mode), monitoring happens against the compliance records captured in Exchange Online. Matching occurs using one or more of the trainable classifiers available within a tenant (Figure 2), including those configured by the tenant.

Since the launch of communications compliance in 2019, Microsoft has done a good job of building out the set of available classifiers and expanding language coverage. The image classifiers are language independent. Classifiers won’t catch everything, but they improve over time and the idea is to detect gratuitous and persistent offenders rather than picking up every conceivable issue.

Policy matches result in referrals to human reviewers to check the content and context of the problem messages. The reviewers can decide if a policy violation is present and if so, how best to deal with the offender. All of which is grounded in an organizations HR policies and procedures, and probably heavily influenced at a local level.

There’s lots to like about communications compliance and it’s a good solution for Microsoft 365 to offer. However, this is not a solution that every organization needs or is comfortable with. Communications compliance has a hint of big brother is watching you about it that makes many people uncomfortable. Its implementation requires careful planning to ensure that the organization is prepared and that everyone involved in policy creation and operation from HR to reviewers to managers understand their roles and how to deal with offenses. This is not a project to start on a whim.

Inappropriate Connection

All of which makes me think that it is inappropriate for Microsoft to link DLP with communications compliance. There’s too big a jump between monitoring for inadvertent disclosure of sensitive corporate information outside the organization (the normal DLP scenario) to checking internal communications to detect violations in tone and language. I don’t see the natural connection between policies largely under the control of IT (DLP) and those where HR has huge influence and oversight.

One thing that links both suggestions Microsoft surface within DLP is that they need Office 365 E5 or Microsoft 365 E5 Compliance licenses. Office 365 E3 covers DLP for Exchange and SharePoint, but you need E5 for Teams (a differentiation that’s always seemed strange and inexplicable). Communications compliance is a premium E5 feature. I hope that Microsoft isn’t simply using DLP to push higher-price features to customers. That’s a tactic which might seem reasonable inside Microsoft, but it’s just tacky out in the real world.

PS. Microsoft will run a webinar about moving Exchange DLP policies to Microsoft 365 DLP policies on November 9. Register here.

Keep up to date with developments in compliance and other areas of Microsoft 365 by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Manage the Mailboxes of ex-Employees

Updated 19 September 2023

As reported in September, a listing of inactive mailboxes is now available in the modern Exchange Online admin center. This prompted some discussion about the management of inactive mailboxes, with some pointing to Microsoft’s recommendation to create an inactive mailbox retention policy to specifically manage inactive mailboxes. While retention policies are not a new feature as alleged by Microsoft, the page contains some good points to consider.

Shared mailboxes are also a valid method of retaining the mailboxes of ex-employees. I don’t discuss that alternative here.

Inactive Mailbox Retention Primer

Briefly, an inactive mailbox is a mailbox belonging to a deleted account. If you run the Get-ExoMailbox cmdlet to return the set of inactive mailboxes, you might see some with a value for the ExternalDirectoryObjectId property, the pointer which connects an Exchange Online mailbox to an Entra ID (Azure AD) account.

Get-ExoMailbox -InactiveMailboxOnly | Format-Table DisplayName, ExternalDirectoryObjectid

DisplayName                                  ExternalDirectoryObjectId
-----------                                  -------------------------
Dongli Pan 
Dylan Webb
Ed Banti
Frank Clonan
Imran Khan                                   b8eef43d-6854-4d77-9e03-745cf2e11e11

The mailboxes with ExternalDirectoryObjectId values belong to user accounts deleted within the last 30 days. During this period, administrators can recover the accounts and reconnect the mailboxes. Once the 30 days lapse, Entra ID permanently removes the account and Exchange Online nullifies the connection between the two objects.

Multiple holds (litigation, in-place eDIscovery, or retention policy) can be present for an inactive mailbox. These holds must be placed while the mailbox is active. Even after their user accounts disappear, inactive mailboxes remain in place until the last hold lapses. At that point, the Managed Folder Assistant cleans up and removes the mailbox.

Administrators can still recover data from inactive mailboxes or restore an inactive mailbox to connect it to a brand-new account, but the link between the original account and mailbox is gone. In a nutshell, inactive mailboxes are a great way for organizations with Office 365/Microsoft 365 E3 and E5 licenses to keep information for ex-employees until the need for their mailboxes disappear. You don’t have to pay anything for inactive mailboxes, no matter how much storage their primary and archives (including auto-expanding archives) occupy.

The Advantage of a Retention Policy for Inactive Mailboxes

A retention policy for inactive mailboxes is often used to gradually clear out information from inactive mailboxes on the basis that old information loses its value to the organization over time. To achieve this goal, the retention policy will:

• Apply only to inactive mailboxes. You can identify the mailboxes individually or by using a distribution list. Up to 1,000 individual inactive mailboxes can be added to a single (static scope) retention policy. If you want to add more, you can create multiple policies. Retention policies using adaptive scopes don’t have the same limitations, and you can identify inactive mailboxes by searching for their mailbox state. Because this process happens automatically and on an ongoing basis, you don’t have to worry about adding new inactive mailboxes to the retention policy.
• Remove content after a set period. Usually, this period ranges from six months to two years. In certain regulatory or legal conditions, an organization might retain mailbox contents for longer periods (I’ve heard of situations where inactive mailboxes are kept for ten years).

If you use a distribution list to add mailboxes to a retention policy with a static scope, remember that this is a one-time operation. Microsoft 365 reads the mailboxes from the list membership and adds them as separate Exchange locations to the retention policy. Any further additions or removals from the distribution list are not synchronized with the locations in the retention policy. Also, Microsoft 365 adds the managers of the distribution list to the policy. All of the above means that using a distribution list to populate a retention policy is strictly a method to add multiple locations to a policy rather than a means of maintaining the set of Exchange locations used by the policy.

The Managed Folder Assistant (MFA) processes inactive mailboxes along with active mailboxes. For instance, if the retention policy mandates the removal of information older than a year old, MFA will scan the mailbox to find any items older than a year and remove these items each time it processes the mailbox. Note that MFA might have to apply several retention policies to an inactive mailbox. If this is the case, the longest retention period applies.

Microsoft says that the advantages of having a specific policy are:

• You can configure the retention policy to retain mailbox content only as long as necessary to meet your organization’s requirement for former employees.
• It’s a good way to identify inactive mailboxes because the retention policy will only be applied to inactive mailboxes.

The first point is correct. The second is technically correct but depends on administrators applying the policy to mailboxes before deleting their user accounts. You can’t apply a retention policy to a mailbox once it becomes inactive. Any attempt through the administrative GUIs or PowerShell fails because the inactive mailbox is not recognized as a valid target.

Microsoft also makes the point that if you use a specific retention policy for inactive mailboxes, you can update the retention settings in one place to apply the new values to all inactive mailboxes. I think this is fair.

Finding Inactive Mailboxes with a Specific Retention Policy

I have doubts about Microsoft’s assertion that having a specific retention policy for inactive mailboxes is a good way to identify inactive mailboxes. Running Get-ExoMailbox -InactiveMailboxOnly is the best way to find the set of inactive mailboxes. To find the set of mailboxes to which a retention policy applies, you would have to examine the InPlaceHolds property of each mailbox to see if it is stamped with the identifier of the retention policy. Something like this would work:

# Find the identifier for the retention policy
$Policy = Get-RetentionCompliancePolicy -Identity "Retention Policy for Inactive mailboxes" | Select-Object -ExpandProperty ExchangeObjectId
# Build search string
$CheckGuid = "mbx" + $Policy.Guid.SubString(0,8) + "*"
[array]$Mbx = Get-ExoMailbox -InactiveMailboxOnly -Properties InPlaceHolds
If (!($Mbx)) {Write-Host "No inactive mailboxes found - exiting"; break} 
Write-Host ("Processing {0} inactive mailboxes..." -f $Mbx.Count)
ForEach ($M in $Mbx)  {
    $Holds = Get-ExoMailbox -Identity $M.UserPrincipalName -Properties InPlaceHolds -InactiveMailboxOnly | Select-Object -ExpandProperty InPlaceHolds
    If ($Holds -like $CheckGuid) { 
        Write-Host ("The in-place hold for Inactive mailboxes applies to mailbox {0} ({1})" -f $M.DisplayName, $M.UserPrincipalName )
    }
} #End ForEach

Note that you’ll need to run the Connect-IPPSSession cmdlet first to connect to the compliance endpoint before running Get-RetentionCompliancePolicy to fetch the identifier for the retention policy. Running this PowerShell will report the exact set of inactive mailboxes assigned the retention policy, so there’s some value in that. Then again, if you use the one retention policy and assign it to mailboxes before deleting their Azure AD accounts, the Get-ExoMailbox cmdlet will return the same set.

Learn how to exploit the Office 365 data available to tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Making Retention More Efficient

Message center notification MC288633 (1 October) covers the topic of optimized behavior of file versions preserved in SharePoint Online and OneDrive for Business. It’s a title guaranteed to turn off most Office 365 administrators unless they’re interested in compliance. As it happens, I am, so I read the notification.

My reading of the situation is that Microsoft is replacing an old-fashioned implementation of the preservation hold library with a more modern approach. As you might know, the preservation hold library is the location used by SharePoint Online to keep information needed for retention purposes. It’s the equivalent of Exchange Online’s Recoverable Items structure, a place where updated and removed content stays until the retention period expires.

The Preservation Hold Library

Up to now, SharePoint Online has used the preservation hold library to retain multiple versions of changes made to documents and list items. If someone edits a document which comes within the scope of a retention policy, SharePoint captures a pre-change copy of the document in the library. If someone deletes a document that must be retained, it goes into the preservation hold library. The actual processing is more complicated, but that description is sufficient here.

The net effect is that a preservation hold library for a busy site can accumulate a bunch of items (Figure 1). Although users cannot access the preservation hold library, its content is indexed and discoverable and available for searching, which means that eDiscovery investigators can recover the full change record for documents and list items. Administrators can also recover files from the preservation hold library, so there’s lots of goodness available.

The Downsides of Retention

Except that a downside exists. Or rather, two significant downsides. The first is that capturing edits and deletions for a busy SharePoint Online site can consume a large percentage of the storage quota used for the site. The amount differs from site to site depending on the characteristics of site usage and the type of file stored. For instance, the site which I use to store the Word documents for blog posts has thousands of relatively small files (usually in the range of 1-5 pages), most of which are never edited after publication. The preservation hold library for the site holds 924 items of 292.6 MB, or 5.92% of the site storage.

The site used for the Office 365 for IT Pros book has completely different characteristics. The Word documents (and some Excel spreadsheets) are larger (some chapters are over 100 pages) and they receive frequent revisions. For example, according to its version history, the chapter covering Teams architecture and structure in the 2021 edition has 330 versions, most generated using the Office AutoSave feature. The combination of large files and multiple revisions drives storage consumption to 15.3 GB, or 21.8% of the site (Figure 2).

The problem is that SharePoint Online regards the storage consumed by the preservation hold library in the same manner as it treats other libraries. Everything counts against the tenant’s overall SharePoint storage quota, which seems a little unfair given that Exchange Online provides additional free storage per mailbox to handle retention. It’s easy to run a report to find the storage consumed by each site, but you’ll need to access the site to discover how much is consumed by the preservation hold library.

The second issue is that content searches find multiple copies of files stored in SharePoint Online sites. This might be what you want, but usually it’s confusing (Figure 3).

The Change

The change rolling out in mid-Novembers means that files with multiple versions deleted from a SharePoint Online site or OneDrive for Business account which must be retained will be preserved as a single file instead of multiple versions. Storing fewer versions should reduce the demand for storage, but I shall wait and see how things work before making a definitive statement on that point. Reducing the number of versions held for a file will also speed up deletions and eliminate errors caused when retained files had more than a hundred versions in the preservation hold library.

Existing files in the preservation hold library are not updated and behave as before. Eventually, after the retention period for items expire, the weekly background job to check and remove obsolete material from the preservation hold library will remove the older files and release storage.

The new approach applies to any file which ends up in the preservation hold library because of a retention policy or in-place eDiscovery hold.

Given the number of files now stored in SharePoint Online due to increased use by apps like Teams, the effect of AutoSave in generating multiple file versions, and the impact on tenant storage quota that retention can have, this is a good change. It also simplifies administration and might even make it easier for backup and restore scenarios (fewer files to deal with). Time will tell!

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Odd Title for Notification, but Real Value in Update

What does “Exchange online auto-expanding archive–Automatic archive of mailbox items in Purges, Versions and Discovery Holds folders” mean? That’s exactly what I thought when I read message center notification MC288630 (1 October). It’s a classic example of how poor editing can mask the value in a message. Here’s what’s happening.

The Recoverable Items structure is composed of several sub-folders, each with a distinct task. A set of sub-folders within Recoverable Items are used for retention processing:

• Purges: Stores items removed from the Deletions folder.
• Versions: Stores the original versions of edited items.
• DiscoveryHolds: Contains hard-deleted items.
• SubstrateHolds: Contains the original versions of items managed by the Microsoft 365 substrate (for example, compliance items for Teams messages).

If a mailbox doesn’t come within the scope of a litigation or in-place (retention) hold, you won’t see items in these folders. You will see items in the Deletions folder because this is where items removed from the Deleted Items folder go until Exchange Online removes them permanently. Items stay in Deletions for the deleted items retention period defined for a mailbox (usually 14 days but can be changed to a maximum of 30 days). During this period, users can recover items from Deletions using Outlook’s Recover Deleted Items option. For more information on how these folders are used, see this Microsoft article.

Cluttering Up Recoverable Items

The point of retention policies is to keep information for as long as it is needed. Although Microsoft allocates a 100 GB storage quota to store data in Recoverable Items when a mailbox is subject to retention, it’s not uncommon to find that some mailboxes accumulate information quickly and occupy the quota. The change described in MC288630 and being rolled out in mid-October aims to take advantage of archive mailboxes by moving information from the Purges, Versions, and DiscoveryHolds sub-folders to the archive mailbox one day after their generation.

In effect, this is the same processing as would occur if you were able to assign a 1-day move to archive Exchange retention tag to these folders. The Managed Folder Assistant looks at the contents of the folders when it processes a mailbox and, if the mailbox has an archive, applies the one-day move to archive rule. The same processing occurs for both normal and auto-expanding archives.

The net effect is that the space occupied by the items in these folders in primary mailboxes is reduced dramatically and administrators won’t have to step in as often as happens now to remove data from Recoverable Items. The items moved into the archive remain indexed and discoverable and have the same value for retention processing.

Ignoring Existing Policies

MC288630 says that “existing archiving policies created by customers for these folders will be ignored” once the change is effective. In other words, if you have an Exchange retention policy with a folder tag for the Recoverable Items folder which takes another action (for instance, for move to the archive after 90 days), the Managed Folder Assistant will now ignore the folder tag when it processes the Purges, Versions, and Discovery Holds sub-folders. However, the folder tag (or a default move to archive tag) will apply to items in the Deletions sub-folder.

Users will remain blissfully unaware of the change. They can’t access the three sub-folders in either primary or archive mailboxes. This is simply a matter of moving data around to a new location to make the overall functioning of the Recoverable Items structure in primary mailboxes more effective. It’s a good change.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what’s happening.

Achieving Compliance can be Expensive

If you follow the announcements made by Microsoft about new functionality available to Microsoft 365 tenants, you might have noticed that many new of the features described in the announcements require high-end licenses like Office 365 E5 or Microsoft 365 E5 Compliance. Both licenses come with a hefty monthly fee (like the $12 list price for the Microsoft 365 E5 compliance add-on). More information on the licensing requirements for different features is available online, including a useful comparison table (Figure 1).

In fact, even with the new prices for Office 365 and Microsoft 365 due to come into effect on March 1, 2022, if your organization needs some of the information protection, governance, and compliance features not available in Office 365 E3, upgrading to Office 365 E5 rather than buying add-ons looks like a relative bargain. In addition to the information governance features, you’ll also get access to other features like the Teams Phone system and audio conferencing.

Higher ARPU

Of course, moving to higher-priced plans is exactly what Microsoft wants customers to do. Every time Microsoft briefs market analysts after releasing its quarterly results, it emphasizes the growth in annual revenue per user (ARPU), meaning that over time Microsoft becomes more successful at convincing customers to upgrade to higher-price plans. Continuing to make higher-priced plans more attractive is why Microsoft usually adds new functionality to those plans rather than making features available to Office 365 E3, the baseline plan for enterprises. For instance, using an auto-label policy for Teams meeting recordings or use adaptive scopes for retention and other policies (due next month) both require E5 or a compliance add-on.

Free Compliance Trial

Which brings me to the free trial for compliance licenses Microsoft is rolling out to tenants which don’t already have these licenses. Claimed by a tenant administrator through the Trials section of the Microsoft 365 compliance center, the validity of the Microsoft 365 E5 compliance trial licenses is 90 days, which should be enough for you to decide whether the functionality does what Microsoft claims and is useful to your organization (you can extend the trial within 15 days of its expiration).

If you decide not to proceed, Microsoft 365 retains the data accumulated by the compliance features for 180 days, after which it is removed.

Microsoft gives some details of the functionality licensed in the trial in their post. More detail is available in the Microsoft 365 E5 compliance column in the comparison table referenced above. There we find features like:

• Automatic application of sensitivity labels to Exchange and SharePoint workloads.
• Use of trainable qualifiers to find and label data.
• Microsoft Cloud App Security.
• Data Loss Prevention (DLP) for Teams messaging.
• Endpoint DLP.
• Communications compliance.
• Advanced eDiscovery.
• Advanced auditing.

In short, there’s lots of functionality to explore, which means that you should do some up-front preparation before signing up for the trial. Aim to spend every day of the 90 doing something useful to explore and measure the effectiveness of a compliance feature for your organization so that you can make a fact-backed decision at the end of the trial.

The trial is a marketing exercise to hook new customers. That’s OK because there is real value to be gained by using features against live data (with preparation) rather than in a test tenant. You can sign up for an E5 test tenant and access all the compliance functionality there, but it’s not quite the same as seeing how things work with your data.

On the other hand, if you already have a trial tenant (as many enterprise Office 365 tenants do), you’ve likely spent some time replicating the production setup in the trial tenant and can get the same value from testing the compliance features in the trial tenant. All of which goes to prove once again that there’s usually more ways than one to solve a problem.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what’s happening.

Partnership with Microsoft Lists Does the Trick

In an earlier article, we cover how Microsoft makes the spoken words in Teams meeting recording transcripts available to Microsoft Search. A similar approach is used to make the attendance for Teams webinars available to Search. Here’s what happens.

Webinars are calendar events, so their existence is recorded in the meeting organizer’s Exchange Online calendar. Also, The Microsoft 365 substrate captures meeting details in items in a hidden folder called 93c8660e-1330-4e40-8fda-fd27f9eafe10AttendanceReportV3Collection in the non-IPM part of the organizer mailbox, including JSON-formatted information about meeting participants captured in the ArtifactEntriesJsonBlob property (Figure 1).

This information is captured for all meetings (including webinars) and is used to display the attendance report for the event in the Teams calendar app. Figure 2 shows the attendance report based on the information captured in the record shown in Figure 1.

Webinars receive special handling, and this is where Microsoft Lists come into play. The connection between Teams and the content held in Lists is via the ThreadId property, a value which points to the Teams meeting space (the identifier is also used in the Teams webinar URL) used for the event. A thread ID looks like this:

19:meeting_MjE2Mjg0OGEtMGViMi00OGNhLTg3ODQtMWE3NjE2MDAzNzli@thread.v2

Exposing Teams Webinar Information for eDiscovery

To make the webinar information available for eDiscovery, Teams creates three lists per webinar in the in the meeting organizer’s OneDrive for Business account. This is the reason why Microsoft makes access to Microsoft Lists one of the prerequisites for organizing Teams webinars. Lists are only created for webinar events.

The lists for an individual event share a unique identifier (GUID) which Teams uses as a suffix to associate the lists for an individual event (for example, de93882234fb418fb3fd5ef7048026d4). The lists are:

• Event: Stores event information such as its start and end time and webinar description and title. The ThreadId for the webinar is stored in this list. The webinar title and description can be edited in the list but the information created by Teams for the meeting cannot.
• Questionnaire: Stores the attendance records for individual webinar attendees. The information about attendee details (like name and email address) can be edited in the list but information relating to the Teams meeting (like its URI) cannot.
• Speakers: Stores details of the speakers such as their names and bios. This information can be edited in the list.

Updates made to list data are reindexed and available for search.

The webinar lists are hidden from the normal My Lists view shown to users when they open the Microsoft Lists app. To access the webinar information, go to OneDrive’s Site Settings and navigate to the Site Libraries and Lists page (Figure 3), where you can see the lists used by Teams along with other lists used by OneDrive like the site’s preservation hold library.

As an example, this is the URL for the site settings and list page for the KimAkers@office365itpros.com account.

https:// office365itpros-my.sharepoint.com/personal/kim_akers_office365itpros_com/_layouts/15/mcontent.aspx

If you choose to customize a list, you see the list settings, including its URL. For instance, the speaker list for an event has a URL like:

https:// office365itpros-my.sharepoint.com/personal/kim_akers_office365itpros_com/Lists/Speaker_de93882234fb418fb3fd5ef7048026d4/AllItems.aspx

Using the URL, we can open the chosen list in a browser. Figure 4 shows the speaker list for a Teams webinar.

Microsoft Search indexes the Information stored in OneDrive for Business. You can therefore search for someone’s involvement in a webinar by inputting their email address into SharePoint Search. The Digiform entries shown in Figure 5 are for the attendance rosters for two webinars.

Even better, the indexed information for the speaker, attendance, and event lists is available for eDiscovery. In Figure 6, we see some webinar items listed in a sample preview for a Core eDiscovery search. The items relate to speaker bios (highlighted in Figure 1), webinar description, and email addresses in the attendance report. Again, the Digiform entries found by the search point to lists stored in OneDrive for Business.

The Many Moving Parts of Microsoft 365

The way Microsoft 365 captures, stores, and indexes webinar attendance data is a good example of the Microsoft 365 substrate and ecosystem in action. Although many moving parts are involved, administrators and end users don’t see any of the complexity or connections involved. Some might be bothered by the ability of end users to update some webinar information stored in lists, but if you don’t tell them that the information is there, they might never discover where it’s stored.

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Search for What Participants Say During Teams Meetings

Microsoft message center notification MC260749 (last updated August 12) titled Microsoft Search: Find a meeting recording based on what was said is both technically interesting and important. Described in Microsoft 365 roadmap item 82003, the roll-out was delayed several times, but the way is now clear for Office 365 tenants to be able to search videos using spoken text along with a bunch of other changes to make Teams meeting recordings more accessible and useful. While it’s hard to say exactly when individual tenants will have all the functionality described here, I expect worldwide deployment to be complete by the end of October 2021.

Everything in OneDrive

Exposing the content of meeting recordings for search is important because it starts the process to close a major compliance gap. Up to now, transcripts for online meetings have not been searchable. The problem first surfaced when Teams stored its recordings in Stream. When the meeting finished, Stream processed the recording and created the transcript. However, the transcript remained in the Stream Azure service and was inaccessible to Microsoft Search. If something can’t be indexed by Microsoft Search, its content cannot be found by a search.

Microsoft completed the migration the storage of Teams meeting recordings from Stream to OneDrive for Business or SharePoint Online (ODSP) on August 16, 2021. All new meeting recordings from that date are in ODSP with the migration of older content from Stream to ODSP happening later. Microsoft is busy building out the rest of the Stream 2.0 platform to handle videos which don’t come from Teams. For instance, they’ve released a preview of the new Stream browser interface which supports access to videos stored in both ODSP and the original Stream store.

The move to ODSP removed the ability to create and replay transcripts for meeting recordings which exists in Stream classic. Starting September 20, Microsoft plans to remove some of the automatically-generated transcripts from older videos in Stream classic to prepare for the migration to Stream 2.0.

To fill the functionality gap, Microsoft introduced a transcription capability for Teams meeting recordings (a recent update means that if you record a Teams meeting now, you generate a transcript automatically). However, the issue of searchability remained. Because ODSP stores the recording files, Search could index file metadata like the name of the recording, but that’s about all.

The gap in indexing and searchability is now closed. Teams stores the spoken text captured during a meeting (including speaker attribution so you know who said what) and meeting metadata in the Exchange Online mailbox of the meeting organizer. Capturing the spoken text in mailboxes allows Microsoft Search to index the data and therefore makes it possible for searches to find this information. And as we’ll see, ODSP also holds a copy of the transcript to allow the words in the transcript to connect with segments in a meeting recording.

Exchange Mailbox Storage for Transcript Information

Teams stores transcript information in a folder called ApplicationDataRoot/93c8660e-1330-4e40-8fda-fd27f9eafe10/MeetingTranscriptCollection in the non-IPM part of the mailbox. Hidden means that the folder isn’t available to users through clients like Outlook, but its contents are available to administrative interfaces like Microsoft Search and programs like MFCMAPI.

Transcripts are captured as mail items. Examining the captured items with MFCMAPI, it looks like two properties for are most interesting:

• TranscriptJsonBlob: stores the spoken text captured during the meeting. In Figure 1, you can see some captured text, including the name of the speaker. When users view the transcript in Teams, the information is displayed in a nicer format. It’s also possible to download transcripts in VTT or Word (DOCX) format.
• TranscriptMetadataJsonBlob: stores metadata about the call.

Linking Words to Videos

The original implementation for Teams meeting recordings stored in Stream classic supported transcription, including the ability to edit the transcript to correct obvious errors. To allow Microsoft Search to find the MP4 file for a meeting recording based on words spoken during a meeting, a background process copies the transcript data captured in Exchange Online and indexes it against the recording to match segments of the video with the spoken words.

Replication of transcript data from Exchange Online to ODSP can take anything from 15 minutes to a day after the meeting ends. Once the process completes, you can search for text spoken in meetings and find recordings using the transcript (Figure 2).

Transcript Playback

Matching words in the transcript with meeting recordings (and eventually, any video stored in ODSP) allows concurrent playback for the two elements. Microsoft 365 roadmap item 82057, rolling out in September 2021, delivers a transcript pane for video playback (Figure 3). No ability is yet available for a video owner to edit the transcript.

Curiously, closed captions are available for only 60 days from the date of recording. In addition, Microsoft says that “Closed captions aren’t fully supported” if you move or copy a recording from its original location. Presumably, this is because the move might affect the link to the transcript data.

Making Transcription Available to More Teams Users

The option to transcribe meetings used to be restricted to accounts with enterprise E3/E5 and Business Premium/Standard. In early July, Microsoft made live transcription available (MC260564) for other licenses, including the E1, F1, academic, and Business basic SKUs, noting that this step improves the accessibility of Teams and makes meetings more inclusive for those who are hard of hearing. Microsoft followed up with MC280258 (August 24), to announce support for transcripts and captions in 27 additional languages (Figure 4) to join the previous support for U.S. English.

Another Compliance Gap Nearly Closed

All the information shared during Teams meetings is gradually coming within the scope of compliance policies. eDiscovery can already find chat, presentations, and documents, and the advent of indexed speech means that spoken comments should soon come within the scope of eDiscovery searches. This hasn’t happened yet, probably because of the work needed to export transcripts and videos in eDiscovery cases, but I am sure this capability is high on Microsoft’s agenda.

Although the captured text is sometimes inaccurate, capturing any record of spoken comments is better than nothing. As time goes by, the artificial intelligence technology used to analyze speech to create the transcript will improve in terms of accuracy and ability to handle accents.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what’s happening.

Keeping an Eye on Retention Policies

A reader asked how to monitor retention policy settings so that any change is highlighted for audit purposes. Given the influence retention policies can have on content stored in Exchange Online, SharePoint Online, OneDrive for Business, and Teams, it’s a good idea to keep an eye on policy updates, if only to know who did what if a retention policy update goes bad. The nature of retention policies is that they seldom need updating after their implementation. Valid reasons for updating retention policies include changing the retention period (for instance, from five to seven years) or adding retention locations.

Alert policies (managed in the Microsoft 365 compliance center) are a natural starting point for administrators needing to monitor configuration changes, until you discover that alert policies are quite inflexible and can check only a limited set of activities (Figure 1). Retention policy updates are not included in the list.

Types of Retention Policies

One reason why alert policies might not include retention policies in the set of supported actions is that retention policies cover several scenarios:

• Org-wide retention policies applying retention settings to all target locations for a workload, like all SharePoint Online sites. Retention policies for Teams or Yammer can only process the compliance records belonging to those workloads.
• Non-org wide retention policies applying retention settings to targeted locations.
• Auto-apply retention policies to apply retention labels to items matching criteria (like the auto-label policy to find and apply retention labels to Teams meeting recordings).

Fortunately, when people create, update, or remove retention policies, the compliance center captures audit events in the Office 365 audit log. This data is used for audit log searches, alert policies, and by Microsoft 365 Cloud App Security (including the Office 365 Cloud App Security variant included in Office 365 E5), so nothing is lost or overlooked if you search the audit log. However, as we’ll discuss, the audit events logged for retention policy updates are not as informative or useful as you might like.

Searching the Audit Log

As always when searching the audit log, it’s important to know what you’re looking for. I know that sounds trite but given the number of audit records captured and the volume of data processed for any reasonably-sized tenant, looking for records for a specific action can often be like looking for the proverbial needle in a haystack. My normal approach is to perform the action I want to monitor so that the workload generates an audit event, wait for 30 minutes or so, and then run an audit log search for the period when I performed the action. This gives Office 365 time to ingest audit records into the log. I can then look at the records found by the search to find the one relating to the action performed. The event will include a value in the Operations property of the audit records to use with subsequent audit log searches to find the events I want to analyze.

Because retention policies use a parent-child structure composed of the policy (basic settings) and rules (actions), two operations record changes to retention policies, The SetRetentionCompliancePolicy event captures changes to a policy while the SetRetentionComplianceRule events logs any changes to the rule belonging to a policy.

Processing Retention Audit Policy Records

On the surface, the task therefore seems straightforward:

• Set a date range for the audit log search.
• Search the audit log for events of the desired types occurring in the date range.
• Process the returned audit records to extract and report data.

The first two steps are easy; the third is more challenging because of the way Microsoft uses Base64 encoding to obscure the retention policy name in the audit records. I don’t know why this is required. The only people likely to look at audit records are administrators, and they can see the names of retention policies in the Compliance Center. Nevertheless, we end up needing to process audit log data like this:

CreationTime       : 2021-07-23T11:16:28
Id                 : 14ed1f37-8c48-4980-7fbf-08d94dcb5122
Operation          : SetRetentionCompliancePolicy
OrganizationId     : b662313f-14fc-43a2-9a7a-d2e27f4f3478
RecordType         : DataGovernance
UserKey            : eff4cd58-1bb8-4899-94de-795f656b4a18
UserType           : Regular
Version            : 1
Workload           : SecurityComplianceCenter
UserId             : Tony.Redmond@office365itpros.com
ExtendedProperties : {@{Name=Workload; Value=Exchange, SharePoint, OneDriveForBusiness, Skype, ModernGroup}, @{Name=CreatedBy; Value=Tony Redmond}, @{Name=CreatedDateUTC;
                     Value=28/04/2017 19:12:30}, @{Name=LastModifiedDateUTC; Value=29/04/2017
                     02:07:40}...}
ObjectType         : CompliancePolicy
Parameters         : {@{Name=CmdletOptions; Value=-Identity
"OTk2ZjI2MDMtZTE2NC00MGRkLWEwNTAtYzUzZDdjYTQzOWU30" -Comment "This retention policy removes old items from Office 365 Groups that use a connector to fetch content from an external data source like Twitter. 
Updated 23 July 2021"}, @{Name=Cmdlet; Value=Set-RetentionCompliancePolicy}}

Feeding the identity OTk2ZjI2MDMtZTE2NC00MGRkLWEwNTAtYzUzZDdjYTQzOWU30 into an online Base64 decoder reveals the value to be 996f2603-e164-40dd-a050-c53d7ca439e7. In other words, it’s a GUID. You can then check the set of retention policies to find the name of the policy with that GUID. All of this is very possible, but it’s more work than is needed. What’s especially infuriating is that the audit records for the SetRetentionComplianceRule events report policy names in clear text.

Another issue I ran into is that the Get-RetentionCompliancePolicy cmdlet does not return the full set of policies in a tenant. The cmdlet doesn’t return details of retention policies created to process Teams private channels or Yammer communities. To find these policies, you must run Get-AppRetentionCompliancePolicy. Apparently, Microsoft distinguishes between app-specific retention policies and more general-use retention policies. This theory is undermined by the fact that retention policies for Teams (regular) channel messages and chats are returned by Get-RetentionCompliancePolicy. It would be nice to have some consistency in how the PowerShell cmdlets for retention policies work.

The Eventual Code

The flow of the code I wrote ended up like this:

• Create a hash table containing the GUID and name of the retention policies in the tenant. Separate calls are made to Get-RetentionCompliancePolicy and Get-AppRetentionCompliancePolicy to make sure that the hash table contains the GUIDs of all policies. Later, we look up the hash table to resolve GUIDs into policy names.
• Find the audit records for retention policy updates. I chose to go back 30 days. Office 365 E3 tenants can go back 90 days while Office 365 E5 tenants can go back 365 days.
• Split the records into retention policy updates and retention rule updates.
• Process the retention rule updates to create a report.
• Process the retention policy updates to create a report. This is where we need to convert values from Base64 and do lookups in the hash table to know the names of the retention policies.
• Generate output files in CSV format and display the retention policy updates on-screen using the Out-GridView cmdlet (Figure 2).

The main loop to process the audit records is shown below. You can see how the Base64 version of the policy name is extracted from the AuditData property of the audit record, converted to a GUID, and then resolved against the hash table to end up with the policy name:

$AuditReport = [System.Collections.Generic.List[Object]]::new() 
ForEach ($AuditRecord in $AuditRecords) {
    $AuditData = $AuditRecord.AuditData | ConvertFrom-Json
    $PolicyDetails = $AuditData.Parameters | ?{$_.Name -eq "CmdletOptions"} | Select -ExpandProperty Value

    $PolicyName = $Null; $PolicyGuid = $Null; $Encodedtext = $Null
    If ($PolicyDetails -Like "*RetryDistribution*") { # The change is to restart distributions to target locations
       $Start = $PolicyDetails.IndexOf('"')+1
       $End = $PolicyDetails.IndexOf("-Retry")-13
       $PolicyName = $PolicyName = $PolicyDetails.SubString($Start,$End) }
   Else { # Update made to the policy
      $Start = $PolicyDetails.IndexOf('"')+1
      $EncodedText = $PolicyDetails.SubString($Start,48)
      $PolicyGuid = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String($EncodedText))
      $PolicyName = $RetentionPolicies.Item($PolicyGuid) # See if we can find the retention policy name
   }

    $DataLine = [PSCustomObject] @{
         Date                = $AuditRecord.CreationDate
         User                = $AuditData.UserId
         Policy              = $PolicyName  
         PolicyGuid          = $PolicyGuid
         DetailsLogged       = $PolicyDetails
         EC                  = $EncodedText }
    $AuditReport.Add($DataLine) 
}

You can download a copy of the script from GitHub. I’ll leave it to you to decide how the information is distributed (via email, posting to a Teams channel, or in a printed report) and if you want to extract more information from the details extracted for each audit record. For instance, this information tells us that the retention policy update is to add public folders as a target location and remove OneDrive for Business.

-Identity "ZDNiYmIyY2ItMzRjMC00ZWMxLWE0MTgtMzRmZWY2YzU2MzNi0" -AddPublicFolderLocation ("All") -RemoveOneDriveLocation ("All")

While this information shows an update to the policy description and the addition of a selected Microsoft 365 group as a location:

-Identity "NmE5ZjdiZjAtNTA3Yi00YTQ5LTgzYzMtMDFhNzAxOTU4ZDEx0" -Comment "Make sure that Office 365 for IT Pros source documents are not deleted." -AddModernGroupLocation ("Office365ITPros@Office365ITPros.com")

More Difficult Than It Should Be

After spending the best part of two days figuring out what was going on and coding up a solution, I think it’s fair to say that reporting retention policy updates using the Office 365 audit log is a more complicated and difficult task than it should be. The introduction of a new cmdlet for certain policies, the use of Base64 coding to obscure policy names, and the general formatting of the information contained in the audit records all create problems. A little thought into how to simplify and improve the format and content of audit data would go a long way to making this task as straightforward as it should be.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Applying Governance to Graph-Based Apps

Update (November 3): The App governance add-on is out of preview and generally available.

In mid-July, Microsoft introduced the preview of an app governance add-on for Microsoft Defender for Cloud Apps (MCAS), describing the new capability as a “security and policy management capability designed for OAuth-enabled apps that access Microsoft 365 data through Microsoft Graph APIs.”

There’s no doubt that tenants can accumulate a collection of Graph-enabled apps over time. The apps come from Microsoft, ISVs, and line of business apps. Indeed, any PowerShell script you write to interact with the Graph APIs gains its permissions through consent granted to an app registered with Azure AD. The net result is that you can end up with hundreds of registered apps, all with Graph permissions, some of which you might not know much about. App governance aims to deliver a structured management framework for those apps, leveraging information taken from Azure AD and MCAS.

Microsoft research clearly shows that attackers use illicit consent grants for Graph-based apps to extract and abuse data. Given the likelihood that organizations will have more Graph-based apps to manage over time, it’s important that administrators understand app usage in their tenant. Unfortunately, the need to review and analyze app usage often falls down task lists, which is the hole the app governance add-on attempts to close.

The Need for MCAS

MCAS isn’t included in any Office 365 plan. Office 365 E5 includes Office 365 Cloud App Security (OCAS), a cut-down version of the full-blown MCAS. Both operate on the same basis of data gathered from user and app activity, but MCAS delivers more functionality and covers more apps. For this pleasure, tenants need to pay more to license MCAS, unless they’ve already invested in Microsoft 365 E5, Enterprise Mobility and Security E5, or one of the other licenses which cover MCAS. You need MCAS to use the new add-on, which doesn’t work with OCAS.

Fortunately, Microsoft offers organizations the chance to run a 30-day trial for MCAS by signing up through the Purchase services section of the Microsoft 365 admin center. After starting the MCAS trial and assigning some licenses to accounts with suitable administrator roles, you can go ahead and start a trial of the add-on. Curiously, the add-on allows a 130-day trial, which might be due to its desire to capture and analyze usage data for apps over a reasonable period. Of course, if you sign up for both trials, MCAS expires after 30 days, and you won’t be able to use the add-on afterwards.

Using App Governance

App governance runs within the Microsoft 365 admin center. If your account isn’t licensed or doesn’t hold one of the necessary compliance roles, you’ll be told this unhappy news if you attempt to access the page. Licensed administrators see a preview of the app situation in the tenant (Figure 1).

I had recently been through an audit of apps based on grabbing app data from Azure AD and reviewing the data through Microsoft Lists, so there are fewer apps present in my tenant than existed previously. As I reviewed the data set, I found a couple of additional apps that I could disable or remove. You can disable an app by viewing its properties through App governance; to remove it, you need to use the Azure AD admin center. Disabling is a good first step to removing a potentially problematic app as you can easily enable the app if someone reports that a business case exists for its use.

In my tenant, app governance detected 33 high privileged apps and 13 overprivileged. Microsoft’s definitions for these categories are:

• High privilege: Consent has been granted to the app for Graph permissions that allow the app to access data or change key settings in the organization.
• Overprivileged: Consent has been granted to the app for Graph permissions the app doesn’t use.

To examine details of an app to understand why it falls into a certain category, click Apps, and peruse the list of apps to select and view the app properties (Figure 2).

As you can see, the portal includes several filters to limit the set of displayed apps. The set of available filters misses one to show disabled apps. This means that if you need to find a disabled app, perhaps to reenable it if the app had been disabled in error, you either need to know the name of the disabled app or do a lot of checking to find the right app.

Probing Permissions

Mmany apps fall into the high privilege category because they read user information. For example, the app used by Microsoft Ignite conference attendees to register has permission to see the user’s email and profile. Apps created by ISVs to read and report tenant data need access to the directory, and that is flagged as a high privilege permission because attacker apps also use the permission to find targets. Even Microsoft’s own Information Barriers app is flagged as high privilege because it has the Directory.Rewrite.All and Groups.Rewrite.All permissions. As always, understanding the context of what an app does is necessary to understand why it needs permissions.

App governance allows tenant administrators to automate checks by creating policies to monitor the creation of overprivileged or high privilege apps. This functionality works like the other alert policies available in the Microsoft 365 compliance center with the exception that the input data focuses on apps rather than actions. As you can see in Figure 1, policies quickly flag new apps which violate criteria. But as pointed out above, you then need to check the app to figure out if a problem really exists.

Permission Glitches

The add-on is a preview, so glitches are expected. For example, app governance flagged an app written to support adding organizational contacts to new user mailboxes as overprivileged. When I examined details of the app (Figure 3), the unused permission is Contacts.ReadWrite. This is odd because that’s the exact permission needed to write a new contact record into a mailbox.

Apart from app details and permissions, App Governance promises to show data about usage and users. Taking users first, I thought this information to be quite useless. The information shown on Figure 4 tells me that 237 consented users exist (Azure AD accounts with data the consents granted to the app covers). This figure includes both tenant and guest accounts and results because an administrator granted consent to the app for the entire organization (if consent is given for individual accounts, they are listed here). The five priority users are those marked as priority accounts. None of the priority accounts (including my own) had any trace of data uploaded or downloaded using the app. Given the app is Microsoft’s Graph Explorer, which I use to test Graph API queries almost daily, this was surprising.

After being disappointed with the data available for users, I didn’t hold out much hope for the Usage (beta) tab. And my expectations were met as precisely nothing showed up here. Instead, App governance informed me that no data was present. Oh well, it’s a preview.

DIY App Governance

As mentioned above, it is relatively simple to perform a DIY audit of Microsoft 365 Graph-enabled apps. Home-grown knowledge of apps used in a tenant is an advantage MCAS can’t deliver, but to exploit that knowledge, some work is necessary to acquire, refine, and understand the app inventory – and to keep on checking on a systematic basis.

App governance extends simple auditing by including policy-based management, categorizing apps based on the permissions they hold, and delivering some insights into app usage. Although still just a preview with all that implies, if your organization has MCAS, the add-on is a useful enhancement. If not, although the need to monitor the granting and usage of permissions in Graph-enabled apps is a real need, you might be able to construct your own method to achieve the goal.

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology.

Moving From Static Retention Targets

Announced in private preview in May 2021 and documented in Microsoft 365 roadmap item 70578 as available in August 2021, adaptive scopes should be a welcome extension to retention and retention label policies.

These policies currently suffer from a lack of granular targeting. You can create org-wide policies which apply everywhere or select locations (mailboxes, sites, Microsoft 365 Groups, or Exchange public folders). Being able to target certain locations is sufficient for many organizations but isn’t flexible enough for some, especially those which run into the limits for non-org-wide retention policies (like a maximum of 1,000 selected mailboxes). It’s possible to use PowerShell to adjust the locations processed by retention policies, but few do this.

Update October 28: The preview of adaptive scopes was delayed. They are now available in all tenants.

The Advantage of Adaptive Scopes

Enter adaptive scopes, so-called because they use filters to find target locations which might change over time (for instance, following the creation of new mailboxes or sites). A change in nomenclature labels older retention policies as static because they use a fixed set of targets which don’t change unless an administrator updates the policy.

From a technology perspective, there’s nothing new in how an adaptive scope works because the three available variants use tried-and-trusted mechanisms. The name covers the ability to apply filters in different ways:

• Mailboxes: Use Azure AD account properties to select target mailboxes similar to building a query for a dynamic Microsoft 365 group. For example, find all the mailboxes located in Germany and Switzerland.
• Sites: Use a KQL query to find target sites. In most cases, to identify specific sites such as all those belonging to a certain department, you’ll need to update the delightfully-named “site property bag.” The property bag holds key/value pairs which you can use as you wish. The Set-PnpPropertyBagValue cmdlet from the SharePoint PnP PowerShell module is a good way to update the values used to select sites.
• Groups: Use attributes of Microsoft 365 Groups to define the set of target groups.

After creating an adaptive scope, you can use it in a retention policy or to publish retention labels to the mailboxes, sites, and groups which come within the scope.

Adaptive scopes are not subject to the same limitations as non-org wide retention policies. For instance, your organization might have 10,000 user accounts located in the United States. An adaptive scope based on the Azure AD Country account property will find those mailboxes (assuming your directory is accurate) and make them targets for a retention policy which uses the scope.

The Licensing Question

Microsoft hasn’t said anything about the licensing requirements for adaptive scopes. My bet is that this will be a feature licensed through Office 365 E5 or Microsoft 365 E5 compliance. The usual rule applied by Microsoft is to seek higher licenses for anything in the Information Governance/Protection area which includes an element of automation. Adaptive scopes automate the application of retention policies and appear to be a prime candidate for inclusion in E5. Maybe I’ll be surprised, and Microsoft will include adaptive scopes in Office 365 E3, but I don’t expect this will be the case.

Fills in a Gap in Retention Policies

Updated: 8 September 2021

Message Center notification MC263844 (June 22, Microsoft 365 roadmap item 70562) might have puzzled some who hadn’t realized that retention policies to process messages in Teams channels don’t apply to private channels. The good news is that the change to introduce processing for private channels is in preview and should become general available in late July 2021 (MC283589 posted on September 8 announced the general availability, so the feature was about two months late).

Private channels debuted in November 2019 at the Microsoft Ignite conference. Private channels serve a subset of a team’s membership. There can be up to 30 private channels in a team (compared to 200 normal channels), and each private channel includes a dedicated SharePoint team site for document sharing. Only the members of a private channel can access its conversations and documents.

Private Channels and SharePoint

Retention processing for the SharePoint sites used for private channels isn’t a problem because regular retention policies for SharePoint sites can include the private sites. Remember, if a retention policy isn’t org-wide (covers all sites in a tenant), individual sites must be added as a location for the policy and adding a site for a private channel is the same as adding a site for a regular team. In both cases, you add the URI for the site to the policy.

Processing Private Messages

Private channel messages pose a different compliance problem. Unlike a regular channel, private channels don’t have a group mailbox. It’s therefore not possible to store compliance records in the group mailbox as happens for regular channels. The choice the developers came up with is to follow the model used for personal and group chats and store compliance records for private channel messages in the Exchange Online mailbox of every channel member. If hybrid or guest accounts are members of a channel, the compliance records go into the special cloud-only mailbox Microsoft 365 provisions to capture data for guest, hybrid, and federated users. This arrangement ensures that Microsoft 365 can index and search for private channel messages.

Using personal mailboxes means that compliance records for private channels intermingle with compliance records for chats. Retention policies can process Teams chats but have always ignored the compliance records for private channels because organizations might want to apply different retention settings to the two sets of records.

This is now changing with MC263844, and organizations will be able to configure retention policies to process Teams private channel messages (Figure 1). It’s important to note that a retention policy for Teams private channel messages can only process those messages. The policy cannot include any other location, even Teams chats or regular channel messages. You’ll also notice that accounts are the basis for inclusion or inclusion in the policy rather than the teams hosting private channels. Again, this relates to where the compliance records are held plus the fact that not all members of a team (group) necessarily are members of the private channels owned by the team.

Separating Chat from Channel Messages

The point is made above that the Exchange Online mailbox for private channel members intermingles compliance records for private channel messages with those for chats. When a retention policy processes a mailbox, it can search for private channel data by examining the MAPI properties of compliance records. For example, the thread type property for a chat is “chat” while it’s “space” for channel messages. Another item property (shown in Figure 2 as viewed through the MFCMAPI program) is an even clearer identification of private channel messages. The value for this property for chat messages is “MicrosoftTeams.”

The task of the retention policy for Teams private channel messages is therefore to find the relevant compliance records (in all mailboxes of private channel members) and examine each item to see if its retention period has expired. If this is the case, the retention policy removes the item, in turn triggering a synchronization process back to the Teams data store (Azure Cosmos DB) to remove its copy of the message. Eventually, clients refresh their local cache of messages and learn about the deletion and the message disappears from user view.

Surprisingly Delayed but Welcome

It’s surprising that it has taken so long for Microsoft to figure out how to manage retention for private channel messages. The impending arrival of shared channels later this year possibly helped accelerate progress. However, arguing against myself, shared channels are more closely connected to the home team and might store their compliance records in the group mailbox. We shall just have to wait and see.

Insight like this doesn’t come easily. You’ve got to know the technology and understand how to look behind the scenes. Benefit from the knowledge and experience of the Office 365 for IT Pros team by subscribing to the best eBook covering Office 365 and the wider Microsoft 365 ecosystem.

Communications Compliance Gains Yammer Support

The advent of support for Yammer conversations in Microsoft 365 Communications Compliance policies created some questions about how monitoring works and if Yammer compliance records served any role. The answer is simple:

• A Yammer network can’t support communications compliance unless it is configured in native Microsoft 365 mode. This step connects Yammer communities with Microsoft 365 groups.
• When in Microsoft 365 mode, the Microsoft 365 substrate captures compliance records for Yammer conversations. The compliance records are mail items stored in the Exchange Online mailbox for the Microsoft 365 group belonging to the community. Compliance records for private Yammer conversations are in the Exchange Online mailboxes for conversation participants.
• Communications compliance policies monitor compliance records to look for problematic content such as threatening behavior. If policies detect issues, investigators work with copies of compliance records stored in special supervision mailboxes to resolve whatever is found.

All of this sounds very familiar because it’s exactly the same approach used by Teams. The only difference is that Teams stores its compliance records in a folder called TeamsMessagesData while Yammer uses one called MessageIngestion\Yammer. Both folders are in the non-IPM section of mailboxes and are invisible to users.

Indeed, in early 2021, Microsoft announced that Planner would adopt the same substrate-driven approach to achieve compliance. However, they have since taken that idea off the table.

eDiscovery

The compliance records for Yammer are mail items. Like the compliance records captured for Teams, the Yammer compliance records are not perfect copies of the messages posted to Yammer communities or privately between users. However, the items are good enough for compliance purposes, and because they’re stored in Exchange Online, the items are indexed and discoverable.

Yammer messages come in several types, including:

• Praise.
• Questions.
• Announcements.
• Polls.
• Discussion.

In addition, the messages can include GIFs, graphics, and reactions.

To discover what content is captured and discoverable, I posted a range of message types to a Yammer community and in private messages. I then ran a content search to find the messages (Figure 1). You’ll notice that the mail items the substrate creates for Yammer compliance records do not support preview. Also, Praise messages don’t have subjects or titles, which accounts for the message with No subject in the sample set.

By definition, the preview sample retrieved by a content search (or in Core eDiscovery) is not every message that a search can find. The full set is only recovered by exporting search results. To examine the items, you can export the results to a PST (or a PST per mailbox) and open the PST in Outlook. Figure 2 shows a Yammer message with a GIF as displayed by Outlook.

You can see that the search found items in the Yammer folder as expected. Some also came from the SubstrateHolds subfolder in Recoverable Items. For some reason, these items stored Yammer poll messages.

Reactions are the only major missing element for Yammer compliance records. This isn’t surprising because the same issue exists for Teams.

Because the compliance records are in Exchange Online mailboxes, you can examine their properties and content with the MFCMAPI utility. Figure 3 shows the compliance record for a Yammer private message as viewed in MFCMAPI. The message is a single line of text surrounded by a bunch of HTML that doesn’t seem to do a lot.

Tracking Yammer Community Activity

Early versions of the Teams and Groups Activity Report used the Get-ExoMailboxFolderStatistics cmdlet to check the presence of compliance records in group mailboxes to understand the activity level of teams and groups. Although the latest version of the script sped up processing by using Graph API calls instead, the cmdlet is still a good way to check the Microsoft 365 Groups used by Yammer communities for activity.

The code needed is straightforward. First, find the set of groups used by Yammer. Next, use Get-ExoMailboxStatistics to fetch the folder data. Finally, report the data after calculating how long it’s been since someone posted to the community. Here’s the basic code:

[array]$YammerGroups = Get-UnifiedGroup -ResultSize Unlimited |?{$_.GroupSku -eq "Yammer"}

If (!($YammerGroups)) {Write-Host "No Microsoft 365 Groups found for Yammer -exiting"; break}

$YammerData = [System.Collections.Generic.List[Object]]::new()
ForEach ($Group in $YammerGroups) {
  Write-Host "Processing" $Group.DisplayName
  $Folder = (Get-ExoMailboxFolderStatistics -Identity $Group.ExternalDirectoryObjectId -Folderscope NonIPMRoot -IncludeOldestAndNewestItems | ?{$_.FolderType -eq "Yammer"})
  If ($Folder.NewestItemReceivedDate) {
    $TimeSincePost = New-TimeSpan ($Folder.NewestItemReceivedDate)
    $FormattedTime = "{0:dd}d:{0:hh}h:{0:mm}m" -f $TimeSincePost }
  Else { 
      $FormattedTime = "N/A" }
  $ReportLine = [PSCustomObject][Ordered]@{  
     DisplayName = $Group.DisplayName
     Items       = $Folder.ItemsInFolder
     NewestItem  = $Folder.NewestItemReceivedDate
     TimeSincePost = $FormattedTime }
  $YammerData.Add($ReportLine)
} # End For
     
$YammerData | Sort Items -Descending | Out-GridView

The script is available for download in the Office 365 for IT Pros GitHub repository.

Figure 4 shows the community statistics generated from the compliance records in my tenant. Obviously, Yammer doesn’t get much usage, but the data is sufficient to prove the point.

Only Modern Yammer

Remember that Yammer (or rather, the Microsoft 365 substrate) generates compliance records only when networks run in native Microsoft 365 mode. This is now the default for new tenants who’ve never used Yammer before. For older tenants still using traditional Yammer, some work needs to be done before they can enjoy the useful compliance records.

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

Change to Remove Inconsistency

Retention policies and retention labels both make sure that workloads like SharePoint Online retain information needed by organizations. Retention policies are broader in scope and apply default retention to any location coming within their scope. For instance, if you apply a retention policy to a set of SharePoint sites, any file within those sites come within the scope of the policy. Retention labels are more granular and apply to individual items, whether assigned by users or through auto-label policies (like the example of using an auto-label policy to retain Teams meeting recordings). Because they are more specific, retention labels take precedence over retention policies.

It’s up to an application how to implement the application of retention labels to items. It’s also up to applications how to respect the fact that a retention label exists on an item. Different behaviors have existed in the SharePoint Online and OneDrive for Business browser interfaces since the introduction of retention labels in 2017. According to MC264360 (June 24) – Microsoft 365 roadmap item 82063, Microsoft is closing the inconsistency and SharePoint Online will adopt the OneDrive for Business approach.

Deleting SharePoint Online Items

Today, if you try and delete an item in a SharePoint Online document library, the UI prompts for the deletion to proceed and if confirmed, attempts to delete the item. If the item is labeled, the deletion fails (Figure 1) and the user sees that removal isn’t possible because of the label.

There’s nothing to stop the user removing the label and then deleting the file, unless it’s a record label (only a site administrator can change a record label).

By comparison, you can delete an item in a SharePoint Online document library which comes within the scope of a retention policy. Although seemingly inconsistent (because the organization wishes to retain the items by policy), SharePoint Online allows the deletion to proceed and moves the item into the site recycle bin. Eventually, when the item expires in the recycle bin, SharePoint Online moves it into the site’s Preservation Hold library where it stays until its retention period lapses.

OneDrive’s Streamlined Approach

OneDrive for Business takes a streamlined approach to item deletion and allows users to remove items as they wish (Figure 2).

Deleted items go into the OneDrive for Business recycle bin (Figure 3). Users can recover deleted files from there using the Restore your OneDrive feature.

After 90 days, deleted files leave the recycle bin for either permanent removal or retention. If a retention policy or label applies to an item, it moves to the Preservation Hold library (Figure 4) and stays there until its retention period lapses. Of course, retention can be a complex business and an item might come under the scope of a retention policy after retention due to a label lapses. In any case, once no further retention applies to an item, a background job removes the item. Removed items are irrecoverable unless a backup exists.

The Goodness of Consistency

You can argue that either approach makes sense. Some like it that SharePoint Online stops people deleting labeled items. It’s a form of affirmation that the file is important. On the other hand, allowing deletion to happen but preserving files needed for retention is a lower-friction method which prevents potential user confusion (why can I delete that file but not this one?). Overall, achieving consistency across OneDrive for Business and SharePoint Online is a good thing and lowering friction is also a good thing, especially if it stops some support calls. We’ll see how users react (or even notice) after Microsoft rolls out the change in August.

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

7 June 2024: See this article for updated coverage of this topic.

How Administrators Can Find Out When Recordings Occur

Recently, I published two posts explaining how auto-label retention policies for Teams meeting recordings work and how to validate that an auto-label policy works. All is well, and the auto-label policy apply the right retention labels to the right files in the right locations, which is what you want.

The inevitable question then arose: how can administrators know when someone records a Teams meeting? The book answer is that neither Teams nor Office 365 offer an obvious way to know when a new recording happens. Recording is, after all, a personal action decided by the meeting organizer or a presenter (or invoked automatically by a meeting setting). Once the meeting policy assigned to the organizer or presenter allows them to use “cloud recording,” Teams records the meeting and captures the MP4 file in OneDrive for Business (personal meetings) or SharePoint Online (channel meetings).

Recording a meeting is not an auditable activity so it’s not captured in the Office 365 audit log. However, the creation of a new file in OneDrive for Business or SharePoint Online is auditable, so we can examine those events to see if we can track new recordings.

Audit Events for a Teams Meeting Recording

First, let’s consider what happens on the creation of a new Teams meeting recording. Three events appear in the audit log:

• Creation of a temporary MP4 file in a FileUploaded event.
• Modification of the temporary file in a FileModified event. This is likely when Teams updates the properties of the file to add the programmatic identifiers Media and Meeting which mark the file as a Teams meeting recording.
• Renaming the file name of the temporary file to its final form. This is also in a FileModified event. The temporary file has a prefix of “~tmp.” Teams removes the prefix to create the final file name in the form meeting name, date, and “meeting recording.” For example, the file called H2 FY2021 Review 20210615_140058-Meeting Recording.mp4 is for a Teams meeting on June 15, 2021, starting at 14:00:58 (local).

Equipped with this knowledge, we can search the audit log with the Search-UnifiedAuditLog cmdlet and parse the audit events to extract data for analysis.

PowerShell Script to Find Creation of Teams Meeting Recordings

The PowerShell code is straightforward:

• Use the Search-UnifiedAuditLog cmdlet to retrieve the set of audit events for FileModified and FileUploaded actions over a set period (I used 14 days).
• Parse the AuditData content in each audit event to figure out if it’s a Teams recording. The basic test used is that the file is an MP4 stored in the /Recordings folder.
• Extract information about the recording and write to a PowerShell list. For instance, it’s good to know the title of the meeting.
• Finally, extract the records for the temporary file to create a set for the final creation of Teams meeting recordings. Output this data to the screen with Out-GridView and to a CSV file.

Here’s the main processing loop:

$StartDate = (Get-Date).AddDays(-15)
$EndDate = Get-Date
[array]$Records = Search-UnifiedAuditLog -Operations FileUploaded, FileModified -StartDate $StartDate -EndDate $EndDate -Formatted -ResultSize 5000 -SessionCommand ReturnLargeSet

If (!($Records)) {Write-Host "No audit records found - exiting!"; break}

$Records = $Records | Sort-Object Identity -Unique

$TaggedRecordings = [System.Collections.Generic.List[Object]]::new() 	
ForEach ($Rec in $Records) {
   $AuditData = $Rec.AuditData | ConvertFrom-Json
   If (($AuditData.SourceFileExtension -eq "mp4") -and ($AuditData.SourceRelativeUrl -like "*/Recordings")) { 
      $A = $AuditData
      $RecordingFileName = $AuditData.SourceFileName
      $DateLoc = $RecordingFileName.IndexOf("-202")
      If ($DateLoc -eq -1) {$Topic = $RecordingFileName} Else {$Topic = $RecordingFileName.SubString(0,$DateLoc)}
      $DataLine = [PSCustomObject] @{
         Workload            = $AuditData.Workload
         Date                = $Rec.CreationDate
         User                = $Rec.UserIds
         Recording           = $RecordingFileName
         "Meeting title"     = $Topic
         Site                = $AuditData.SiteURL
         FullURL             = $AuditData.ObjectId
         Folder              = $AuditData.SourceRelativeURL
         Operation           = $Rec.Operations }
    $TaggedRecordings.Add($DataLine) 

   } #End If
} #End For

Figure 1 shows the output as viewed through Out-GridView.

You can download the complete script from GitHub.

Search-UnifiedAuditLog can return up to 50,000 audit events from the log. In large tenants where many document events accrue daily, you might exceed this number of audit events in a couple of days or even sooner. In this situation, you’ll need to fetch audit events and store them in another repository and analyze them from there.

Exploit the Audit Log

People sometimes complain when they can’t find a simple off-the-shelf option in a Microsoft 365 administration GUI to do something. The Office 365 audit log contains lots of interesting information which answers many questions, like who’s creating Teams meeting recordings. You only have to look. Or rather, know where to look.

Learn how to exploit the Office 365 data available to tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Opening the Black Box

My article about how to create an auto-label policy to apply retention labels to Teams meeting recordings resulted in several questions. As I noted in the article, tracking the progress of auto-labeling can be challenging due to the black-box nature of the background processes which search for recording files to label. One suggestion was to use the technique explained in this blog post to use the SharePoint Online PnP PowerShell module to connect to sites and retrieve information about retention job activity. For example:

$SiteURL = "https://office365itpros.sharepoint.com/sites/Office365Adoption/"
Connect-PnPOnline -Url $SiteURL -Interactive
get-pnppropertybag -key "dlc_policyupdatelastrun"
get-pnppropertybag -key "dlc_expirationlastrunv2"
2/23/2021 11:18:42 PM
2/2/2021 8:02:41 PM

The first value (dlc_PolicyUpdateLastRun) is the date when the background job to evaluate retention dates for items last ran. The second (dlc_ExpirationLastRunv2) tells you the last time the background job ran to execute the retention action defined in labels when retention periods expire.

The background jobs which evaluate retention dates and execute actions are not directly connected to auto-label processing, but they give an insight into how SharePoint Online processes sites. In a nutshell, if a site is active, the background jobs process its content. If not, the site is ignored. This makes a lot of sense because it avoids SharePoint doing a bunch of work to check items in sites where no work is necessary. I don’t know if another value stores a date when action must be taken to process expired items, but it would make sense if it did.

These values date back to legacy management processing in SharePoint on-premises and while they still work, Microsoft introduced a new retention processing engine last year which might eventually nullify their use.

Off to the Audit Log

Interesting as these values are, they don’t tell us anything about the application of labels. In the last article, I mentioned that the Office 365 audit log captures the TagApplied event when a person or policy applies a retention label to an item. The audit events are available roughly 15 minutes after they occur, so this source seemed like a good place to investigate.

I ended up writing a script to do the following:

• Find audit records for the TagApplied event in the last 14 days.
• Filter the records to find those which apply the retention label used by the auto-label policy. The same filter makes sure to only select records for policy rather than user application.
• Find the date of the recording from the file name generated by Teams. For instance, a recording named Call with James Ryan-20210217_141123-Meeting Recording.mp4 started at 14:11 on 17 February 2021.
• Calculate how long it took to auto-label the recording file (the difference between the date the call started and the audit record).
• Write the details to a SharePoint list to make the data available for additional analysis.

Here’s the main loop of the code to process the audit records. You can download the complete script from the Office 365 for IT Pros GitHub repository.

[array]$Records = (Search-UnifiedAuditLog -Operations TagApplied -StartDate $StartDate -EndDate $EndDate -Formatted -ResultSize 2000)
$TaggedRecordings = [System.Collections.Generic.List[Object]]::new() 
ForEach ($Rec in $Records) {
   $AuditData = $Rec.AuditData | ConvertFrom-Json
   If (($AuditData.DestinationLabel -eq $RetentionLabel) -and ($AuditData.UserType -eq "CustomPolicy")) { 
      $RecordingFileName = $AuditData.DestinationFileName
      $DateLoc = ($RecordingFileName.IndexOf("-202")+1)
      $RDate = $RecordingFileName.SubString($DateLoc,8)
      $TimeLoc = $DateLoc + 9
      $RTime = $RecordingFileName.SubString($TimeLoc,4)
      $RecordingDateTime = $RDate + $RTime
      [datetime]$RecordingDate = [datetime]::ParseExact($RecordingDateTime,"yyyyMMddHHmm",$null)
      [datetime]$TaggingDate = Get-Date($AuditData.CreationTime)
      $TimeToTag = ($TaggingDate - $RecordingDate)
      $TotalSeconds = $TotalSeconds + $TimeToTag.TotalSeconds
      $TimeToTagFormatted = "{0:dd}d:{0:hh}h:{0:mm}m" -f $TimeToTag
# Add the data about our record          
      $DataLine = [PSCustomObject] @{
         Workload            = $AuditData.Workload
         Recording           = $AuditData.DestinationFileName
         "Retention Label"   = $AuditData.DestinationLabel
         "Tagging Date"      = Get-Date($AuditData.CreationTime) -format g
         "Recording date"    = Get-Date($RecordingDate) -format g
         "Days to label"     = $TimeToTagFormatted
         Site                = $AuditData.SiteURL
         FullURL             = $AuditData.ObjectId }
    $TaggedRecordings.Add($DataLine) 
   } # End if
} # End ForEach

The Final Answer

After processing all the audit records, I know what Teams meeting recordings the auto-label policy has labelled and how long it took on average for an item to receive a label.

25 audit records found for auto-applying the Teams recordings retention label between 09/06/2021 19:36:43 and 23/06/2021 19:36:43
Average elapsed time to auto-label recordings: 02d:13h:28m
The report file is available in C:\temp\TaggedTeamsRecordings.csv.

The average time between creation and labeling depends on the gap between the meeting and when the labeling job runs. This seems to be on a weekly workcycle and usually runs over the weekend, so labeling a recording can take anything up to a week. An average of between two and four days is normal given that Teams captures new meeting recordings over the work week.

The same technique can be applied to track the progress of any auto-label policy.

Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new development as they happen.

Picking Up Support for Retention Labels

Updated: 10-Nov-2021

We’re approaching the end of the transition for the storage of Teams meeting recordings from “classic” Stream to OneDrive for Business and SharePoint Online (ODSP). From August 16, 2021, Microsoft will begin the process of moving any tenant who has not yet transitioned to store new meeting recordings to ODSP. When Microsoft announced their intention to move away from the Azure-based storage used by classic Stream, they emphasized the advantages gained by storing recordings in ODSP. Among those advantages is the ability to apply retention policies to meeting recordings. Others include the ability to share recordings with external people and an increase in storage quota over the limited amount made available for Stream.

Building an Auto-Label Policy

The sad fact about meeting recordings is that they tend to age rapidly. After a month or so, the need to refer to the recording of any meeting is greatly diminished. And indeed, many organizations don’t want recordings kept for any great length of time. An auto-label retention policy is the best way to find and remove Teams meeting recordings. The policy contains some conditions to identify items stored in ODSP and a retention label to apply. The retention label specifies the retention period (for example, two months), and the retention action (for example, permanently delete the item).

When Microsoft originally discussed the movement of Teams meeting recording to ODSP at Ignite 2020, they referenced a special retention policy to control recordings (see 15:00 in the recording) to be available in H1 CY21. That functionality hasn’t been delivered yet, and it’s important because it covers all licensing plans (SKUs). For now, Microsoft documents how to create an auto-label retention policy to remove recordings. Conceptually, the policy is very simple:

• Find Teams recordings: When Teams uploads a recording to ODSP, it stamps the MP4 file with ProgID attributes. This means that an auto-label policy can use a keyword search for ProgID:Media AND ProgID:Meeting to find recordings (Figure 1). Teams sets the ProgID (programmatic identifier) values for recordings when uploading the files to ODSP.
• Select the target locations: Most Teams recordings are from private meetings and end up in the meeting organizer’s OneDrive for Business account. Channel meetings end up in the channel folder in the SharePoint Online document library of the host team. The important thing here is to choose Microsoft 365 Groups as the target location type. You can also choose SharePoint sites if you expect to move or copy recordings around, but selecting Microsoft 365 Groups ensures that the auto-label policy finds recordings captured in the SharePoint sites connected to teams.
• Apply a retention label: Any retention label can be used, including those which require manual disposition.

Auto-label policies which run against ODSP locations depend on the indexing process to find matching items. As the process runs to populate the indexes used for Microsoft Search, it matches items using the criteria set in retention policies and applies the label specified in the policies.

The indexing process runs on an ongoing basis to detect new items and usually tags new recordings within a couple of days, depending on the overall load on the indexing service. My experience is that labels appear sooner in OneDrive for Business than they do in SharePoint Online. Frustratingly, it can happen that a policy labels some items in a location but not others, which might make you think that a policy isn’t working instead of reflecting how index updating proceeds. Eventually, everything gets caught up and all recordings have labels.

The Need for Licenses

Creating and applying an auto-label policy sounds like a good idea, until you realize that auto-label policies require Office 365 E5 or a Microsoft 365 E5 compliance license for all accounts covered by the policy. Many other licensed accounts generate Teams meeting recordings who can’t use auto-label policies. In these cases, users can apply retention labels manually (this function is covered by Office 365 E3 and E1 and Microsoft 365 Business Premium among other licenses). Manual application of retention labels is certainly feasible but this strategy relies on the discipline and thoroughness of user behavior, which isn’t always reliable. A generalized org-wide retention policy usually applies a longer retention period than desirable for Teams meeting recordings, so isn’t a good answer.

If you don’t want to use an auto-label policy, from January 2022 you should be able to apply a Teams-specific auto-expiration period to meeting recordings. The advantage of this approach is that retention is controlled by Teams meeting policies and is available to all Microsoft 365 plans which include Teams. And if you choose to use an auto-label policy, the retention labels assigned to meeting recordings will take precedence over Teams auto-expiration.

Interpreting the Effect of Black Box Policies

An auto-label policy is an impenetrable black box when it comes to reporting progress in processing items. Once you create or edit a policy and publish it to target workloads (ODSP in this case), all you can do is hope that the policy has the desired effect and labels the correct items. The compliance center gives no hint about when the policy last scanned a location, how many items matched, or overall totals for the tenant.

Three methods exist to check the effectiveness of an auto-label policy. The quick and easy method is to check the recordings in individual sites and accounts to verify if they have the correct retention label (Figure 2).

Checking individual recordings quickly becomes boring and there’s no guarantee when ODSP will process an auto-label policy against files. The Office 365 E5 and Microsoft 365 E5 licenses include access to the Activity explorer in the Data classification section of the Microsoft 365 compliance center. You can check there to see if the policy applies retention labels to recordings. Figure 3 shows the information captured for an auto-labelling action as viewed through the Activity Explorer.

The Office 365 audit log captures the same data for auto-labeling actions. You can search using the Audit log feature in the compliance center or by running the Search-UnifiedAuditLog cmdlet to look for TagApplied events. Here’s an example of the data available in an audit record:

Search-UnifiedAuditLog -StartDate 11-Jun-2021 -EndDate 12-Jun-2021 -Formatted -ResultSize 5000 -Operations TagApplied

RecordType   : SharePointFileOperation
CreationDate : 11/06/2021 15:39:17
UserIds      : 6909d419-3589-4d38-85e3-d65e8c9aa408
Operations   : TagApplied
AuditData    : {
                 "CreationTime": "2021-06-11T15:39:17",
                 "Id": "63ee2402-1400-42bf-89e8-08d92cef12fc",
                 "Operation": "TagApplied",
                 "OrganizationId": "b662313f-14fc-43a2-9a7a-d2e27f4f3478",
                 "RecordType": "SharePointFileOperation",
                 "UserKey": "6909d419-3589-4d38-85e3-d65e8c9aa408",
                 "UserType": "CustomPolicy",
                 "Version": 1,
                 "Workload": "OneDrive",
                 "ClientIP": "",
                 "ObjectId":
               "https://office365itpros-my.sharepoint.com/personal/tony_redmond_office365itpros_com/Documents/Recordings/Transcription for All-20210609_131449-Meeting Recording.mp4",
                 "DestinationFileName": "Meeting with Ivan-20210609_131449-Meeting Recording.mp4",
                 "DestinationLabel": "Teams Recordings",

A more extensive discussion about how to use audit log events to track the progress of auto-labeling is in this post. You can also use audit events to know when new Teams meeting recordings are created in OneDrive for Business or SharePoint Online.

If you don’t have the licenses needed to use an auto-label policy to manage Teams meeting recordings, you can at least find out when recordings are created and use that information as the basis to remove the recordings manually or programmatically.

To Keep or to Remove?

It’s hard to recommend a suitable retention period for Teams meeting recordings. The pressure which existed previously due to the limited storage quotas imposed by Stream doesn’t apply anymore, so you could keep all recordings if you wanted. But given that most recordings are not very useful after a month or so, the right thing to do is to remove them. That is, if you have the licenses for auto-label policies!

Learn more about how Office 365 really works on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s really important across the Office 365 ecosystem.

Many Recent Changes

Information Protection and Governance is an area Microsoft has invested in heavily for the past few years. Many new features constantly appear, such as native support for sensitivity labels in the Microsoft 365 apps for enterprise, trainable classifiers, auto-labelling policies for sensitivity labels, and so on. Amongst all the change, one constant is that tenant administrators are often unsure about the licensing requirements demanded to protection data. Let’s try and figure out what the situation is.

The Split Between Manual and Automatic Processing

The first thing about information protection and governance features is that Microsoft makes a clear distinction between manual and automatic processing. When a user takes an action to do something, it’s manual processing and the required license is usually included in Office 365 E3. For information protection features, Microsoft enforced the differentiation in 2019 with the introduction of two Microsoft Information Protection service plans for Office 365. The standard plan is in Office 365 E3; the premium is in Office 365 E5.

The standard set of information protection and governance functionality in Office 365 E3 includes:

• Manual application of sensitivity labels to Office documents via Microsoft 365 apps for enterprise, Office Online (including OWA), and Office mobile.
• Manual application of sensitivity labels for container management to Teams, Groups, and Sites. Bizarrely, the person who applies the label (an administrator or group owner) must have an Azure AD Premium P1 license. The unfathomable logic is that the automatic inheritance of settings from the label to the underlying Azure AD group is advanced functionality.
• Manual Application of retention labels to documents and email.
• Basic Office 365 Message Encryption (OME). This includes the default Encrypt-Only and Do Not Forward templates to protect email.
• Data Loss Processing for Exchange Online and SharePoint Online (Teams is an outlier as its DLP policies require Office 365 E5).

Automatic processing usually means that some form of auto-apply policy is involved. For example, you can deploy auto-label policies to apply sensitivity labels or retention labels to documents and email. Office 365 E5 covers these policies along with Advanced OME and customer key for Office 365. Sometimes Microsoft’s definition of automatic is a little strained. For instance, if you define a default retention label for a SharePoint Online document library so that new documents created in the library receive the defined label, it’s automatic and therefore needs an E5 license.

However, for more advanced functionality like Bring Your Own Key (BYOK), Hold Your Own Key (HYOK), or double-key encryption (DKE), you’ll need a premium license like Microsoft 365 E5, Microsoft 365 E5 Compliance, and Microsoft 365 E5 Information Protection and Governance. These licenses also cover scenarios like using S/MIME with sensitivity labels, data classification in SharePoint Online, and using sensitivity labels with Power BI.

Tools to Help Understand Licensing

Given the number of features and plans available in this space, the issue of licensing can be quite complex. Microsoft publishes guidance to help tenant administrators and licensing coordinators understand when premium licenses are required to cover security and compliance features. A useful Microsoft 365 compliance comparison spreadsheet (Figure 1) is also available to show which license covers each feature. The spreadsheet also identifies gaps in terms of desirable features not covered by licenses held by a tenant.

Non-Enforcement is No Excuse

In some cases, a feature might not enforce the stated licensing requirement. This could be because the necessary code is not yet available. The code might or not appear soon. In any case, a tenant must have licenses to use functionality. It’s a bad place to be in if features the business depends on suddenly stop working because Microsoft updates its license enforcement code.

Slower and Buggy

I can’t find a notification that the Microsoft 365 compliance center was to receive a GUI makeover for content searches, but maybe I missed that memo. As it turns out, the notification is MC246002, but it dates back to March 23 and was overtaken by events. In my unaware state, I was surprised when a new user interface is now available in the tenants I have checked. The documentation is dated May 11, so I assume that’s when things changed. Curiously, the documentation refers to Office 365 Groups instead of Microsoft 365 Groups and insists on talking about the mailbox associated with a team (for channel messages). This perpetuates the nonsense that Teams uses Exchange Online to store data and ignores the storage of compliance records for personal and group chats in user mailboxes, but hey, it’s only documentation.

The old content search interface was around for several years and needed a refresh, and this release brings the interfaces for content searches and Core eDiscovery in line with that used for Advanced eDiscovery (which requires Office 365 E5). It also aligns the interface with Microsoft’s accessibility guidelines. The problem of refreshing anything is the potential of breaking things or making a feature work worse than before. Microsoft has succeeded splendidly in attaining both objectives. The new content search interface is both slow and buggy. Let’s hope it improves over time.

Fresh Interface

The good news is that the new interface is better looking and in line with the other sections of the Microsoft 365 compliance center. Microsoft has clearly paid attention to simplifying the creation of searches. For example, they’ve rationalized the set of locations into three types: Exchange mailboxes, SharePoint sites, and Exchange public folders (Figure 1). This is a good step because it avoids getting worried about differentiating between user, shared, and group mailboxes, compliance records for Yammer and Teams (and Planner in the future), OneDrive and SharePoint, and so on.

Also, content searches now automatically include “app content.” Although this checkbox says that it includes content for on-premises users, it means content stored in cloud-only mailboxes created by the Microsoft 365 substrate to hold messages sent by hybrid, guest, and federated users. This capability existed in the old interface, but a tenant had to ask Microsoft support to enable support for app content. It’s good that the option is now available to all.

Problems in the Location Pickers

Unfortunately, things start to go downhill from this point. First, the picker used to select Exchange mailboxes is very slow. Even on my small tenant, it takes ten seconds or more to find a mailbox. Also, note that the email address field is promised but not displayed (Figure 2). Seeing the email address is often helpful in distinguishing mailboxes with similar display names. On the upside, the picker allows selection of distribution lists and Microsoft 365 groups, which makes adding a bunch of mailboxes easier. You can also add inactive mailboxes to a search.

The picker also suffers a deselection problem. Take the example where you have selected several mailboxes, groups, and lists for a search and the decide that you want to start over. Figure 3 shows that a search has eight mailboxes selected, but details of the mailboxes are not shown to allow their removal. The only way I have found to deselect a mailbox is to search for it again and then remove the check against its name. This might be acceptable for one mailbox; it is tiresome when a search spans many mailboxes.

The SharePoint site picker still insists on URLs to find sites. It’s reasonably easy to find the URL for a site, but it would also be good if the picker allowed input of the site name. Bizarrely, if you go back to the site picker to update the list of selected sites, a list of the selected sites is available and it’s easy to uncheck a site (Figure 4).

Keywords and Conditions

After selecting target locations, the next step is to add the keywords and conditions for the search. There isn’t much change in the keyword list, but the way to select conditions has changed. In the past, each condition showed if it was common (applied to both Exchange and SharePoint) or specific to a workload. For instance, the Sent date condition applies only to email whereas the last modified condition is really a document condition (emails don’t change after sending). Now, there’s no assistance about what condition can be used with the different locations.

If you try to use a condition not supported by a selected workload, you’ll see an error (Figure 6). In this case, I selected the message kind condition which SharePoint doesn’t support.

Fine. Let’s remove the offending condition. The compliance center still wasn’t happy and generated an obscure, impenetrable error (Figure 7). The point here is that Microsoft has worked on content searches for over five years. It’s unacceptable when error messages fail to tell the end user exactly what they need to do to resolve the issue. As I worked through content searches over several days, I encountered more errors and problems than in the last year, and most of the errors were incomprehensible.

After going back to the search summary screen, even more gobbledygook erupted with diagnostic information that might make sense to a computer but means absolutely zilch to me. In this case, the search criteria (query) still includes the problematic message kind condition, but the error persisted even after removing the condition.

There was no way out except to abandon editing the search and start over. Eventually, I created an acceptable set of conditions and keywords and saved the search. The compliance center then launches an estimate search to create a sample set of results.

Samples and Previews

An estimate search is just that. It is a quick search to estimate what items a full search will find. To help the searcher figure out if their query works, the estimate returns a small sample of items matching the query. In the past, this was called a preview search.

When the estimate is complete, the summary screen for the search displays search statistics such as the number of matching items found and how many mailboxes and sites the search processed. Unlike previously, you now need to use an explicit option (Review sample) to see the items retrieved by the search.

Running the estimate search seems slower than before. This is a gut feel because I don’t have the two interfaces to test. However, I have run enough content searches over the year to know when something is not quite right. Retrieving the review sample items is also slow. Painfully slow at times. In addition, the preview screen (Figure 9) doesn’t tell you how many sample items are available.

Two problems surfaced here. First, scrolling through the list of preview items sometimes failed and I had to return to the search summary to start again. Second, the previous facility to choose to display 50, 100, or 200 preview items is gone. You can only see what search chooses to display,

Another irritation is that although Microsoft’s documentation says Word documents can be previewed, this version stubbornly refused to preview documents.

Impact on Core eDiscovery

Content searches underpin the Core eDiscovery functionality in the Microsoft 365 compliance center. The new interface now appears for Core eDiscovery. However, the ability to perform bulk operations has disappeared. This creates a big gap because a major difference between running individual content searches and an eDiscovery case is that the eDiscovery case can span multiple searches, each with their own locations and search criteria. In the past, eDiscovery managers have been able to combine the results from multiple searches into a single bulk export. That option is no longer available.

Nice Interface, Shame About the Slowness and Bugs

The remainder of the content search lifecycle (exporting search results and reports) works largely as before and doesn’t need any commentary. But getting to the point where results can be exported now takes longer and the experience, although mitigated by a nice UI, is spoilt by slow and buggy code. I don’t know if any of the Microsoft engineers and testers who worked on the new content search UI have ever conducted a search in anger in the context of something like a fraud investigation. If they had, they might just have realized that what’s been given to customers has some real problems. And that’s sad.

I’m sure Microsoft will fix the problems in due course. Hopefully, that’s sooner rather than later. And it would nice if they tested the code first before releasing it to paying customers.

Update May 28: I’ve had a conversation with Microsoft about the issues noted above. Microsoft acknowledges that they have work to do to fix bugs and improve performance. We’ll track this activity in future.

We’re busily revising the Office 365 for IT Pros eBook to include details of the new UI for content searches. Subscribers will see this work in a monthly update coming soon.

The Looming End for the Security and Compliance Center

Updated 18 June 2023

A reader asked how to create a report of the membership of Microsoft 365 role groups. Although this sounds like a straightforward question, the answer is complex. Here’s why.

Originally, compliance functionality was workload-based. Exchange Online had its own features as did SharePoint Online. In 2016, Microsoft introduced the Office 365 Security and Compliance Center (SCC) to bring together functionality which applied across all workloads. Permissions for the SCC follow the Exchange Online Role-Based Access Control (RBAC) model. Users receive permissions to perform actions through membership of role groups. If your account is a member of the right role group, you can perform a compliance action, like running a content search or managing an eDiscovery case. If it’s not, you won’t see the options to perform those actions displayed in the SCC.

Here’s where the situation becomes complicated. We are in the middle of a transition from the SCC to the Microsoft 365 compliance center, which Microsoft launched in 2018. Three years and a lot of confusion later, an April 15 blog post warns that Microsoft will soon start to redirect users automatically from the SCC to the Microsoft 365 compliance center. Message center notification MC256030 posted on May 12 confirms that a new permissions management page in the Microsoft 365 compliance center will make role management easier (Microsoft 365 roadmap item 72239).

Update: The Microsoft 365 compliance center is now the Microsoft Purview compliance portal. I’ve also updated the PowerShell code in this post to use the Microsoft Graph PowerShell SDK.

New Permissions Management Page

The new permissions management page (Figure 1) allows management for both Azure AD roles and compliance center roles (more correctly, role groups). The differences between the two are:

• Azure AD roles allow performance of directory-related tasks. The full set of Azure AD roles is visible by running the Get-AzureADDirectoryRole cmdlet or through the Roles and administrators section of the Azure AD admin center. Azure AD roles support advanced role management functionality like Privileged Identity Management to assign roles to users for limited periods.
• Compliance center role groups allow performance of compliance tasks like eDiscovery. Each role group contains one or more roles, which is how accounts gain permission. The 43 compliance role groups (my tenant has 44 because I created a specific role group to handle certain processing) have no other function except to control access to different compliance features. The SCC was the previous location to manage these roles. To update the set of users who receive permissions through membership of a compliance role group, an account must be a global administrator or assigned the Role Management role (a role assigned only to the Organization Management role group).

The permission management page shows Azure AD roles used to performance compliance tasks. Currently, the page lists nine Azure AD roles like compliance administrator and compliance data administrator. Other Azure AD roles like Teams Administrator don’t appear because they are not associated with compliance management.

Reporting Who Holds Compliance Roles

Returning to the original question of how to generate a report about the holders of different compliance roles, the answer depends on if you want to report the membership of compliance role groups or Azure AD roles. Given that more functionality is governed by the latter type at present, the following code is a solution.

The steps to create the report are:

• Uses the Connect-IPPSSession cmdlet (in the Exchange Online management module) to connect to the Compliance endpoint. You’ll need to use a tenant administrator account or one holding the compliance Organization Management role.
• Fetches the list of known role groups.
• Parses the set of members for each role group by converting the odd values used to represent members FFO.extest.microsoft.com/Microsoft Exchange Hosted Organizations/office365itpros.onmicrosoft.com/cad05ccf-a359-4ac7-89e0-1e33bf37579e into mailbox display names (the last part of the name is the Azure AD object identifier for the account).
• Writes details out into a PowerShell list and displays the results using the Out-GridView cmdlet.

Here’s the code:

Connect-IPPSSession
[array]$RoleGroups = Get-RoleGroup
$Report = [System.Collections.Generic.List[Object]]::new()
ForEach ($RoleGroup in $RoleGroups) {
    $Members = $RoleGroup.Members
    $MemberNames = [System.Collections.Generic.List[Object]]::new()
    ForEach ($Member in $Members) {
       $MemberName = (Get-ExoMailbox -Identity $Member.SubString(($Member.IndexOf("onmicrosoft.com/")+16),36) -Erroraction SilentlyContinue).DisplayName 
       $MemberNames.Add($MemberName)
    }
    If ($RoleGroup.WhenChanged -eq "Wednesday 1 January 2020 00:00:00") {
       $RoleGroupChanged = "Never"
    } Else {
       $RoleGroupChanged = Get-Date($RoleGroup.WhenChanged) -format g }

    $MemberNames = $MemberNames -join ", "
    $ReportLine = [PSCustomObject][Ordered]@{  
       "Role Group"           = $RoleGroup.DisplayName 
       "Members"              = $MemberNames
       "Last Updated"         = $RoleGroupChanged   }
    $Report.Add($ReportLine) 
} #End ForEach $RoleGroup
$Report | Sort-Object "Role Group" | Out-GridView

Figure 2 shows what the report looks like. A simple Export-CSV command will write the details out to a CSV file if you want to manipulate the data in Excel.

The same approach works to create a report for the Azure AD roles. In this case, you use the Get-MgDirectoryRole cmdlet to find the set of roles and Get-MgDirectoryRoleMember cmdlet to process each role (here’s an example of using these cmdlets to report on Microsoft 365 admin accounts which aren’t protected by multi-factor authentication).

Connect-MgGraph -Scopes Directory.Read.All
[array]$RoleGroups = Get-MgDirectoryRole | Sort-Object DisplayName

$Report = [System.Collections.Generic.List[Object]]::new()
ForEach ($RoleGroup in $RoleGroups) {
  [array]$Members = Get-MgDirectoryRoleMember -DirectoryRoleId $RoleGroup.Id
  $MemberNames = $Members.additionalProperties.displayName -join (", ")
  $ReportLine = [PSCustomObject][Ordered]@{  
       "Role Group"          = $RoleGroup.DisplayName 
       "Members"             = $MemberNames
       "Description"         = $RoleGroup.Description  }
    $Report.Add($ReportLine) 
} #End ForEach $RoleGroup
$Report | Out-GridView

Simple questions often have complex answers. In this case, it’s a matter of deciding what kind of role holders you want to report. Once you know that, the PowerShell to generate the report is relatively straightforward.

Learn lots more about how different parts of Office 365 work by subscribing to the Office 365 for IT Pros eBook. We go where other writing teams don’t, and we keep our book refreshed with monthly updates.

Change in the World of eDiscovery

Message center notification MC255066 posted on 7 May covers some configuration changes Microsoft is making to Core eDiscovery and Advanced eDiscovery. After claiming that the changes will bring “performance, reliability and experience improvements” (surely the norm for all Microsoft announcements), the text goes on to note that “documented limits were previously not enforced.” The upshot is that eDiscovery might not work like it did once Microsoft enforces the changes on May 10.

Core eDiscovery and Advanced eDiscovery have different technical foundations. Core eDiscovery is a case-based wrapper around content searches and in-place holds. Each case can span multiple searches and holds, and exports from the searches can be combined into one set for investigators to review. Advanced eDiscovery, which requires Office 365 E5 or Microsoft 365 compliance licenses, has its own search, review, and analysis capabilities developed to handle high-end eDiscovery cases of the type found in large enterprises. These cases might involve millions of documents and email items.

Notable Changes

Microsoft has documented limits for content searches for several years. In a practical sense, the most notable changes cited by Microsoft are:

• Content search preview, which can retrieve up to 100 items per mailbox and display a total of 1,000 items from all mailboxes included in a search.
• Core eDiscovery no longer supports exports involving more than 100,000 mailboxes.
• The Advanced eDiscovery collection process now treats SharePoint Online sites as individual locations, so collection might be slower.

Few organizations need to search more than 100,000 mailboxes. Those who do likely use Advanced eDiscovery or a specialized third-party eDiscovery product. MC254890 (May 6) says that Advanced eDiscovery has “raised the maximum size of an export from an Advanced eDiscovery review set from 3 million documents or 100 GB (whichever is smaller) to 5 million documents or 500 GB (whichever is smaller).” Advanced eDiscovery uses multiple ZIP files to handle the export of such large amounts of data.

Advanced eDiscovery is not fast at building its collection of data under review today, so making it a little slower to process SharePoint Online sources is probably not a big issue.

The Meaning of Preview

Some think that a content search preview represents the results of a full search. This isn’t true. Search preview exists to allow investigators to assess the accuracy and effectiveness of search criteria by reviewing a representative sample of what the search might find. No investigator wants to find more information than necessary. A search which finds precisely the required information takes much less time to process than one which returns a bunch of unrelated (and unwanted) items. Being able to preview the items found by a search (Figure 1) gives investigators the chance to see what kind of items a full search will find, no more and no less. An export is preceded by a full search, and that’s when the true set of items found in the target locations is revealed.

All of which means that the limit of 100 items per mailbox is important. It could be that the 101^st item is critical for an investigator but doesn’t show up in a preview. Given the increasing amount of data stored in Exchange Online, SharePoint Online, and OneDrive for Business, it’s possible that the most important items are buried and will never appear in a preview. They will be found and included in an export.

More Attention Needed for Search Criteria

This doesn’t mean that the search criteria are flawed or that searching is ineffective. It does mean that investigators need to understand how to use content searches to accomplish their goals. Up to now, it seems like Microsoft didn’t always enforce the documented limits, so it’s possible that preview returned more items than it will after May 10. With that in mind, the real lesson here is that investigators need to pay more attention to search criteria to ensure that the best possible chance exists that important items will turn up in preview.

More Data Consumes Search Resources

Some might ask why Microsoft is making these changes? I think the answer is probably based on multiple influences, including:

• Organizations store more information in SharePoint Online and OneDrive Business. Microsoft is also moving applications like Stream and Whiteboard to use SharePoint Online and OneDrive for Business. The more data, the more resources are consumed by search.
• The 100 GB Exchange Online enterprise mailbox quota encourages users to keep more email.
• The Microsoft 365 substrate captures compliance records for Teams and Yammer and stores the records in Exchange Online user and group mailboxes to make these items indexed and discoverable. The growth of Teams usage over the last year to 145 million daily active users has an attendant growth in compliance record storage. Yammer only recently added support for compliance records, and it only happens for Yammer networks configured in Microsoft 365 mode, so it’s much less of a factor.

In a nutshell, more data than ever before needs to be searched. If you didn’t impose some limits, search would consume more and more resources, and that’s an unmanageable situation. Although I can’t prove it with hard data, content searches certainly seem to take longer to complete now than they once did. Perhaps the changes now being made will restore search performance to where it once was.

Confused about eDiscovery in Microsoft 365? The Office 365 for IT Pros eBook includes a complete chapter on the topic. Subscribe today to keep your knowledge updated as change happens.

Understand How People Use Sensitivity Labels to Protect Office Documents

If you enable support for sensitivity labels in SharePoint Online and OneDrive for Business (and you should), most of the previous frustrations that organizations have experienced in dealing with protected go away. Protected (encrypted) content can be indexed and found by eDiscovery, co-authoring is supported (with Office Online), and so on. And very importantly, Office 365 captures audit events when people apply, remove, or change sensitivity labels with Office documents.

Originally, only sensitivity label actions performed by the Office Online apps were captured. This is fine, but most user interactions with Office documents occur through the desktop apps. The gap in coverage is closing and the latest versions of the Microsoft 365 apps for enterprise (aka Office click to run) now create audit records when they apply or remove labels from documents. I’m using version 2012 – current channel preview (build 13350.20316) as the basis for this article, but I can see that audit records have been generated since mid-December.

Although the latter part of December is a period of low work activity, the number of events captured since compared against previous months confirms the view that desktop apps are used more heavily to generate documents, spreadsheets, and presentations. At least, in my tenant.

Separate Audit Events

Nice as it is to have the additional insight into the use of sensitivity labels, it’s regrettable that Microsoft did not use the same operation names when generating audit records for the desktop apps as they do for the online apps. The operation is the name of an auditable action.

It’s possible that the logic here is that the actions originate in two different sources and the different operations mean that administrators can conduct precise audit searches to find records for either the desktop or online apps – or both.

The new operations are:

• SensitivityLabelApplied: A sensitivity label is applied to an Office document. This operation is also used when capturing a record for the application of a label to a SharePoint site. The two can be distinguished by the record type, which will be either SensitivityLabeledFileAction (for Office) or SharePoint. Events are recorded when users apply sensitivity labels to Outlook messages, but not for messages protected by OME. OWA and Outlook mobile clients don’t currently generate audit events when users label messages.
• SensitivityLabeledFileOpened: An Office document with a sensitivity label is opened by a desktop app.
• SensitivityLabelRemoved: A sensitivity label is removed from an Office document.
• SensitivityLabeledFileRenamed: An Office document with a sensitivity label is renamed to become a new file. This event is also logged when a labelled file stored on a local device (not a copy synchronized by OneDrive) is edited.

As in many cases with Office 365 audit log records, the new events need to be parsed out before they’re useful. This is reasonably easy to do with PowerShell, albeit at the need to examine and interpret the payload content of each type of event.

Reporting Audit Events

Seeing is believing and it’s always easier to understand how things work when you have a practical example. I’ve written a script to grab all the events for sensitivity labels for the last three months and create a report. Each of the event types is unpacked and interpreted to make it clear what the event means. The output is a CSV file which can be analyzed in whatever way you wish. Or you can examine the output on-screen through the Out-GridView cmdlet (Figure 1).

The script is available in GitHub. You’ll need to connect to the Exchange Online management module and the security and compliance endpoint to run the cmdlets in the script. The compliance endpoint is used to fetch the list of sensitivity labels defined in the organization and create a hash table of GUIDs/identifiers (the keys) and label names (values). Some audit events contain label names but it’s more typical to only find a label identifier recorded, so lookups against the hash table translate identifiers into label names.

As you can see from the output, in my tenant most audit records are recorded when an Office desktop app opens a protected file:

Job complete. 370 Sensitivity Label audit records found for the last 90 days

Labels applied to SharePoint sites:  51
Labels applied to new documents:     45
Labels updated on documents:         5
Labeled files renamed:               29
Labeled files opened (desktop):      200
Labels removed from documents:       40
Mismatches detected:                 0
----------------------

Report file written to C:\temp\SensitivityLabelsAuditRecords.csv

In this case, no mismatches are noted between the label applied to a site (container management) and those assigned to documents stored in the site. My users might just be learning how to label documents properly!

We write tons of PowerShell scripts to check out how Office 365 really works and understand where any fault lines might be. Our GitHub repository is available to all. Even better, we explain how to use our scripts and other PowerShell commands to manage Office 365 in the Office 365 for IT Pros eBook.

Message center update MC228823 released on December 7 (Microsoft 365 roadmap item 68875) covers the topic of Microsoft 365 compliance capabilities for card content generated through apps in Teams messages. That title is a mouthful and deserves some investigation to understand exactly what Microsoft means.

Teams and Adaptive Cards

Apps integrated with Teams often use adaptive cards to interact with end users. For instance, if you use the incoming webhook connector to bring data from an external data source into Teams, the information is presented in a card. For example, you can grab information about new Microsoft 365 roadmap items and post them to a channel (Figure 1). The elements of the card are composed by the application and posted to Teams through the connector.

Interactive Cards

Some cards, like the example given above, are designed to inform people rather than being interactive. Other cards, like Polls in Teams meetings are interactive. Microsoft’s January 26 announcement on the same topic mention apps from ISVs like Survey Monkey, Fuze, and Medxnote, none of which I have used, but all likely to be interactive rather than simply informative.

Cards and Compliance Records

The point about Microsoft talking about compliance capabilities is that app cards contain data. And up to now, this data has not come within the scope of Microsoft 365 compliance functionality:

• Compliance records: Unlike user messages sent in Teams chats and channel conversations, the Microsoft 365 substrate did not capture compliance records for app cards.
• eDiscovery and content searches: Because compliance records for app cards didn’t exist, app cards did not show up in search results or advanced eDiscovery cases.
• eDiscovery holds and retention policies: Likewise, because compliance records rather than the source Teams content in Azure are the basis for Teams retention processing, including holds, the lack of compliance records meant that app cards were not subject to holds or retention policies.

The substrate now captures compliance records for app cards posted to chats and channel conversations, but only for cards generated after the release of the update. No retrospective lookback occurs for app cards created before this point. Like compliance records for other Teams messages, the app data are stored in user and group mailboxes and are indexed and available for compliance processing, like searches, holds, and retention policies. Communications Compliance policies also use compliance records for their checks.

The change is now rolling out to tenants and world-wide deployment is scheduled for completion in mid-February.

Audit Records for Cards

Microsoft has added a new audit event to the Office 365 audit log to capture interactions with app cards. Search for the PerformedCardAction event when using the Search-UnifiedAuditLog cmdlet or “Performed action on card” from the Audit search in the Compliance Center. Neither method tells you much more than someone did something with a card. The event doesn’t tell you what the card or app was or what the user did, so it’s not much use from an audit perspective, unless a narrative like “Performed action on “1612055241167”” is insightful.

If you want to find out who did what with a card, you should run a content search where the preview of found items might be more illuminating. Figure 2 shows how app cards of the same type in Figure 1 appear in the preview of found items.

Like other compliance records, the substrate captures app card data as mail messages. The transformation from app card to mail message doesn’t result in perfect facsimiles. Mail messages are certainly a good way to capture Teams messages (even if Microsoft has trimmed the set of properties captured in Teams compliance records). However, mail messages are less successful in capturing the complete form of adaptive cards. This is evident if you export search results and examine the individual messages.

The truth is that compliance records serve to capture sufficient information for compliance purposes, but don’t expect them to be exact replicas of the original data or provide the complete context of how people use the cards.

Approvals Not Captured

Some gaps remain in the Teams compliance story around apps. For example, you might assume that the Approvals app uses cards, but apparently it doesn’t. At least, the substrate ignores the creation and approval of requests made in the Approvals app and doesn’t create any compliance records. This might not seem important, but it’s a gap in the compliance story and it’s a way for people to communicate through Teams without any records of that interaction. Compliance administrators don’t like that sort of thing but given the rate of expansion of Teams and the number of apps now using the platform, some gaps are inevitable.

We pay a lot of attention to data governance and compliance topics in the Office 365 for IT Pros eBook. Apart from anything else, if you understand how Microsoft 365 manages compliance data for applications like Teams, you understand the applications better.

Sensitive Information Types for Use with DLP

Data Loss Prevention (DLP) isn’t the most exciting topic, but it’s an important way to protect sensitive information stored in Exchange Online, SharePoint Online, OneDrive for Business, and Teams. Office 365 E3 licenses are needed to use DLP policies. The exception is Teams, which for some bizarre reason requires Office 365 E5.

Matching Sensitive Data

The foundation for DLP is the ability to find sensitive information within items. Microsoft 365 does this by scanning items for matches against definitions of sensitive information types as items are added to workloads, mostly when new or changed information is indexed.

The definition for a sensitive information type is a pattern identified by a regular expression or function. For instance, credit card numbers are matched if a fourteen or sixteen digit number is found which complies with Luhn’s algorithm (also used to check other sensitive information types like Canadian Social Security numbers). Additional confidence during the matching process is gained by the presence of other evidence close to the matched term. For instance, the word “Visa” or “MasterCard” close to a number which passes Luhn’s test increases the percentage chance that the number is a credit card.

Organizations can create their own sensitive information types to match information specific to their business, like customer numbers or project identifiers. These definitions join the set of common sensitive information types defined by Microsoft for use in DLP policies.

New Sensitive Information Types

Office 365 notification MC230755 published on 18 December brings the news that Microsoft has added 49 new sensitive information types to its set, which now includes 201 definitions. The new sensitive information types are now rolling out.

The definitions of sensitive information types created by Microsoft are described online, including the pattern and keywords used in the matching process. You can also get a quick count of the current set by running the Get-DlpSensitiveInformationType cmdlet. In this case, we see the 201 standard Microsoft definitions and 3 added by the organization:

$Dlp = Get-DlpSensitiveInformationType
$Dlp | Group Publisher | Format-Table Name, Count

Name                              Count
----                              -----
Microsoft Corporation               201
Office 365 for IT Pros                3

Microsoft says that the new definitions “unbundle” European Union definitions for driver’s license, passport, and social security numbers. In other words, instead of using generic definitions for these types, country-specific definitions are available for individual European Union countries like Latvia, Hungary, and Luxembourg (Figure 1).

If you’ve been using the Euro definitions in DLP policies, Microsoft recommends that you consider upgrading to country-specific sensitive information types if available to increase the accuracy of matching.

We cover DLP in Chapter 22 of the Office 365 for IT Pros eBook. Subscribe now to stay up to date with changes across Office 365. Our monthly updates will surprise and delight you!

The Myth of Teams Data Stored in Exchange Online

Microsoft 365 Notification MC230096 posted on 16 December 2020 is titled Change to properties added to Teams chat messages saved in Exchange Online. It’s a bad and misleading title. Teams chat messages are never saved in Exchange Online, nor are messages for channel conversations. Teams compliance records are stored in Exchange Online but the actual Teams messages always remain in the Teams message store in Azure Cosmos DB. There’s a big difference between the two types of objects.

Unfortunately, some believe the myth that Teams compliance records are complete and perfect copies of chat messages. They’re not and several important pieces of information are missing from the items stored in Exchange Online, like reactions and voice memos. Some backup vendors seek to perpetuate the notion that copying the Exchange items creates a good backup for Teams, which isn’t true, unless you consider a total inability to restore the items into Teams a backup feature.

Old and Expensive Attributes Being Removed

Coming back to MC230096, the news is that Teams will no longer create fully-populated MAPI mail items in Exchange Online. Instead, the properties of the compliance records for Teams chat messages will be tailored to meet the needs of eDiscovery. In addition to eDiscovery, Teams creates compliance records in Exchange Online to make the data available for services like Microsoft Search and features like communications compliance policies. In October 2020, Microsoft moved the storage location of the compliance records to the non-IPM section of user and group mailboxes.

The change being made drops a bunch of Exchange attributes which are not used by eDiscovery, such as LegacyExchangeDN (a throwback to the x.500 roots of the Exchange directory store used to map Active Directory addresses back to the addresses used by Exchange 5.5). The change is being rolled out now and is due for completion by the end of January 2021 and compliance records after this point won’t populate the unnecessary attributes. The compliance records for old chat messages are unaffected.

No one would ever conduct an eDiscovery search looking for messages addressed to a legacy distinguished name or recipient type, SID, GUID, or the other properties being dropped from Teams compliance records. People do use display names (like Jane Doe) or SMTP addresses (like John.Smith@office365itpros.com): these attributes are being kept along with the other searchable properties.

Burning Up Service Resources

Microsoft says that they’re making the change because populating the records with the unwanted data consumes a lot of resources as Teams makes Graph calls against Azure AD to retrieve the information. Given the growth in Teams usage over the last year and the number of personal and group chats and the consequent number of compliance records created in Exchange Online, this is a good and logical change. There’s no point in consuming vast quantities of CPU cycles to fetch and process directory attributes that no one will ever use.

In fact, looking at the MAPI properties of a Teams compliance item (Figure 1), there’s probably some more rationalization which can be done to remove some more duplicated or unnecessary attributes.

Change Won’t Impact Many

Tenants are unlikely to notice the change as the processing to capture Teams compliance records occurs in the background. If an organization exports the compliance records to a third-party archiving or eDiscovery, some testing will be needed to ensure that the new record format doesn’t affect how that solution works..

Keep a close eye on what’s happening inside Teams and the other Office 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure you know about changes when you need to.

New Information Surfaces All the Time

It’s amazing what is available online. When refreshing Chapter 20 of the Office 365 for IT Pros eBook, I found an interesting Microsoft article from 2018 about how to investigate partially indexed Exchange Online items and what this means for content searches.

Why Some Exchange Online Items Aren’t Fully Indexed

Microsoft 365 indexes items as they are added to workloads like Exchange Online, SharePoint Online, and OneDrive for Business and the compliance records generated for Teams and Yammer. The indexes are the foundation for content searches and eDiscovery cases.

Microsoft 365 encounters problems when indexing a percentage of items in a tenant for reasons like an unsupported format, their size, or an error occurs during indexing. For instance, indexing can only process Excel attachments if they are under 4 MB (this page says that the first 4 MB is indexed but the remainder is not), while indexable attachments for other file types can be up to 150 MB. And some files, like graphic and audio files, have metadata (document or email properties such as subject, creation date, author, etc.) but no indexable content. In the fun fact category, the maximum body size of an item in the index is 67 million characters (including up to 250 attachments).

Items which the indexer cannot fully process are referred to as partially indexed (their metadata is indexed, but their content is partially or not indexed). Content search results report these as unindexed items. For example, the search in Figure 1 shows that 3,928 items were found in a search returning 1,462,570 items, or around 0.27%.

Even if their content can’t be indexed, content searches do return partially indexed items if matches occur against their metadata. You can export the partially indexed items found by a content search to perform further analysis to determine if they are of interest to an investigation. Sometimes human beings can make more sense of unindexed items than computers can.

Analyzing Partially Indexed Items with PowerShell

The article about investigating the number and type of partially indexed Exchange Online items in a tenant includes a PowerShell script (PartiallyIndexedItems.ps1), which performs a content search for all items in all Exchange Online mailboxes (including user, group, and shared mailboxes). The output of the script is some summary data about the number and size of mailbox items and the ratio of partially indexed items. As you can see, the script reported 0.27% of items in my tenant are partially indexed (also the data reported in Figure 1). In terms of file size, the ratio is higher at 2.51%, which implies that most of the items are attachments.

===== Partially indexed items =====
         Total          Ratio
Count    1,462,570      0.27%
Size(GB) 95.35          2.51%

The next step is to report the reasons why items are partially indexed and the file type of those items. The script generates output like this:

===== Reasons for partially indexed items =====
attachmentrms
     => 25
parserencrypted
    encoffmetro => 24
    pdf => 5
    xls => 4
    zip => 2
parsererror
    doc => 7
    docm => 1
    docx => 32
    encoffmetro => 8
    gzip => 37
    json => 1
    pdf => 168
    png => 2
    pptx => 11
    xml => 5
    zip => 1
retrieverrms
     => 1797

Generating More Readable Output

I amended the script to produce more readable data that also can be exported to a CSV file (see below). The error text used here is my explanation of what caused partial indexing. As you can see, most of the issues are caused by messages protected by Office 365 Message Encryption (OME) or sensitivity labels, graphic files, and zipped files.

FileType                           Count ErrorText
--------                           ----- ---------
                                    1797 Rights Management Encrypted Item
PNG graphic file                     966 Parser encountered unsupported format
Unknown/no format                    529 Parser encountered unknown format
GZIP file                            320 Parser encountered unsupported format
PDF file                             168 Parser encountered an error
Password protected PowerPoint PPTX    90 Parser encountered unsupported format
GZIP file                             37 Parser encountered an error
Bitmap graphic file                   34 Parser encountered unsupported format
Word (DOCX) document                  32 Parser encountered an error
                                      25 Rights Management Encrypted Attachment
Password protected PowerPoint PPTX    24 Parser couldn't decrypt item
PDF file                              20 Parser encountered malformed item
ZIP file                              17 Parser error on output size

You can download a copy of the modified script from GitHub.

SharePoint Online and OneDrive for Business also have partially indexed items but seem to be less prone to the problem than Exchange Online is. This is due to the higher volume of individual items flowing through email and the wide spectrum of attachments accompanying messages.

Understanding the data which exists inside an Office 365 tenant is obviously a good thing to do. The script throws some insight into the complexities of indexing for high volumes of items of different types and might explain why searches don’t always return what you might expect.

Decryption of Exported Documents

Office 365 notification MC225739 (3 November) reports that eDiscovery exports will support decryption for attachments in Exchange (Online). The pointer to the Microsoft 365 roadmap refers to item 68704, which says:

“eDiscovery managers will be able to collect and review content encrypted with Microsoft encryption technologies and attached as a local copy to an email in Exchange from the Advanced eDiscovery solution.”

I asked the engineering group if decryption for exports would also apply for Core eDiscovery (the type you get with Office 365 E3) and received an affirmative response.

Deployment begins soon and is due to be complete worldwide by early December.

Protected Messages and Their Attachments

Exchange Online decrypts protected messages (messages assigned a sensitivity label with encryption) when items found by a content search were exported. Decryption only happens when search results are exported to individual (MSG) files rather than to a PST. Up to now, any protected attachments (files assigned sensitivity labels with encryption) remained encrypted, which created a problem for investigators who needed to see the content, or when content needed to be reviewed before it was turned over as the result of a GDPR data subject request.

One solution is to assign an account super-user permission for rights management and have them use that permission to decrypt the documents. While effective, this is problematic because super-user permission allows access to any encrypted content in a tenant. It’s more convenient (and safer) to have Exchange use its permissions to decrypt both messages and attachments as search results are exported from mailboxes.

Edge and Exports

Although any browser supported by Office 365 can create and run content searches and eDiscovery cases, you must use the Edge browser to download and install the Microsoft 365 eDiscovery Export program. This tool is created with Microsoft’s ClickOnce technology, and is used to download the results of a search from Azure to local storage. A recent change to Edge means that you might have to configure your browser to enable support for ClickOnce.

To do this, open a tab in Edge and go to edge://flags/#edge-click-once. Make sure that ClickOnce support is enabled (Figure 1).

If ClickOnce is not enabled, you can download the Microsoft 365 eDiscovery Export tool, but it won’t run. It took me a couple of times before I figured out what was going on. I’m sure the penny will drop for you sooner.

Learn more about how content searches work and how to export the results found by the searches in the Office 365 for IT Pros eBook.

Windows 10 and Edge Deliver Signals for DLP Evaluation

Announced as Generally Available on November 10, Endpoint DLP is a Microsoft 365 offering which uses signals generated by actions performed on Windows 10 workstations to evaluate against DLP policies. Supported actions include copying files to removable media like a USB or to a network share, printing files, uploading to a cloud app, or copying data to the clipboard.

Microsoft leverages its control of Windows and Edge by avoiding the need to deploy additional agents to monitor activity on a workstation. The necessary code to detect actions and submit them for DLP evaluation is incorporated into Windows 10 (version 1809 or later) and recent versions of the Edge browser.

Edge is the preferred browser because it understands how to respect endpoint DLP policies, and you can block other browsers from accessing files protected by policies. For instance, you could block Chrome or Firefox from opening a Word document if a specific retention label is present.

Not an Office 365 Feature

Before you can use Endpoint DLP, you need Microsoft 365 E5 licenses or either the Microsoft 365 E5 information protection and governance or compliance add-ons. This is understandable given that Windows 10 is bundled in the Microsoft 365 suite. Being able to gather information from Windows is a big part of the Endpoint DLP value proposition and it’s important that users have access to builds of Windows which include the DLP code. Having a Microsoft 365 license makes it more likely that users will be current, and not run something like an old Windows 7 or Windows 8 device.

Workstations used by licensed accounts can be onboarded (enabled) through the Microsoft 365 compliance center to start the flow of signals for DLP evaluation, unless they are already enrolled for Windows Defender, in which case Endpoint DLP works without any further configuration.

Looking for Violations

Once a workstation is enabled, actions taken by the user are monitored for potential violations against policy using the same kind of conditions as used to monitor Office 365 activity. For example, attempts to upload documents containing credit card numbers can be detected and stopped. Supported file formats include Office documents, PDF, text, and source code.

Endpoint DLP settings for the organization can be adjusted in the Microsoft 365 compliance center (Figure 1) to reduce the amount of noise in signals by excluding certain folders like the recycle bin, temp folder, or folders used for non-work files. It’s also possible to allow uploads to specific cloud services without generating a violation. Policy thresholds can be set to generate alerts when a large number of similar events happen. For instance, a policy could alert administrators if someone prints more than twenty documents assigned the Confidential sensitivity label.

Checking Devices

When Endpoint DLP is available in a tenant, DLP policies can be created for a target location called Devices, just like choosing SharePoint or Exchange as policy locations. The normal approach is to separate device policies from those used with Office 365 workloads, but you can combine them. Device policies have separate settings for restrictions to enforce when conditions are met (Figure 2).

Signals to SIEM

Apart from being used by DLP, the signals generated by devices can be gathered and analyzed in a SIEM. An example using Azure Sentinel is described in this article.

Good for Some Organizations

Some organizations will like Endpoint DLP very much. Others will not be interested because of the cost of Microsoft 365 licenses, presence of non-Windows devices, or because they’ve invested in other solutions. In either case, this is an area that’s worth keeping an eye on because the signs are that Microsoft is taking advantage of its Information Protection, Office, and Windows assets to create a compelling unified DLP story.

For more independent information about Endpoint DLP, read this article by MVP Anders Onevinn.

For more information about DLP for Office 365 workloads (Exchange, SharePoint, OneDrive, and Teams), read chapter 22 of the Office 365 for IT Pros eBook.

Email Exfiltration Controls for Office 365 connectors

Updated: 18 June 2021

In May, I wrote two articles about how Office 365 tenants can restrict users autoforwarding email from their Exchange Online mailboxes. The first article covered OWA, the second more general restrictions. In the second article, I pointed out that Power Automate (aka Flow) cheerfully ignores any restrictions imposed by Exchange Online, thus giving those who want to transfer email outside the organization a handy way to accomplish their goal.

That was then and this is now. Microsoft has just introduced some additional capabilities to help tenants control “email exfiltration” through Office 365 connectors. The immediate use case is to stop Power Automate flows sending, forwarding, or replying to email. Exfiltration is an interesting word to choose, and one that will be unfamiliar even to native English speakers. One definition I found that seems to fit is that data exfiltration is any unauthorized movement of data. In this instance, we want to keep email inside Exchange Online so that it’s exposed to compliance and data governance tools, so the unauthorized movement of data is of messages to an external email address.

Exfiltration Headers

There’s nothing complicated in the new controls. Some well-understood and reliable mechanisms are deployed to detect and stop outbound email generated by Power Automate addressed to external recipients. What’s changed recently is that Power Automate now adds an SMTP x-header to messages to identify its traffic. For example, I created a flow to fire when a new item is added to a SharePoint list. The message sent has the following headers:

x-ms-mail-application: to identify that the message comes from Power Automate. For example, my flow generated the following header. The underlined identifier is important because it can be used to allow or block messages from specific flows.

Microsoft Power Automate; User-Agent: azure-logic-apps/1.0 (workflow d356b212a66640dab94fd13546ca88d8; version 08586039113867675952) microsoft-flow/1.0

x-ms-mail-operation-type: to identify whether the message is a send, forward, or reply. In this instance, SharePoint Online creates a new message, so the action noted is Send. The value can also be Forward. Either will work.

To find this information, I sent the message to an Outlook.com address and examined it with the Message Header Analyzer after it was delivered (Figure 1).

Implementing an Email Exfiltration Block in a Transport Rule

Anyone who has ever created an Exchange transport (mail flow) rule knows that all outbound mail passes through the transport service, which examines and applies the conditions set in rules. In this instance, the rule is very simple. Figure 2 shows all that’s needed for a complete block of all email sent to external recipients via Power Automate flows.

The rule is: If the recipient is external, check if the x-ms-mail-application header is present and contains the words “Power Automate.” If it does, block the message and send the user a reject notification.

The rule conditions and action are: If the recipient is external, check if the x-ms-mail-application header is present and contains the words “Power Automate.” If it does, block the message and send the user a reject notification.

You can compose some nice text to explain the problem to the user which Exchange Online will insert into the reject message (Figure 3).

Microsoft’s article explains how to add conditional processing and exceptions. You might want to allow some flows to run because they are needed to send email to invoke an external process, or you might want to allow flows from specific senders or addressed to specific recipient addresses because you’re happy that the email is necessary and doesn’t compromise the organization’s data governance policy.

Good Flow Controls

The email exfiltration control is simple and effective. It’s just strange that it’s taken Microsoft four years since the introduction of Flow in April 2016 to figure out that controls are needed over email generated by Power Automate. In their defense, the data governance landscape was very different in April 2016 and Office 365 did not have the same kind of compliance feature set that’s available now.

Communication Compliances Policies Depend on Compliance Records Captured by Microsoft 365 Substrate

In a change so good that it deserved two identical Office 365 notifications (MC218305 and MC218304). Microsoft revealed on July 11 that communications compliance policies now support hybrid deployments by monitoring Teams chat and channel messages sent by users with on-premises Exchange mailboxes.

Communication compliance policies replaced supervision policies in April 2020 as part of Microsoft’s Insider Risk solution. Background processes monitor user communications in email, Teams, and Skype for Business Online to detect potential violations of regulatory, legal, or business policies. To check Teams messages, the processes use the compliance records captured in user and group mailboxes.

Communications compliance policies required Office 365 E5 or Microsoft 365 E5 compliance licenses.

Cloud-Only Mailboxes or Shards

In hybrid deployments, the Microsoft 365 substrate creates special cloud-only mailboxes for users with on-premises mailboxes. These mailboxes, or “shards,” cannot be accessed by users or any administrative tools available to tenants. The substrate creates compliance records in the cloud-only mailboxes to capture details of messages sent by hybrid users.

Content from the mailboxes used for hybrid users are indexed and are discoverable by Office 365 content searches, but only if you ask Microsoft to enable “app content” searches. When this is done, an extra option appears in content search settings (Figure 1).

It’s also possible to create a content search which includes hybrid mailboxes by setting the AllowNotFoundExchangeLocationsEnabled parameter to $True for the New-ComplianceSearch cmdlet.

Why Few Extra Violations Might Be Detected

The change made to communications compliance policies extend their reach to process the messages held in the cloud-only mailboxes. As reported by the Exchange engineering group at Ignite 2019, hybrid deployments often move most of their mailboxes to Exchange Online to take advantage of the functionality available there. The mailboxes which remain on-premises are there for a specific reason which stops them being moved to Exchange Online.

The update might not detect many more violations because it’s likely that a copy of offending messages are already available in a tenant user’s mailbox or group mailbox. However, it increases the coverage by communications compliance policies by scanning conversations from the scenario when all the participants in personal or group chats are hybrid users.

Understanding the detail behind how compliance policies work inside Office 365 is key to constructing a solid data governance framework for a tenant. Learn more from the in-depth coverage in the Office 365 for IT Pros eBook.

Exploit Sensitivity Labels to Protect Confidential Material Stored in SharePoint Online

If you assign sensitivity labels to critical documents stored in SharePoint Online or OneDrive for Business, you probably don’t want users to share those documents with external parties. It’s possible to restrict sharing at the level of a SharePoint site or tenant to stop documents being shared externally, but that will stop all sharing. Being able to pinpoint and block specific documents is better, especially when someone has made a judgment that a document needs to be protected by a certain sensitivity label. Of course, if the sensitivity label invokes encryption, the recipient might not have the rights to access the content, but it’s better when the block is imposed by the service and the intended recipient doesn’t get a chance to inspect document metadata (title, etc.), which might reveal something of its content.

Last July, Microsoft introduced the initial support in DLP policies for sensitivity labels using checks against the managed property defined in the SharePoint Online schema used to hold the GUID of a sensitivity label. The property is called InformationProtectionLabelId and the check is performed against a document property in the form InformationProtectionLabelId:Guid. For example:

InformationProtectionLabelId:9ec4cb17-1374-4016-a356-25a7de5e411d

In an announcement posted on November 10, Microsoft confirmed full support for sensitivity labels in DLP policies. This means that instead of using a document property, you can specify that the content contains a sensitivity label in the same way as the policy can check for the presence of a sensitive data type (like a credit card number) or retention label.

Simple DLP Policy

A simple DLP policy illustrates the point. The policy needs one rule with two conditions and an action:

• Condition 1: Content contains a retention label, sensitive data type, or sensitivity label. Select sensitivity label and then select the sensitivity label to check (Figure 2).
• Condition 2: Content is shared with someone outside the organization.
• Action: Block access to people outside the organization.

You can decide to apply the policy to selected sites or all sites in the tenant. I elected to use all sites because it means that documents marked as Ultra Confidential cannot be shared externally from any site, including new sites added after the policy becomes active.

The Block in Effect

After the DLP policy is published to SharePoint Online, any attempt to share a document with the Ultra Confidential label will proceed as follows:

• User will be able to create and send a sharing link to an external recipient as normal.
• DLP will detect that a link has been generated and block sharing (no further external sharing is possible). The sharer will receive notification that sharing is blocked (Figure 3). At this point, the sharer should probably tell the external person that the sharing link won’t work because…
• If the external person tries to access the document, they’ll be informed that they can’t.

Using Auto-Label Policies To Find and Label Documents

Another way of approaching the problem is to use an auto-label policy to search for documents with a specific characteristic and apply a label to protect the document. This works well, providing that you’re willing to pay for Office 365 E5 licenses to use auto-labeling policies. The technique described above works with Office 365 E3.

Another point to remember is that the most important and critical information in a company often cannot be easily found by auto-labeling. Some human intervention is needed to decide just how confidential a document is and what the appropriate level of protection should be. And when someone applies a highly confidential label to a document, it’s nice that you can then stop external sharing with such a simple DLP policy.

DLP policies are covered in Chapter 22 of the Office 365 for IT Pros eBook. We cover sensitivity labels in Chapter 24. Lots of information to learn from!

Sensitivity Label Support for SharePoint Online and OneDrive for Business

Updated August 15, 2022

Every Microsoft Purview sensitivity label has a priority order to indicate its level of sensitivity. A sensitivity label mismatch occurs when users upload Office documents or PDFs with sensitivity labels to SharePoint Online sites that have lower priority labels. Mismatches also occur when users update Office documents or PDFs stored in SharePoint Online and change the sensitivity label assigned to the files with one that has a higher priority than the label assigned to the site.

Microsoft recently made support for sensitivity labels in SharePoint Online and OneDrive for Business generally available. This is an important step forward because it allows SharePoint to index content protected by encryption applied by sensitivity labels. The indexed content then becomes available to Data Loss Prevention policies, content searches, and so on.

The integration of sensitivity labels with SharePoint Online is optional and must be enabled for a tenant on an opt-in basis, Afterwards, users can apply, remove, or change sensitivity labels to documents using the SharePoint Online and OneDrive for Business browser interface or through the Office Online apps. Sensitivity labels can be applied by users or by assigning default labels in label publishing policies or as a default sensitivity label assigned to a document library.

Audit Events Captured

Events for these actions are captured by SharePoint Online and ingested along with other SharePoint events into the Office 365 audit log. These events are:

• SensitivityLabelApplied: A label is applied to a SharePoint site.
• FileSensitivityLabelApplied: An Office Online app applies a label to an Office document.
• FileSensitivityLabelChanged: An Office Online app changed a label (upgrade or downgrade).
• FileSensitivityLabelRemoved: An Office Online app removed a label from a file.
• DocumentSensitivityMismatchDetected: A mismatch is detected because the sensitivity label applied to a document is higher than the level of sensitivity applied to the site where the document is stored. For instance, the site is labeled “Confidential” and a user uploads a document assigned the “Super Confidential” label to the site.

Currently, no events are captured when users apply sensitivity labels through other interfaces like Outlook or OWA.

Sensitivity Label Mismatch Email Notifications

When a mismatch occurs, SharePoint Online captures an audit record, and sends an Incompatible sensitivity label detected email notification to the person who uploaded the document. The notification contains details of the document which caused the problem and the label assigned to the document and to the site (Figure 1). It’s up to the person who receives the notification to resolve the issue. Given that they uploaded the document, they should know its true sensitivity. If necessary, they can change the sensitivity label assigned to the document and upload it again.

Handling Confidential Material

Even if it leads to a sensitivity label mismatch, it’s entirely possible that it’s OK to store a highly sensitive document in a site labelled with a lower level of sensitivity. Labels created to protect highly sensitive content usually restrict rights to interact with documents to a limited set of users. It might be desirable to not allow some people with access to the site (like guest accounts) to access a document assigned with a highly sensitive label. However, this should be an exception. It’s good practice to only store documents in sites that are accessible to all members of the site unless good reasons exist to restrict access to some documents to a subset of site members. In these situations, it’s best to store the sensitive material in another site with restricted membership such as a site belonging to a private Teams channel.

Mastering the detail of what happens inside Office 365 is important for tenant administrators. Shouldn’t you subscribe to the Office 365 for IT Pros eBook?

Sometimes Web Content Isn’t True

Updated September 16, 2021

Always verify what you read in a blog before you accept it as fact. A myriad of reasons might make text unreliable. People make mistakes as they write, or in their understanding of a topic, or use different versions of software to what you have. The problem doesn’t exist only in independent blogs. Microsoft publications get things wrong too. A recent example in when they updated their guidance about what’s captured in Teams compliance records and can be used for eDiscovery.

It’s good when Microsoft does this because there’s a ton of misconception in the technical community about the purpose and usage of Teams compliance records. I have been told that it is possible to backup Teams by copying the compliance records in an Exchange Online backup, something that is complete and unadulterated rubbish. You can copy the compliance records, but you’ll never be able to restore those items into Teams. As explained below, Microsoft updated their page because it contained some errors (correct information is now online).

How the Microsoft 365 Substrate Captures Teams Compliance Records

In summary, here’s what happens. When someone posts a message to Teams, the Microsoft 365 substrate captures a copy of the message as an Exchange mail item. A Teams message is not a mail item, so some transformation occurs in the capture. For this reason, referring to this process as journaling is incorrect. Unlike email journaling, a perfect legally-defensible copy of the original item does not result.

The Microsoft 365 substrate writes Teams compliance records for personal chats into user mailboxes. Compliance records for channel messages go into group mailboxes. In both cases, the mail items are stored in the TeamsMessagesData folder in the non-IPM (system) part of the mailbox. This folder is hidden from clients. Originally, Teams stored its compliance records in a folder under the Conversation History folder. Teams changed the folder it uses in October 2020.

Storing records in Exchange Online mailboxes has been done since Teams first generated compliance records in 2017. The substrate captures compliance records for all Teams conversations, including those involving hybrid users whose mailboxes are on on-premises Exchange servers and guest users. Compliance records are also captured for federated chats with Skype consumer users. In these cases, special hidden mailboxes store the compliance records. I have heard these mailboxes referred to as phantom, shard, or cloud-based mailboxes.

Conversations in private channels are a special case. Private channels don’t have a group mailbox, so the substrate writes copies of these messages into the personal mailboxes of channel members and tags the items as belonging to a private channel.

Teams compliance records are also used for retention policy processing. The Exchange Managed Folder Assistant removes expired records from mailboxes according to policy. Those deletions are synchronized back to Teams, which then removes the real messages from its store.

Teams and eDiscovery

Because the compliance records are in Exchange Online mailboxes, they are indexed and discoverable by content searches. eDiscovery never operates against the “real” Teams message data, which remains in Azure Cosmos DB. All content searches use the indexes populated by Exchange Online, so the items returned by a content search (Figure 2) come whatever can be found in Exchange Online, including records for conversations involving hybrid, guest, and federated users.

When Teams compliance records are found by a content search, they can be exported as individual items or to a PST. Figure 3 shows an item found with a content search as viewed through Outlook. The compliance record contains important information like the title of the topic and the name of the team the item is posted to. Inline images, GIFs, links, and tables are also visible.

Everything seems good, if you understand and appreciate two facts: first, the compliance records stored in Exchange Online are copies and not real Teams data. Second, the transformation process to copy a Teams message into an Exchange mail item means that some Teams content does not end up in the searchable content.

Moving Content from Teams to Exchange Online

When the substrate copies a Teams message to create a mail item in Exchange Online, the following information is included:

• Links to any embedded emojis, stickers, inline images, and GIFs.
• Tables.
• Embedded deep links to other Teams messages.
• Sharing links to files in SharePoint Online document libraries.
• For channel messages, the subject of the message is recorded (if available) as is the name of a team a message is posted to. For personal chats, the names of the people involved in the conversation are captured.

However, problems occur with these elements of Teams messages:

• Reactions (for example, a like, heart, or smile) given to messages. In an eDiscovery context, reactions can be important signs that certain individuals have seen a conversation in the same way that changing the read status of an email from “unread” tells you that the message was opened.
• Recordings of audio messages.

Update April 2021: Teams compliance records omitted code snippets created in Teams messages in the past. Retesting shows that these elements are now captured as .DAT attachments for the compliance records. The .DAT attachments hold the HTML-formatted content for the code snippet. They can be opened and examined with a text editor.

In addition, compliance records captured for praise messages only include the text of the praise and not the graphics. Compliance messages for messages with quoted text include the text but not the formatting to mark the text as a quote.

An Insight into the Exchange Items

You can use the MFCMAPI utiliity to see what’s in the Teams compliance records captured as mail items in Exchange mailboxes. Examining a Teams compliance record with MFCMAPI very quickly tells you what the item does and does not contain. Mail items are collections of MAPI properties and the content of those properties constitute what clients display, what Office 365 indexes, and what’s discoverable by a content search.

Figure 4 shows an example of how to review the properties of a Teams compliance item. The PR_HTML property stores the HTML-formatted content of the item that clients like Outlook display. In this case, you can see the HTML code describing a “smile” sticker and pointer to a GIF (stored online in a Teams content delivery network).

Webinar Information

Teams webinar information such as the event information, speakers, and attendance report is captured in a set of Microsoft Lists in the meeting organizer’s OneDrive for Business account to make the data available for search and eDiscovery,

Some Teams Data is Invisible for Compliance

Good as the substrate is at capturing Teams messages, some Teams data remains invisible from a compliance perspective, including:

• Voice memos recorded with the Teams mobile client.
• Whiteboards used during Teams meetings (Teams recordings don’t capture whiteboard activity in the video feed and the whiteboard service is not indexed for eDiscovery).
• Teams meeting recording stored in Stream are not available for eDiscovery either. The spoken text in recordings stored in OneDrive for Business and SharePoint Online is captured for search but is not yet available for eDiscovery.

The point is that you shouldn’t assume that everything done in Teams is captured for compliance purposes.

Private Channels

Teams private channels pose another challenge for compliance administrators. The compliance records for conversations in these channels aren’t captured in group mailboxes. Instead, the substrate creates copies in the personal mailboxes of channel members. The messages for private channels and personal chats are mixed up. However, compliance records for private channel messages have different tags to the items for chats. See this post for more information.

In addition, the documents created in the SharePoint sites belonging to private channels won’t be included in content searches unless the URLs for the sites are added to the search locations.

Call and Meeting Records

Teams compliance records are captured for meetings and calls. These records (Call Detail Records or CDRs) note when the meeting or call happened, the participants, and when each participant joined and left the call. For instance, a call between two users might be captured like this:

Start Time (UTC): 5/20/2020 12:57:02 PM
End Time (UTC): 5/20/2020 1:27:36 PM
Duration: 00:30:34.1604437
[5/20/2020 12:57:02 PM (UTC)] vasil@michev.xxx joined.
[5/20/2020 1:27:36 PM (UTC)] vasil@xxx left.
[5/20/2020 12:57:02 PM (UTC)] Tony.Redmond@xxx  joined.
[5/20/2020 1:27:36 PM (UTC)] Tony.Redmond@xxx left.

Because compliance records are captured as mail items, the person who starts the call is noted as the sender (for meetings, it’s the person who schedules the meeting). The people who participate are captured as message recipients and the subject will be something like:

Call (Complete)/Thread Id: /Communication Id: 58365f07-e530-4b69-bef8-71dca438e65a/Vasil Michev (MVP) (Guest),Tony Redmond

The subject for a meeting looks like:

Meeting (ScheduledMeeting)/Thread Id: 19:meeting_NzI1ZTA3ODUtZDhiZC00MTRiLWE5NDEtNmRiMWFlMzI5MmZj@thread.v2/Communication Id: 0f03bcd9-f48b-4bdc-887f-a78f3087d772

When meetings or calls are with visitors, you’ll see them noted with addresses like:

teamsvisitor:13c3a4132a584b918b9c6528b6dabef9 <13c3a4132a584b918b9c6528b6dabef9>

And the transcript will look like this. All we can say is that four anonymous visitors joined a meeting hosted by a tenant user. There’s no way to resolve the addresses signed to visitors into their email addresses.

Start Time (UTC): 6/20/2020 3:54:56 PM
End Time (UTC): 6/20/2020 5:05:28 PM
Duration: 01:10:31.9773921
[6/20/2020 3:54:56 PM (UTC)] teamsvisitor:13c3a4132a584b918b9c6528b6dabef9 joined.
[6/20/2020 5:05:27 PM (UTC)] teamsvisitor:13c3a4132a584b918b9c6528b6dabef9 left.
[6/20/2020 4:02:46 PM (UTC)] teamsvisitor:748997de34a346149f3c72a8d3c6c50f joined.
[6/20/2020 4:36:21 PM (UTC)] teamsvisitor:748997de34a346149f3c72a8d3c6c50f left.
[6/20/2020 4:08:42 PM (UTC)] teamsvisitor:ba1c0907edae4a6791f9fdc17adb9fc1 joined.
[6/20/2020 5:05:28 PM (UTC)] teamsvisitor:ba1c0907edae4a6791f9fdc17adb9fc1 left.
[6/20/2020 4:21:17 PM (UTC)] teamsvisitor:d1cce625a5ee4a29911a7a954a89f1ee joined.
[6/20/2020 4:23:29 PM (UTC)] teamsvisitor:d1cce625a5ee4a29911a7a954a89f1ee left.
[6/20/2020 3:59:38 PM (UTC)] Tony.Redmond@xxx joined.
[6/20/2020 5:05:27 PM (UTC)] Tony.Redmond@ left.

Guest accounts or people authenticated with another Office 365 tenant have their email address noted.

Compliance records for meetings and calls are searched along with other items. If you want to refine a search to look specifically for records for meetings or calls, you can do this by searching for the MAPI item class used for these items (Figure 5).

• To search for all Teams items (messages, calls, and meetings), search using the message kind condition and look for MicrosoftTeams. Warning: Always add extra search parameters (like certain users or a date range) as looking for items based on the message kind will return every item of that kind. In the case of Teams, this could be millions of items.
• To search for Teams meeting records, use the keyword Itemclass:IPM.AppointmentSnapshot.SkypeTeams.Meeting. Again, make sure to add extra search parameters to restrict the number of items returned by the search.
• To search for Teams calls records, use the keyword Itemclass:IPM.AppointmentSnapshot.SkypeTeams.Call.
• To search for both, use the OR operator: Itemclass:IPM.AppointmentSnapshot.SkypeTeams.Meeting OR Itemclass:IPM.AppointmentSnapshot.SkypeTeams.Call

Remember that Teams compliance records, including call detail records, are stored in Exchange Online mailboxes, so always search Exchange Online locations rather than SharePoint Online when looking for Teams content.

The Problems of Assuming Web Text is Accurate

Coming back to the problems of web text that’s wrong. Microsoft published its article on April 15. The text prompted some online commentary about Teams compliance, all blissfully repeating the errors in Microsoft’s article. Here’s an especially egregious example from April 22, complete with erroneous text pasted in from Microsoft’s article. Microsoft updated its page on April 29 with accurate information. It will be interesting to see if those who repeated the incorrect text now recant.

The experience proves that you should always check and verify text found in the web before you trust and depend on it. Even this text!

Compliance is a complex area. If you need to know more about compliance, subscribe to the Office 365 for IT Pros eBook where you’ll find Microsoft 365 compliance explained in depth.

It’s Just Different in the Cloud

One of the interesting things about Office 365 is the way that the integrated nature of the suite forces people to rethink how they previously approached tasks. Take for instance the question that Exchange administrators have been asked to answer for years: “who sent that email”? A question that takes us to Exchange Send As audit records.

The Development of Exchange Mailbox Auditing

When Exchange 2010 SP1 first introduced mailbox auditing, Microsoft gave administrators the tools to answer the question. The audit reports were clunky (horrible), but you could get the job done in PowerShell by running the Search-MailboxAuditLog cmdlet to search the audit records gathered for delegate activity to find the SendAs events generated when someone used that permission to send a message for another mailbox. That is, if you had enabled auditing for the mailboxes.

It took Microsoft far too long to enable auditing for all mailboxes by default. This was announced for Exchange Online in mid-2018 and eventually enabled in early 2019. However, as explained in this post, if you have Office 365 E3 licenses, you still need to manually enable mailbox auditing for mailboxes assigned those licenses.

Searching for Exchange Send As Audit Records

To return to the famous question, tenants can use the Search-UnifiedAuditLog cmdlet to search the audit log for SendAs events and produce an answer. And that’s exactly what you see in many of the scripts offered as the basis for answering our question, including an earlier post of mine.

Adjustments Needed for Office 365

However neat such an answer is, time has moved on and the answers given previously are now wrong. Unlike Exchange on-premises, where all SendAs events are generated by delegates sending messages for another mailbox, Exchange Online processes messages sent by other workloads that can show up in audit searches and skew results unless adjustments are applied. Here are some things to consider:

• Audit records with S-1-5-18 captured in the UserId property record the generation of a welcome message for a new team.
• Audit records are generated when Teams sends a welcome message.
• Audit records are generated for the group mailbox when a member posts a message to a conversation in an Outlook group using OWA. Records are not generated when messages are posted with other clients or arrive from guest members.
• Audit records are generated for the group mailbox when someone updates a task in Planner.

A Script to Find SendAs Audit Records

With these caveats in mind, here’s a script to search for SendAs records and process SendAs audit records and identify those belonging to user/shared mailboxes and those belonging to group mailboxes. The former category is normally what people are concerned with because they’re looking for instances where someone sent a message from a mailbox rather than posting to an Outlook group or adding a comment with Planner. To help identify the two categories, we create a hash table of primary email addresses for mailboxes and groups and look that table up for each audit event.

# First populate the Recipients Hash Table with user mailboxes, group mailboxes, and shared mailboxes
CLS
Write-Host "Populating Recipients Table..."
$RecipientsTable = @{}
Try {
    $Recipients = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox, SharedMailbox}
Catch {
    Write-Host "Can't find recipients" ; break}
# Now Populate hash table with label data  
$Recipients.ForEach( {
       $RecipientsTable.Add([String]$_.PrimarySmtpAddress, $_.RecipientTypeDetails) } )
# And include group mailboxes
[array]$GroupMailboxes = Get-Mailbox -ResultSize Unlimited -GroupMailbox
$GroupMailboxes.ForEach( {
       $RecipientsTable.Add([String]$_.PrimarySmtpAddress, $_.RecipientTypeDetails) } )
Write-Host "Finding audit records for Send As operations..."
$Records = (Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date).AddDays(+1) -Operations "SendAs" -ResultSize 1000)
If ($Records.Count -eq 0) {
    Write-Host "No audit records for Send As found." }
Else {
    Write-Host "Processing" $Records.Count "Send As audit records..."
    $Report = [System.Collections.Generic.List[Object]]::new() # Create output file 
    # Scan each audit record to extract information
    ForEach ($Rec in $Records) {
      $AuditData = ConvertFrom-Json $Rec.Auditdata
      $MailboxType = $RecipientsTable.Item($AuditData.MailboxOwnerUPN) # Look up hash table
      If ($MailboxType -eq "GroupMailbox") {$Reason = "Group Mailbox Send"} Else {$Reason = "Delegate Send As"}
      If ($AuditData.UserId -eq "S-1-5-18") {$UserId = "Service Account"} Else {$UserId = $AuditData.UserId}
      $ReportLine = [PSCustomObject] @{
           TimeStamp   = Get-Date($AuditData.CreationTime) -format g
           SentBy      = $AuditData.MailboxOwnerUPN
           SentAs      = $AuditData.SendAsUserSmtp
           Subject     = $AuditData.Item.Subject
           User        = $AuditData.UserId
           Action      = $AuditData.Operation
           Reason      = $Reason
           UserType    = $AuditData.UserType
           LogonType   = $AuditData.LogonType
           ClientIP    = $AuditData.ClientIP
           MailboxType = $MailboxType
           ClientInfo  = $AuditData.ClientInfoString
           Status      = $AuditData.ResultStatus }        
      $Report.Add($ReportLine) }
}
$Report | ? {$_.MailboxType -eq "UserMailbox"} | Out-GridView
$Report |Export-Csv -NoTypeInformation -Path c:\temp\SendASAuditRecords.csv
Write-Host "Report File saved in" c:\temp\SendASAuditRecords.csv

Figure 1 shows an example of some audit records found for user and shared mailboxes as generated by the script. The complete set of processed records is written out to a CSV file where the data can be parsed and analyzed to your heart’s content.

The script is available for download in GitHub.

The Influence of the Substrate

The problem with taking on-premises solutions like scripts to the cloud is that the solutions often don’t accommodate the way applications work and integrate. The influence of the Office 365 substrate is felt across the entire suite and is growing, which is why it’s wise to keep an eye on how scripts work as Microsoft introduces new functionality.

Chapter 21 of the Office 365 for IT Pros eBook includes many examples of how to interrogate the audit log to retrieve useful information. It’s surprising just how much you can discover if you go looking.

Capturing Crucial Office 365 Audit Data Requires E5 Licenses

In January 2019, Microsoft announced that they were adding an event called MailItemsAccessed to the set of audited operations captured in the Office 365 audit log. Microsoft claimed that the new event would “capture details of when a message in a mailbox is opened by the mailbox owner, delegate (someone with read access to the mailbox) or using administrative access” leading to audit information delivering “comprehensive forensic coverage of mailbox accesses.”

Time moved on and in March 2019, Microsoft said that they had halted the deployment of MailItemsAccessed to Office 365 tenants. Software has a habit of hitting delays and it was speculated that the overhead involved in gathering a massive number of message access events would place a strain on Exchange Online.

All went quiet for a while, which prompted me to ask Microsoft in June what was happening. They provided an odd statement that faintly indicated that the MailItemsAccessed event might appear in Q3 (July to September).

Crucial Security or Compliance Audit Events

Q3 came and went without a trace of any message access being captured in the Office 365 audit log. But last month Microsoft released documentation for Advanced Audit in Microsoft 365 (now Purview Audit Premium) which makes it clear that MailItemsAccessed is now regarded as the first example of a “crucial” security or compliance-related audit event included in their advanced audit offering. Previously, Microsoft called these events “high-value.” In either case, Microsoft defines the event as “one that can help you investigate possible breaches or other forensic-related investigations.”

Update October 19: Microsoft has released three additional crucial events to handle email sends and searches of mailboxes and sites.

In a nutshell, if you want to see information about who accessed an item in a mailbox, you need to buy some Office 365 E5, Microsoft 365 E5 or Microsoft 365 E3 with Compliance licenses.

Some MailItemsAccessed records can be found in the Office 365 audit log for my tenant audit and viewed using the Search-UnifiedAuditLog cmdlet or the Audit log search (Figure 1). But all the records that have turned up so far (in about a month) are for “sync” activities for various folders like the Inbox. Sync records aren’t very exciting because all they record is the synchronization of a complete folder using a client like Outlook desktop. The really interesting data lie in bind records, which record access to individual messages.

It’s also interesting to learn that Exchange Online applies throttling for MailItemsAccessed events. If a mailbox generates more than 1,000 bind events in a 24-hour period, Exchange Online stops recording MailItemsAccessed events for bind operations for another 24 hours before resuming capture of these events. Microsoft says that less than 1% of mailboxes are subject to throttling.

You can download an example of how to extract and report MailItemsAccessed audit events from GitHub.

Audit Log Retention Policies

Apart from capturing crucial audit events, the advanced audit feature also allows tenants to configure audit log retention policies. These policies work much like mailbox retention policies. You define a retention policy for selected audit events with a set retention period and Office 365 removes those items after that period. A tenant supports up to 50 audit log retention policies.

This example runs the New-UnifiedAuditLogRetentionPolicy cmdlet to create an audit retention policy to remove any SearchQueryPerformed event executed by the background app@sharepoint process after three months instead of the twelve-month retention of audit events if the tenant has E5 licenses.

New-UnifiedAuditLogRetentionPolicy -Name "90-day Retention SearchQueryPerformed by app@sharepoint" -Description "Remove SearchQueryPerformed events from the app@sharepoint process after 90 days" -RecordTypes SharePoint -Operations SearchQueryPerformed -UserIds "app@sharepoint" -RetentionDuration ThreeMonths -Priority 8

You can only manage audit log retention policies with PowerShell using cmdlets accessible by connecting to the Compliance Center endpoint.

Purging the Office 365 Audit Log

You can choose to apply retention for any of the events captured in the Office 365 audit log and keep them for three, six, nine, or twelve months. That is, you can keep audit events for longer than 90 days for accounts with E5 licenses. Office 365 restricts E3 accounts to a 90-day retention period, which is also the period for which you can search audit events in the Compliance Center. Searches earlier than this point must be done with the Search-UnifiedAuditLog PowerShell cmdlet.

It’s a good idea for tenants who either want precise control over how long audit data is retained or want to clean up events that don’t add much value in terms of investigations. SharePoint is a notoriously “chatty” application when it comes to the capture of audit events, so I can see why tenants  might decide to keep important events like FileUploaded or FileAccessed for as long as possible while removing some of the chatter after 90 days.

Communication Woes

I don’t have any issue with Microsoft classifying the MailItemsAccessed event as crucial and demanding a premium for its capture into the audit log. Only some tenants will be interested in these events and they might well have E5 licenses already. I can also see the sense of not imposing a huge overhead on Office 365 to capture these events for E3 tenants. It’s just a pity that the communication around the introduction of MailItemsAccessed and its evolution to become a crucial audit event has been so fractured and incoherent. Microsoft can do better.

We track developments in Office 365 auditing, including the kind of events you can extract from the audit log, in a chapter in the Office 365 for IT Pros eBook. Knowing what goes on in a tenant is important and the audit log holds the answers to many mysteries.

An Unclear Announcement About Legal Holds for Teams

The wording of Microsoft’s February 2 announcement (MC202846) that legal hold is now supported for Teams private channels might have confused some. The announcement starts with “we have begun rolling out legal hold for Microsoft Teams,” which isn’t accurate. It has been possible to put the group mailboxes used by Teams on legal hold via PowerShell or by including group mailboxes in holds owned by eDiscovery cases for quite a while. For example, to set a group mailbox on litigation (everything is retained hold), you can run the command:

Set-Mailbox -Identity MyTeam -LitigationHoldEnabled $True -GroupMailbox

The real meaning of MC202846 is that holds are now supported to control the compliance records created for conversations in private channels. As noted in this article, private channels don’t have a group mailbox, so the same capture mechanism for compliance records used for regular channels doesn’t work.

Holding Teams Private Channel Conversations

When messages are posted to regular channels, the Microsoft 365 substrate captures copies of the messages and stores them in the Team Chat folder of the group mailbox belonging to the team. The lack of a group mailbox for private channels means that the substrate stores compliance records for Teams private channels in the mailboxes of all the members of the private channel, which is the same approach taken to capture records of 1:1 and group chats. Therefore, compliance records for a team are divided as follows:

• Messages posted to Teams regular channels. Stored in the Team Chat folder of the group mailbox belonging to the team.
• Messages posted to Teams private channels. Stored in the Team Chat folder of the mailboxes belonging to all private channel members.

Team Chat is a sub-folder of the Conversation History folder. “Team Chat” is the English language name. If you want to be sure that you’re accessing the right folder with PowerShell, check the folder type. For example, I often use a command like this to discover when the last compliance record was written to a mailbox:

Get-ExoMailboxFolderStatistics -Identity O365ITPros -FolderScope ConversationHistory -IncludeOldestAndNewestItems | ?{$_.FolderType -eq "TeamChat"} | Format-Table Name, ItemsInFolder, NewestItemReceivedDate   
                                       
Name      ItemsInFolder NewestItemReceivedDate
----      ------------- ----------------------
Team Chat          2469 4 Feb 2020 16:03:05

Teams Compliance Records Are Copies

Despite the efforts of some backup vendors, aided and abetted by a lack of understanding about Teams compliance records, it is untrue that messages stored in Exchange mailboxes are real Teams message data that are a good backup source. The Teams message store is in Azure CosmosDB, and the mailbox items are incomplete copies created as Outlook mail items. The upside is that because the compliance records exist in Exchange mailboxes, they are indexed and therefore discoverable by Office 365 content searches, available for retention processing, and suitable targets for holds.

Distinguishing Teams Private Channel Messages

The problem with storing copies of private channel messages alongside copies of personal data is how data governance processing can distinguish the items. After all, you probably don’t want the retention policy set for personal chats to apply to private channel messages. To solve the problem, compliance records for private channels are marked with a different source, allowing components like the Managed Folder Assistant to ignore private channel data when processing retention policies.

Code in the Managed Folder Assistant also handles ELC (Electronic Lifecycle) processing, a fancy name for checking if items must be retained because they come within the scope of a hold. ELC checks items before they are removed from a mailbox and keeps a copy if required by a retention policy or hold. Microsoft has updated the hold logic to allow processing of private channel items, which then means that private channel items now support holds.

Clients can’t get at the Team Chat folder to view or remove items (as seen in Figure 1, you can use MFCMAPI to look at the items), so all compliance records for private channels created since their introduction are still in group mailboxes. In effect, a hold existed for these items. After the update rolls out, holds placed on the mailboxes of members of a private channel will include the messages posted to that channel.

Holding Private Channel Messages

Because all members of a private channel store copies, it’s enough to put the mailbox of a single member of a private channel on hold to impose the hold on the messages posted to that private channel. The obvious flaw in this strategy is that if the chosen member leaves the organization and their mailbox is deleted, the hold lapses. The workaround is to include the mailboxes of two, or three members in the hold, but what happens if all the chosen members leave?

It would be better if the addition of a group mailbox to a hold created implicit holds on all private channel content stored in member mailboxes, but that’s not the way things work. At least, not for now.

Compliance is such an interesting topic! Seriously, when you need to understand Office 365 data governance, consider leveraging the wealth of experience in the Office 365 for IT Pros eBook.

Old Security and Compliance Center Split in Two

Office 365 Notification MC202599 posted on January 30 tells tenants that the Microsoft 365 compliance center and Microsoft 365 security center portals are being rolled out in February 2020 with worldwide completion by early March. These portals were originally announced in April 2018 and have been significantly upgraded since (see this post for a discussion of some shortcomings that existed in the preview versions about a year ago). Tenants with Microsoft 365 subscriptions already have access.

The new portals will replace the Office 365 Security and Compliance Center (SCC) introduced in 2016. Microsoft is dividing the functionality found in the SCC across two portals to better reflect the work done in each. It’s a reasonable thing to do considering:

• The number of new features added in the security and compliance areas since 2016 (like sensitivity labels) and the expansion of functionality to handle extra workloads. The SCC was becoming a catch-call for anything remotely connected to security, compliance, or data governance.
• Although administrators might do everything in small tenants, in larger enterprises a division of work often exists and those who handle compliance issues tend not to be the same people who deal with tenant security.
• Many enterprises have upgraded their subscriptions from Office 365 to Microsoft 365. The new portals deliver a common interface for security and compliance work across all areas of Microsoft 365. At least, that’s the vision.

Not Quite Ready for a Total Switchover

The SCC will remain available at https://protection.office.com/homepage for some time to come because not all of the functionality available in it has been transferred to the new portals. It takes time to untangle everything and move code to the new locations, which is why the Microsoft 365 compliance center has a link to the SCC. At this point, the compliance center seems more complete and useful than the security center.

I don’t really have strong feelings about the change. To me, it’s more important that features work all the time, something that could never be said of the SCC in the past. While acknowledging the difficulty of slip-streaming functionality into a portal at a hectic rate, the sad lack of attention to detail was distressing at times. Recently, the SCC seems to have settled down, perhaps because the developers left it alone while they concentrated on the new portals.

Let’s hope that the quality of the new portals is better than the SCC and that Microsoft focuses effort into making sure that all the basic functionality works robustly instead of new and glitzy features like the compliance score. I consider it strange that 75% of a possible maximum score is gained by Microsoft managing controls as a cloud provider (Figure 2).

It’s also annoying that many of the rating used to increase the score could be automatically calculated and are not. For example, the improvement actions include advice such as “implement spam filter” (isn’t that what Exchange Online Protection is doing?) and “implement ATP safe links” (ditto) and “black legacy authentication (has Microsoft looked at the settings active in the tenant?). Oh well, things will improve over time. Won’t they?

The advent of the Microsoft 365 Security and Compliance portals brings joy to the hearts of book authors. We have to refresh all our content to make sure that we refer to the right option in the right portal when we describe functionality. Expect the switchover to happen in the Office 365 for IT Pros eBook over the next few monthly updates.

Office Depends on Unified Labeling Client

Office 365 Message Center Notification MC193997 (24 October) brings the news that OWA will soon be able to automatically apply Office 365 sensitivity labels to outbound email (Office 365 roadmap item 56649). Automatic application is based on the detection of sensitive data types in content. This feature requires accounts to have Office 365 E5 licenses and is being deployed to Targeted Release tenants with roll-out due to complete by the end of 2019.

Outlook and the other Office desktop applications can apply sensitivity labels automatically if the Azure Information Protection client is installed on a PC. Microsoft is now upgrading Office applications to support the same functionality and OWA is the first application to receive the capability. Microsoft announced the preview for support for sensitivity labels in the Office Online apps and SharePoint Online at the Microsoft Ignite 2019 conference.

Auto-Labeling on Send

OWA applies automatic labeling when messages are sent and uses the content of the message body to decide if the test for the sensitive data is satisfied. The other Office applications perform automatic labeling when files are saved.

The sensitive data types used to detect content for auto-labeling are the same as used elsewhere in Office 365 (for instance, by data loss prevention policies) and the same concepts of defining the number of occurrences of the data type that must exist in a file or message together with the confidence level that the data type is what it seems to be are used to define when a match exists.

Defining Labels for Automatic Protection

Figure 1 shows the properties of a sensitivity label with auto-labeling enabled. In this case, the label will be applied to any document or file where a client detects the existence of a single credit card number. Typically, you combine this feature with content marking to apply a header or footer to warn users that sensitive data is present and encryption (if desired) to protect the information. The message displayed to the user is free-form text to communicate to users when their items are automatically labelled. In this case a suitable message might be “Automatic protection applied because this message contains a credit card number.”

Priority Dictates Which Label to Apply

It is possible that several sensitivity labels invoke automatic labeling and match against content in an item. When this happens, Office 365 applies the label with the highest priority as ordered in the sensitivity label policy published to the user. The first label in a policy has the lowest priority while the last has the highest priority (most sensitive).

Need to know more about Office 365 Sensitivity Labels? Look no further than Chapter 24 of the Office 365 for IT Pros eBook. It’s packed full of information on this topic.

Record Your Thoughts in Teams Personal and Group Chats

The Teams mobile clients allow users to record a voice memo and send it to personal or group chats. It’s a nice feature available since March 2019 that is popular with users. To record a voice memo, hold down the microphone icon (Figure 1) and speak. Release the hold to stop the recording and then send it as you would a normal message.

This only works for personal and group chats. You can’t send voice memos to channel conversations. Although the Teams desktop and browser clients don’t support voice memos, you can play back voice memos on either client. Figure 2 shows how a voice memo appears in a chat in the browser client.

The Compliance Issue

After recording and sending a number of voice memos, I looked at the compliance records generated by Office 365. As these memos are part of personal chats, the compliance records are stored in the mailboxes of everyone participating in the chat. In the example I use, Office 365 creates compliance records in two mailboxes – the sender and the recipient.

The first problem is that Teams does not capture any metadata for voice memos (not even that the message is a voice memo). No attempt is made to use language recognition to interpret and capture the contents of the voice memo to make it searchable, like the way that Stream generates automatic captions for videos. In saying this, I note that Stream only currently generates automatic captions for English and Spanish language videos; the task of voice recognition and transcription for all the languages supported by Office 365 is immense.

In short, to all intents and purposes, the compliance records captured for voice memos are blank. Office 365 content searches can find the compliance records, but the emptiness of the compliance record will disappoint any compliance officer or investigator (Figure 3).

The second problem is that because Office 365 captures no metadata or other information for voice memos, the only way to find that these items exist is to look for everything in a mailbox. But even when you find something, the emptiness problem means that you know that someone communicated with someone else, but have no idea of what was said.

The reason that this is a compliance problem is evident from the conversation in Figure 1 where a participant is told that they’re going to receive some information in a voice memo. That information could be instructions to commit some form of behavior that is prohibited by law or the organization. We don’t know because no trace is left about what was said. Even MFCMAPI reveals nothing except perhaps a link to some data in the Teams Azure storage (Figure 4), and that’s just speculation on my part.

What Microsoft Needs to Do

Voice memos are valuable functionality and no one wants to see them disappear. However, compliance is terribly important for any company or business that must operate in line with legal or regulatory guidelines. To fix the problem, Microsoft needs to capture metadata for voice memos posted to chats, ideally with some information about the voice content to help investigators find these items and understand what they contain. Without the ability to search voice memos, a real gap exists in the Office 365 compliance story.

In the meantime, if you’re worried about the compliance issue for voice memos, you can update the Teams messaging policies used in the tenant to disable voice messages (Figure 5). It takes a little while for the new policy settings to get to clients, but when the policy arrives users won’t be able to send any more voice memos.

Compliance is a difficult subject to master, especially across multiple Office 365 workloads. That’s why we spend a lot of time looking into the nooks and crannies of compliance and documenting it here and in the Office 365 for IT Pros eBook.

Time to Phase out Exchange Online Retention Policies for Office 365 Retention Policies?

Exchange mailbox retention policies were introduced in Exchange 2010. They are still a popular method to control what users can keep in both on-premises and cloud mailboxes, but as time goes by, Office 365 tenants might consider moving to Office 365 retention policies to enforce a common retention framework across all workloads.

Because Exchange mailbox retention policies are designed to process email, they offer different functionality to the general-purpose Office 365 retention policies. By their very nature, compromises exist in any policy that applies across multiple Office 365 workloads like Exchange Online, SharePoint Online, and Teams. One such compromise is the inability of users to assign personal retention tags to items.

How Exchange Makes Personal Retention Tags Available

Personal retention tags allow users to define different retention behavior for items stored outside system folders (like the Inbox). For example, you might define a retention tag to keep items for ten years and make it available to users to assign to items that they don’t want removed from their mailbox. Personal retention tags are published to users through the mailbox retention policies assigned to their mailboxes. Users can also browse available personal retention tags through the Mail section of OWA options (Figure 1) and add tags that are not included in their policy which they would like to use. When they select a personal tag, Outlook adds it to the set defined in their assigned mailbox retention policy.

But I Don’t Want People Using Personal Retention Tags

Recently I heard some people questioning why users should be able to add personal tags through OWA options. The logic here is that the organization wants to exert complete control over the retention of mailbox items and don’t want users deciding to do anything different. You might decide to follow the same course if you’re preparing to switchover to Office 365 retention policies and don’t want to confuse people when they then can’t use personal tags.

Just like mailbox retention policies, Exchange 2010 introduced role-based access control (RBAC). Each mailbox is assigned a user role assignment policy to control what options are available to the mailbox. Many tweaks can be made to user role assignment policies to control features down to individual PowerShell cmdlet parameters (all Exchange management functionality is built on top of PowerShell), but in this case all we need to do is create a new user role assignment policy and remove the retention policy option.

Go to the Permissions section of the Exchange Admin Center (EAC), select User roles, and create a new policy. Give the policy a name and then check off the different user roles you want to include in the policy. Some of the roles (like MyTextMessaging) are antique memories of a long-past time and can be excluded without affecting user functionality. To remove the ability to select personal retention tags, uncheck the MyRetentionPolicies role (Figure 2) and save the new policy.

Assign the New User Role Assignment Policy

After making sure that the settings in the new policy are correct, you can assign it to mailboxes. Do this by selecting mailboxes in EAC and assigning the policy to them (Figure 3) or with PowerShell (below).

# Assign user role assignment policy to mailbox
Set-Mailbox -Identity "Oisin Johnston" -RoleAssignmentPolicy "Restricted Retention Tags"

After assignment, wait at least fifteen minutes for OWA to refresh its settings (or sign the user out and back into OWA) before checking that the retention policies option is unavailable in OWA settings.

A lot of Exchange Online mailbox management has its roots in the on-premises mechanisms. We cover this information in two chapters in the Office 365 for IT Pros eBook, suitably updated for the cloud of course…

Teams and Compliance Records

When people use Teams to communicate, Office 365 captures compliance records in Exchange Online mailboxes. Records for conversations in channels are captured in the group mailbox belonging to the team while records for personal and group chats are in the mailboxes of all chat participants. Teams supports the capture of compliance records for on-premises users in hybrid organizations and for guest accounts using special “phantom” mailboxes. Generally, the scheme works well and the compliance records are available for eDiscovery.

That is, unless your account has a frontline (Office 365 F1) license. In this case, your mailbox quota is 2 GB, which seems enough if it’s only going to be used for an occasional email. But Teams compliance records are charged against the mailbox quota and if the user is involved in many personal or group chats, their quota might be substantially eroded, especially if chat participants share graphics. One of our readers reported that they’ve seen instances where a quarter of the mailbox quota was absorbed by Teams compliance records.

Team Chat Folder

Teams compliance records are stored in the hidden Team Chat sub-folder under Conversation History. Because Team Chat is a system folder that isn’t available to users, you’d assume that its contents would not count against mailbox quota. And for most Office 365 accounts the fact that Team Chat is charged against mailbox quota isn’t an issue because of the standard 100 GB quota.

But the situation is different when a mailbox has a 2 GB quota. I say this in the knowledge that 2 GB is still a big amount. In 1996, original Exchange 4.0 mailboxes enjoyed quotas of between 20 MB and 50 MB. But things are different now. Messages are much larger, we keep everything, and Exchange Online stuffs all manner of data into user mailboxes. In this case, the net result is that a frontline user could find themselves running out of mailbox quota because of compliance records, which doesn’t seem like a good thing.

What You Can Do

Unless Microsoft changes the way they measure usage against mailbox quota, the only thing you can do is to periodically check the consumption of frontline mailboxes to ensure that none exhausts their quota. As usual, PowerShell comes in handy. Here’s a code snippet to process all user mailboxes and report the user, total items in mailbox, total size of mailbox, and the amount taken up by Teams compliance items.

# Find out what Teams compliance record are in user mailboxes
$Mbx = Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Select Alias, DisplayName, UserPrincipalname
$Report = @()
ForEach ($M in $Mbx) {
 # Retrieve message stats
   Write-Host "Processing" $M.DisplayName
   $MbxStatus = Get-MailboxStatistics -Identity $M.Alias | Select ItemCount, TotalItemSize
   $ConvHistory = Get-MailboxFolderStatistics -Identity $M.Alias -FolderScope ConversationHistory
   $ReportLine = [PSCustomObject]@{
           User          = $M.DisplayName
           UPN           = $M.UserPrincipalName
           MbxSize       = $MbxStatus.TotalItemSize
           MbxItems      = $MbxStatus.ItemCount
           TeamsItems    = $ConvHistory[1].ItemsInFolder
           TeamsSize     = $ConvHistory[1].FolderSize }
   $Report += $ReportLine }
$Report | Sort MbxItems -Desc | Export-CSV -NoTypeInformation c:\Temp\TeamsComplianceItems.csv

The output is a CSV file (Figure 1), as it’s usually easier to analyze this information in Excel.

To improve the script, you could:

• Only process mailboxes that have frontline licenses.
• Convert the mailbox size data returned by PowerShell into numeric values (to make it sortable).
• Add extra mailbox properties to the output.
• Allocate a higher license to any mailbox approaching their quota.
• Go wild with your imagination.

Of course, you could also deploy a Teams retention policy for frontline workers to remove items after a shorter period.

In the meantime, we’ve reported the issue to Microsoft and they are looking into the matter.

For more information about managing Teams, including Teams compliance records, read the Office 365 for IT Pros eBook.

Announced in January, Pulled in April, Back in September?

In April 2019, Microsoft rolled back the deployment of code to capture MailItemsAccessed events in the Office 365 audit log (and Exchange mailbox audit log, which feeds into the Office 365 log). At the time, Microsoft said that they planned to restart the rollout “soon,” but they haven’t given an update since.

I asked Microsoft for a status and received this:

“The M365 Auditing product group has an update on audit capabilities. Earlier this year, we announced that availability of Exchange [Online] MailItemsAccessed event was being rolled back. We are actively working on getting these events added into the audit logs and expect staged roll out to start in Q3 of this calendar year. Exact licensing requirements to access these events will be announced closer to roll out. In addition to this, we are working on enabling Longer term retention capability for audit events. Later in the year, we also plan to add more events and capabilities to our audit feature set. More details will be made available closer to release dates. Customers that want to evaluate these new events and features before subscribing will be able to do so with trial subscriptions. We are excited to get these capabilities in the hands of our customers and look forward to getting their feedback.”

Interpreting the Words of the Wise

Here’s what I took out of the statement:

• Microsoft expects to restart the roll-out in Q3. That could be next week, it could be at the end of September.
•  “Exact licensing requirements to access these events” is both interesting and worrying. The MailItemsAccessed event captures details of when an email is opened. I can’t imagine any scenario where Microsoft could justify licensing of the ingestion of these events into the Office 365 audit log and reporting (by the tenant) thereafter. ISVs will also be interested in using these events for their reports. But perhaps Microsoft has something interesting up their sleeves where they use these events for deeper analysis and understanding of how email is used within a tenant (like Workplace Analytics or MyAnalytics). If so, they might be able to justify an add-on license.
• I’m not sure why so much effort is needed to get the MailItemsAccessed events back into the Office 365 audit log unless a) the events are not being captured reliably or b) the storage of so many items (for 180 million active Office 365 users open a lot of messages daily) is proving to be a challenge. In either case, Microsoft isn’t saying.
• “More events and capabilities to our audit feature set.” Well, more data is welcome, if the audit events aren’t truncated or otherwise malformed when they get to the Office 365 audit log.
• “We are excited, etc.” Well, it’s July 4 next week, so I shall let that piece of motherhood and apple pie go by without comment.

In a nutshell, we’re working on getting MailItemsAccessed events back into the Office 365 audit log and it’ll be done by the end of Q3. Or something like that.

We await further developments.

Update October 23: Microsoft is bringing the MailItemsAccessed audit event back, but you’ll have to pay for a new Microsoft Audit 365 feature to get it. See Petri.com for more details.

Do you struggle to keep up-to-date with changing situations in Office 365? The Office 365 for IT Pros team specializes in tracking developments and then reporting what we find in the book You should have a copy!

Successful Experts Live (Norway) Event

The blog has been relatively quiet this week because I’ve been traveling to Germany and Norway to speak at the European Collaboration Summit (Wiesbaden) and Experts Live Norway (Oslo). I discussed if Teams will replace Email at ECS (you can grab a copy of the presentation here) before making a rapid departure for the airport.

Experts Live events are community run at either country or European level. In this case, Ståle Hansen, who writes Chapter 16 about Teams Meetings and Voice in the Office 365 for IT Pros eBook, asked me to come to Oslo to speak at the Norwegian event.

Experts Live Norway was very successful and a good example of how professional and interesting a national-level community event can be. The agenda included a good mixture of sessions covering topics like Azure, programming with the Graph API, Teams, and Office 365. Speakers were a mixture of Microsoft employees, MVPs, and subject matter experts. Most sessions were in English.

All About Office 365 Data Governance (in very little time)

I spoke about Office 365 Data Governance (you can download a PDF of the presentation below) and naturally didn’t manage to fit everything I wanted to say into the allotted time. Such is life. I’ve just got to try and stop telling stories and asking questions…

If, like me, you haven’t been to Oslo in a while, the city is very modern and vibrant. The number of electric cars is very noticeable with lots of Teslas and BMW i3s and an occasional Jaguar i-Pace. All in all, an enjoyable event.

Need help understanding Office 365 data governance and compliance technologies? Look no further than the Office 365 for IT Pros eBook, where we devote several chapters to unraveling these mysteries.

Sometimes You Want to Get Rid of Inactive Mailboxes

Updated 17 April 2023

Sometimes Microsoft doesn’t communicate changes made to PowerShell cmdlets that introduce interesting new functionality. There’s so much change in the service that they could be forgiven for an occasional slip-up, unless of course you need to use the specific feature that is undocumented.

New Parameters for Set-Mailbox

Which brings me to the well-known Set-Mailbox cmdlet, which boasts two parameters called ExcludeFromOrgHolds and ExcludeFromAllOrgHolds, a fact highlighted by MVP Vasil Michev in his ongoing crusade to discover what’s hidden in the corners of Office 365.

These parameters allow administrators to exclude some or all org-wide retention holds from inactive mailboxes. Remember that an inactive mailbox is one belonging to an Azure AD account that has been deleted but is kept because a hold exists on the mailbox. The hold can be any form of hold supported by Exchange Online, including litigation holds and those set by Office 365 retention policies. Retention holds come in two flavors, org-wide and non-org-wide (in other words, holds that apply to all mailboxes and those that apply to selected mailboxes).

Excluding an org-wide hold means that when Exchange evaluates whether to keep an inactive mailbox, it ignores that hold. If all org-wide holds are ignored, the inactive mailbox will only be kept if a specific non org-wide hold exists.

Controlling Org-Wide Holds on Inactive Mailboxes

Why do these parameters exist? Well, Microsoft introduced inactive mailboxes several years ago as a way for organizations to keep mailboxes around for compliance purposes without having to pay for Office 365 licenses. The most common use case is when mailboxes are kept for ex-employees. The idea is that a tenant will apply a hold to keep the mailboxes inactive for the desired period and then release the hold when the mailboxes are no longer needed.

Org-wide holds apply to both active and inactive mailboxes. Over time, it’s possible that a tenant will add new org-wide holds. The effect is that the set of inactive mailboxes is likely to grow because any mailbox that is deleted will become inactive because one or more org-wide holds exist.

Keeping inactive mailboxes is good if intended. It’s not so good if you don’t want or need those mailboxes. One of the principles of data governance in Office 365 is that tenants should be able to decide what data to keep and what to remove, and keeping inactive mailboxes longer than they should be goes against that principle. I imagine that Microsoft introduced these cmdlets to give tenants the ability to decide what org-wide holds should apply to inactive mailboxes.

Discovering Org-Wide Holds

Org-wide holds are registered in the Exchange Online organization configuration. To see the set, run the PowerShell command:

# Retrieve org-wide holds for the Exchange Online 
Get-OrganizationConfig | Select-Object -ExpandProperty InPlaceHolds

mbx15382841af9f497c83f9efe73e51888d:1
mbx9696959111f74ecda8a40aef97edd2c2:1
mbx703105e3b8804a1093bb5cb777638ea8:1
grp703105e3b8804a1093bb5cb777638ea8:1
mbxc1e2d6f1785d4bf8a7746a26e58e5f66:1
grpc1e2d6f1785d4bf8a7746a26e58e5f66:1
mbxf6a1654abdba4712a43c354e28a4d56c:2
grpf6a1654abdba4712a43c354e28a4d56c:2

The holds we’re interested in start with mbx. Those starting with grp apply to Office 365 Groups. The values following are GUIDs that point to the retention policies defining the holds. If you’re interested in understanding how to resolve the GUID to find the retention policy, see the Compliance chapter in the Office 365 for IT Pros eBook.

Excluding Org-Wide Holds from Inactive Mailboxes

To exclude specific org-wide holds from a mailbox, run the Set-Mailbox cmdlet and pass the GUIDs for the holds you want to exclude in a comma-separated list for the ExcludeFromOrgHolds parameter. Use the same format for the GUIDs as reported by Get-OrganizationConfig. When you run the command, Exchange updates the InPlaceHolds property for the mailbox to note the excluded holds.

# Exclude specific org-wide holds from a mailbox
Set-Mailbox -Identity Kim.Akers -ExcludeFromOrgHolds "mbx9696959111f74ecda8a40aef97edd2c2:1", "mbx19200b9af08442529be070dae2fd54d3:1" 

Microsoft recommends that you use the distinguished name or ExchangeGUID property to identify the mailbox. This is to be absolutely sure that a unique value is passed because if you exclude the holds for the wrong inactive mailboxes, you run the risk that Exchange will remove these mailboxes permanently when it evaluates the holds that exist on them.

To remove all org-wide holds from a mailbox, run Set-Mailbox and pass the ExcludeFromAllOrgHolds parameter. Because you’re now removing all org-wide holds, it’s even more important to be certain that you’re processing the right mailboxes.

#Exclude all org-wide holds from the target mailbox 
Set-Mailbox -Identity $Mbx.DistinguishedName -ExcludeFromAllOrgHold

The Effect of Exclusion

I wrote a script to exclude all org-wide holds from the inactive mailboxes in my tenant. Here’s the relevant code to retrieve org-wide holds from the Exchange Online configuration and exclude inactive mailboxes from the mailbox holds. Figure 1 shows the script running.

[array]$InPlaceHolds = Get-OrganizationConfig | Select-Object -ExpandProperty InPlaceHolds
$InPlaceHoldsMbx = $InPlaceHolds | Where-Object {$_ -like "*mbx*"}

[array]$InactiveMbx = Get-ExoMailbox -InactiveMailboxOnly -ResultSize Unlimited | Select-Object -ExpandProperty Alias 

ForEach ($Mbx in $InactiveMbx) {
   Write-Host ("Excluding inactive mailbox {0} from org-wide holds" -f $Mbx)
   $Status = Set-Mailbox -Identity $Mbx -ExcludeFromOrgHolds $InPlaceHoldsMbx }

Immediately Set-Mailbox processes a mailbox, Exchange evaluated the holds to decide whether to remove the mailbox. After the script finished, the number of inactive mailboxes reduced from 39 to 17. This proves that you need to be ultra-careful when you exclude any org-wide hold from an inactive mailbox.

For more information about managing Exchange Online mailboxes, read Chapter 6 in the Office 365 for IT Pros eBook to discover even more valuable tips and techniques.

Nasty Language Now Detected in Email and Teams

In March, I wrote about the update to Office 365 supervision policies to support monitoring of Teams communications in personal and channel conversations. Supervision policies are an Office 365 E5 feature and not every organization feels the need to check email and Teams to ensure compliance with company or industry regulations, but it’s an important part of data governance in some industries.

Recently, in another example of how Microsoft uses the cloud to bring machine learning and artificial intelligence into their products, supervision policies acquired the ability to use data models to check messages. The first data model is “Offensive Language,” which covers a wide range of conditions, including slurs, taunts, racism, homophobia, profanities, and taboo terms designed to help organizations implement anti-harassment and cyber-bulling in the workplace.

Adding the Offensive Language Data Model to a Supervision Policy

Adding the Offensive Language data model to a supervision policy is easy. When creating or editing a policy, you chose what communications to review, including the conditions to select messages. All you need to do is set the Use match data model condition checkbox (Figure 1).

Testing the Policy

After saving the policy, the next thing is to test its effectiveness. This is more easily done with email because Office 365 captures copies of messages for supervision immediately while it takes Teams up to 24 hours to do the same.

Messages selected for supervision are kept in special mailboxes and processed there by reviewers using OWA or the Supervision section of the Security and Compliance Center (Figure 2). Reviewers must decide if the messages picked up by a policy are compliant or non-compliant. Anyone who sends a message containing offensive language to other people needs some counseling. Ideally, the organization should have well-documented and clear procedures to report issues detected through supervision policies to line managers and HR for further action.

Blatant examples of grossly offensive language are picked up without a doubt (for instance, calling someone a f***ing idiot in email) as are messages containing specific keywords (like “homos”). Other messages get through that some might find offensive (you’ll have to do your own testing to find out), but might be caught in time as the learning model is refined to understand the kind of language used in the organization. At least, the great promise of artificial intelligence and machine learning is that administrators don’t have to keep on updating policies to take account of changing circumstances (new forms of insults, for instance). We shall see over time.

English Only

The current data model only handles English language terms. It will take time for Microsoft to build the models to handle offensive language in the many languages supported by Office 365, including regional variations used in the 240+ markets where Office 365 is sold. In the meantime, any local patois won’t be detected by policy, even if it is utterly offensive.

Along with a ton of other information about auditing, supervision policies are covered in Chapter 21 of the Office 365 for IT Pros eBook.

Office 365 Developers Take 237 Days to Fix Compliance Issue

In September 2018, I reported the failure of a PowerShell demo at the UK Evolve conference. The failure was not my fault (my code was, of course, immaculate). It was caused by a truncation of data in Office 365 audit records generated for group creation (the add group operation).

Bafflingly, the same code had worked perfectly during a similar demo at the European Collaboration Summit in late May. Something had changed inside Office 365 to cause the truncation. Checking the audit records in my tenant revealed that the change to the audit record structure happened between July 5 and July 11. And as it turned out, the truncation affected other group actions too, like adding a member to a group or deleting a group.

A Chat at Ignite

I reported the problem to Microsoft on September 12. Two weeks later, I met with some Exchange engineers at the Ignite conference in Orlando to review the problem. I’m not sure that Microsoft understood that a failure in audit records was a serious issue in terms of compliance, but I did my best to emphasize that it was unacceptable for audit records to be compromised. I went away from the meeting happy that the problem was understood and would be corrected.

Alas, the problem wasn’t quite as easily fixed as I anticipated. In fact, the fix only became available on May 7, some 237 days since the original problem report and 306 days since a code update introduced the issue to the Office 365 audit log. The fix also applies to the other group-associated events that were truncated before.

Holes Remain in the Office 365 Audit Log

Truncated records remain in the Office 365 audit log and will not be backfilled. This means that any group creation or update event stored in the audit log since early July 2018 is truncated. Office 365 E5 tenants have access to audit record for 365 days while the records for other tenants are cleared after 90 days. Untruncated events are available in Office 365 Cloud App Security or third-party products like Quadrotech’s Radar for Security and Audit that ingest audit data from Office 365 without going through the audit log.

Office 365 tenant administrators might not have been aware of the problem because Microsoft filtered the truncated events out from the set shown in Security and Compliance Center audit log searches. The only way to find the problematic events was with the Search-UnifiedAuditLog cmdlet. Hopefully, the fixed events will now reappear in the audit log search.

So So Slow

Since last September, I have been in contact with multiple people inside the Office 365 development group to try and advance the fix. It’s been a source of wonderment and frustration to me that Microsoft could leave an obvious gaping hole in an audit/compliance function for so long. It has not been their proudest hour.

In any case, the fix is in and truncation has stopped (at least for these records). We should be thankful for small mercies.

For more information about the Office 365 audit log and many practical examples of how to interrogate its contents, read Chapter 21 of the Office 365 for IT Pros eBook. We’ve been complaining about the truncation problem since last September because it affected one of the examples used in Chapter 21. All fixed in the next update.

Sometimes Office 365 is Infuriating

On March 19, I woke up to discover that all the retention labels assigned to documents in the SharePoint Online sites and OneDrive for Business accounts in my Office 365 tenant had disappeared. No trace of any label existed and you couldn’t assign a label to any document.

What was also weird was that the Security and Compliance Center reported “no data” when I went to look at the retention labels, a fact confirmed by PowerShell as the code below (to list retention labels) returned a big fat nothing.

Get-ComplianceTag | Format-Table Name, IsRecordLabel, HasRetentionAction, RetentionDuration, RetentionAction, Mode –AutoSize

Meltdown in the SCC

As it happened, the week when the problem happened was the annual MVP Summit in Redmond, so I was pretty busy. I pinged a couple of my Microsoft contacts and learned that the Security and Compliance Center was having some problems. So much so that engineers had to disable the ability to edit or delete objects. Later, I discovered that an incident (FO176096) was in progress as some Information Protection labels had gone missing. Now, retention labels could be called Information Protection labels, but they are more likely sensitivity labels (a surplus of labels is always a bad thing). In any case, something screwy was clearly going on.

The incident report promised that data would be restored, so I decided to wait. And wait, and wait… but the retention labels still haven’t turned up in SharePoint Online. On March 26, I thought that something was stirring when I noticed retention labels appear in one or two sites, but that was only the effect of auto-label policies, as confirmed by the Label Explorer in the SCC. You can confirm the same by looking at the Office 365 audit records created when retention labels are applied to documents (the system rather than a user applies the labels).

Return of the Labels

Retention labels first reappeared in the SCC on March 25, which meant that I could once again assign retention labels to SharePoint and OneDrive for Business documents, but the labels assigned to SharePoint documents beforehand remained invisible. Or missing. Or lost. Or in an unknown state. The retention labels were available and persistent in Exchange and Office 365 Groups.

As mentioned above, labels started to reappear in SharePoint due to auto-label policies on March 26. However, the retention labels assigned explicitly to documents did not come back until April 2, two full weeks after I reported the initial issue. Microsoft hasn’t shared a reason with me yet as to why the problem occurred or what they did to recover the labels. For all I know, the labels went into a black hole, stayed there for a while, and then ambled back out into the sunshine.

Problems for Microsoft

There’s a number of very bad things here. First, losing retention labels is a big no-no in terms of compliance. I do not know whether the temporary black-out has affected the retention period for these items. I also don’t know how many other Office 365 tenants were affected by the problem.

Second, although I learned about similar symptoms from other tenants, Microsoft never posted an incident notification in the Service Health Dashboard (SHD) of my tenant. Discovering a major loss of functionality through users is not the way things should work, especially considering all the telemetry Microsoft gathers about Office 365.

Third, the tardiness in restoring SharePoint back to full working condition is regrettable. You could say that I am not amused. It’s a sad example of a quality failure inside Office 365.

The Office 365 for IT Pros eBook can’t explain what SharePoint Online did with those pesky retention labels. But we can explain how retention labels should work, which is covered in Chapter 19.

New Consoles Turn Up in Office 365 Tenants

Previewed in January 2019, this week the new Microsoft 365 Security Center and Microsoft 365 Compliance Center have turned up in Office 365 tenants. The new consoles integrate different components from across the Microsoft 365 suite and will eventually replace the Office 365 Security and Compliance Center (SCC). Use https://compliance.microsoft.com to access the Microsoft 365 compliance center and https://security.microsoft.com for the Microsoft 365 security center, or click the Security and Compliance links now available in the Office 365 Admin Center.

Fit and Finish Needed

Although deemed generally available by Microsoft, the new consoles need some fit and finish to become fully functional. Many options in the Compliance Center take you back to the SCC. For example, you must use the SCC to create new supervision policies or manage sensitive information types. There’s no trace of the Office 365 audit log or content searches either. However, you can manage retention and sensitivity labels and create and apply policies for these labels in the new center (but not a retention policy that applies a default retention setting to one or more locations).

The new centers share the same design language as the Microsoft 365 Admin Center. Screen layouts are less bulky and clearer than in the SCC, so they’re a little easier on the eye. Some options (like Alerts and Classification) appear in both consoles. Monitoring and Reports is also a common option, but you see different data for compliance than you see for security.

Split Responsibilities

Apart from integrating other Microsoft 365 components alongside Office 365, dividing security and compliance into separate consoles allows Microsoft to have different access roles to control who can use the consoles. If you run a small tenant when the only administrative role used is a global administrator, the division in responsibilities won’t make any difference to you, but in larger tenants, being able to assign precise administrative responsibilities is a good thing. We therefore have roles like the Security Administrator and Compliance Administrator (see this page for details).

Impact on the Office 365 for IT Pros eBook

As noted above, Microsoft needs to do some work to bring the new consoles up to scratch so that they can phase out the Office 365 Security and Compliance Center. We hope that Microsoft fixes the problems that afflicted the SCC during this process, such as the many warning messages that something couldn’t be done because some ill-defined and unknown quota had been exceeded.

For the moment, the Office 365 for IT Pros writing team will continue to focus on the SCC and keep a watching brief on developments in the new consoles. Once everything is ready, we will switch our coverage to the Microsoft 365 consoles and update whatever is needed (screen shots etc.) across a range of chapters.

Being able to respond to changes like this as they’re rolled out by Microsoft is one of the charms of a eBook. The rate of change in Office 365 sure doesn’t make live easy for printed books.

Checking Communications for All Users in an Office 365 Tenant

Office 365 supervision policies allow tenants to monitor the communications of users in email and Teams. The usual situation is that a company needs to ensure that certain groups of users don’t infringe regulations in their communications inside or outside the company. Supervision policies allow this by capturing a set percentage of messages matching predefined criteria for reviewers to examine.

Typically, you use distribution lists to define the set of users whose communications are reviewed. The background assistants that examine email and Teams messages expand the distribution list membership to know what individual users to monitor. If a new member joins the distribution list, they are added to the supervision group. If they leave the list, they are removed.

You can’t use dynamic distribution groups for supervision policies because the overhead of continually evaluating the group membership would be too high. The question therefore arose of how to maintain a distribution list when you want a supervision policy to check the email sent by every user in a tenant.

PowerShell Server-Side Filtering

My solution is to build a relatively simple PowerShell script to scan for mailboxes that are not in a distribution list and add those mailboxes to the list. The list is then used by a supervision policy to monitor whatever traffic is needed, perhaps to make sure that no one in the tenant calls any other user something offensive in email (defining the list of offensive terms is an interesting exercise).

In any case, the basis of the script is that you use one of the fifteen custom attributes available for Exchange Online mailboxes to store an indicator to show if the mailbox has been added the distribution list. The reason for choosing a custom attribute is that the Get-Mailbox cmdlet supports server-side filtering against these attributes, so retrieving a set of mailboxes that aren’t on the list is faster than if you use a property that needs client-side filtering. Server-side filtering means that Exchange does the work before returning a set of objects while client-side filtering means that you fetch all objects from Exchange and then filter them on the client. As 15,000 mailboxes were involved in this case, server-side filtering is a big win.

Creating and Populating the Distribution List for the Supervision Policy

With the decision made about the technique to use, the code is simple. The first thing to do is to create a distribution list (later you might like to hide this DL from the Exchange address lists so that no one tries to use it for other purposes):

New-DistributionGroup -Name "Supervisory Review Mailboxes" -Alias SRReview -ManagedBy TRedmond -MemberDepartRestriction 'Closed' -MemberJoinRestriction 'Closed' 

Now we can create a set of mailboxes that are not marked and then add those mailboxes to the DL. We also update the attribute for each mailbox to indicate that the mailbox is now in the DL. Note that we are careful to have Get-Mailbox only find user mailboxes because only people generate communications for supervision policies to monitor. There’s no sense in processing room mailboxes, shared mailboxes, and the like.

$Mbx = (Get-Mailbox -RecipientTypeDetails UserMailbox -ResultSize Unlimited -Filter {CustomAttribute7 -eq $Null})
$i = 0
ForEach ($M in $Mbx) {
   Write-Host "Adding" $M.DisplayName
   Add-DistributionGroupMember -Identity SRReview -Member $M.DistinguishedName -ErrorAction SilentlyContinue
   Set-Mailbox -Identity $M.Alias -CustomAttribute7 SRAdded 
   $i++}
Write-Host $i "mailboxes added to Supervisory Review distribution list"

The first time the script runs, it will take some time to complete because it finds and processes all user mailboxes. Thereafter, if you run the script weekly to pick up new mailboxes, it will be much faster because the call to Get-Mailbox will find only the new mailboxes.

For more information about supervision policies, read Chapter 21 of the Office 365 for IT Pros ebook. We have many other PowerShell examples throughout the book too.

Hard Deletes for Office 365 Purges

As is often the case when you write for a moving target, I learned that Microsoft had upgraded the compliance search purge action to finally support hard deletes the day after we shipped the March 2019 update for Office 365 for IT Pros. The book is updated, but the topic is worth highlighting here.

Compliance Search Actions

Actions govern what happens when you run a content search. Normally, after creating a search, you execute an action to execute a preview search, followed by an export action when the search returns the set of items you need. Behind the scenes, the New-ComplianceSearch cmdlet sets up a search and the New-ComplianceSearchAction cmdlet associates an action with the search. The Start-ComplianceSearch cmdlet then starts the search.

Compliance Search Purge Actions for Exchange Online Only

The compliance search purge action is only supported for content searches executed against Exchange Online mailboxes. The Purge action is also only accessible to users who hold the Organization Management role for the compliance center. Up to recently, it was only possible to soft-delete mailbox items, which means that a user could recover the item. This is OK if you want to allow users to recover items deleted in error, but not if you want to permanently remove items like malware or messages sent in error. The Search-Mailbox cmdlet gets a lot of use in these scenarios because it is very good at removing mailbox items.

Microsoft didn’t say anything about upgrading the purge action to support hard deletes, and I only noticed the change when I looked at the documentation for New-ComplianceSearchAction for quite another reason. It’s nice how these unannounced changes pop up in the cloud, I guess.

In any case, if you use a hard delete purge action, Exchange Online moves the items into the Recoverable Items\Purges folder and marks them for permanent removal. The next time the Managed Folder Assistant processes the mailbox, it removes the items from the database and they are irrecoverable. While the items are in the Purges folder, they are invisible to the user.

Limited Purging

You can only create a purge action for a search with PowerShell. However, that’s not the big downside. Only ten items per mailbox can be purged in this manner. The limit is tied to the content search results, so if you wanted to remove 50 items from a mailbox, you’ll have to run five separate search and remove cycles to be sure that everything is found and deleted. By comparison, Search-Mailbox can process up to 10,000 items.

Microsoft is keen to emphasize that content search actions are not designed to perform mailbox clear-outs. Having a low limit per mailbox restricts the potential impact of administrator mistakes in the search query. It also forces administrators to construct search queries that are narrow rather than broad. In other words, you should use a search query that precisely identifies the exact message you want to remove rather than a query that casts a wide net and finds lots of items, including some that you don’t want to remove.

Compliance search actions by definition depend on being able to find indexed items. Unindexed items cannot be purged.

Hard delete purging (permanent removal) can’t be effective when litigation holds or in-place holds exist on a mailbox. If you want to permanently expunge all details of items from mailboxes, make sure that you remove any holds from the mailbox before starting. Soft delete purging (which allows users to recover deleted items) accommodates holds.

Using a Compliance Search Purge Action

First, create a content search with PowerShell or through the Microsoft Purview Compliance portal (the easiest approach). Make sure that the search finds the items that you want to remove and limit it to Exchange Online mailboxes. Now add the purge action by running the New-ComplianceSearchAction cmdlet to add the purge action and set the purge type to HardDelete:

New-ComplianceSearchAction -Purge -PurgeType HardDelete -SearchName "Search for Documents"

Confirm
Are you sure you want to perform this action?
This operation will make message items meeting the criteria of the compliance search "ACDSearch" completely
inaccessible to users. There is no automatic method to undo the removal of these message items.
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y

Exchange Online notices that a purge action is specified and goes ahead to find the matching items using the query specified for the compliance search. It then purges the first 10 matching items found. The search should not take long (it’s only going to process 10 items), but you can check by running the Get-ComplianceSearchAction cmdlet. Note that the name of the action is formed by the search name, an underscore, and the name of the associated search. When the status is reported as Complete, the items are purged.

Get-ComplianceSearchAction -Identity "Search for documents_purge" | Format-Table Searchname, JobStartTime, JobProgress, Status

SearchName           JobStartTime         JobProgress Status
----------           ------------         ----------- ------
Search for Documents 15 Mar 2019 18:18:48         100 Completed

To check the effect of a purge, you can look at the folders in a user mailbox that you know held a message found by the search. Here we use the Get-ExoMailboxFolderStatistics cmdlet to retrieve the item count for the Purges folder. As items are purged, the item count in this folder should increase.

Get-ExoMailboxFolderStatistics -Identity Kim.Akers  -FolderScope RecoverableItems |?{$_.Name -eq "Purges"}| Format-Table Name, ItemsInFolder

Name      ItemsInFolder
----      -------------
Purges              701

We’ve published a script in our GitHub repository to show how to use a compliance search purge action to remove items from Exchange Online mailboxes. Hopefully, it will help you understand and implement the technique.

For more information about content searches, see Chapter 20 of the Office 365 for IT Pros eBook. The Search-Mailbox cmdlet is covered in Chapter 6.

Cloud App Security Alerts Join the Office 365 Audit Data

Office 365 keeps on changing. The recent announcement that Microsoft is surfacing Office 365 Cloud App Security alerts through extra interfaces is an example of a change that might be considered small, unless you work in the area of security and compliance.

One thing that attracted my attention is the fact that Office 365 Cloud App Security (bundled with E5 licenses) now sends its alerts to the Office 365 audit log. This makes sense because Office 365 alerts and alert policies are powered by the events captured in the audit log.

Analyzing Cloud App Security Audit Records

In any case, events in the audit log show up with RecordType SecurityComplianceAlerts. Like all events in the audit log, some work is needed to unpack and interpret the information stored in the AuditData property. I used some code from Chapter 21 of the Office 365 for IT Pros eBook to examine what useful material is included by running the Search-UnifiedAuditLog cmdlet to retrieve the records.

Office 365 audit log records are normalized, but only to a point. Normalization means that a set of the same basic fields are included in all records, no matter what workload generates a record. The devil in the detail is that the contents of the AuditData property is open to interpretation and each workload can do its own thing in terms of what is output. And in the case of Cloud App Security, the contents of AuditData vary depending on an alert.

The upshot is that more work than should be necessary is needed to parse the data to make it useful for reporting and analysis. I only found two types of alerts generated by Cloud App Security, so that’s what the code below deals with. You might find others and need to update the code to handle whatever Microsoft decided to stuff into AuditData for the alert.

$Records = (Search-UnifiedAuditLog -RecordType
SecurityComplianceAlerts -StartDate 1-Jan-2019 -EndDate 30-Jan-2019 -Formatted
-ResultSize 3000)
If ($Records.Count -eq 0) {
   Write-Host "No alert audit records found." }
Else {
   Write-Host "Processing" $Records.Count "audit records..."
$Report = @()
ForEach ($Rec in $Records) {
   $AuditData = ConvertFrom-Json $Rec.Auditdata
   $Data = ConvertFrom-Json $Auditdata.data
   If ($Rec.Operations -eq "AlertTriggered") {
      $ReportLine = [PSCustomObject]@{
           TimeStamp; = $Rec.CreationDate
           User        = $Data.f3u
           Action      = $Data.an
           Status      = $AuditData.ResultStatus
           Severity    = $AuditData.Severity
           Workload    = $AuditData.Source
           Operation   = $Rec.Operations
           Category    = $AuditData.Category }
      $Report += $ReportLine}
    Else {
      $ReportLine = [PSCustomObject]@{
           TimeStamp   = $Rec.CreationDate
           User        = $Data.eid
           Action      = $Data.lon
           Status      = $AuditData.ResultStatus
           Severity    = $AuditData.Severity
           Workload    = $AuditData.Source
           Operation   = $Rec.Operations
           Category    = $AuditData.Category }
        $Report += $ReportLine}
  }} 

$Report | Select Timestamp, Operation, User, Action
Processing 42 audit records...

TimeStamp            Operation            User          Action
---------            ---------            ----          ------
21 Jan 2019 16:58:00 AlertEntityGenerated Tony.Redmond@ eDiscoverySearchStartedOrExported
21 Jan 2019 16:58:00 AlertTriggered       Tony.Redmond@ eDiscovery search started or exported
2 Jan 2019 19:54:00  AlertTriggered       Tony.Redmond@ eDiscovery search started or exported
…

It’s worth pointing out that some of the alerts that flow into the audit log duplicate events already logged by a workload, which is certainly the case for the eDiscovery searches featured above.

Always Tracking New Developments

We’ll continue to track what happens as Microsoft releases the other updates mentioned in their post and update whatever we need to in the Office 365 for IT Pros eBook. Keeping up-to-date with developments inside Office 365 is what we do!

Helping Teams be Compliant

The annual LegalTech conference took place in New York City this week. It’s the highlight of the year if you are interested in compliance technology, and it’s the reason why Microsoft made a number of announcements relating to compliance features in Office 365. Among these was a post about updates for records management, which is how we get to Teams compliance records.

The text referenced a report commissioned by Microsoft from Cohasset Associates (a company specializing in records management) to examine how Exchange Online and the Office 365 Security and Compliance Center meet the requirements of rules such as SEC 17a-4 and FINRA Rule 4511 about the storage and management of electronic records. This is a big deal for Office 365 because if the service can’t meet regulatory requirements, companies subject to those requirements can’t use Office 365.

The report is worth reading (download it here). Because a third-party wrote it, Microsoft had to answer their questions about how Exchange Online and Office 365 work and what changes are coming in the future. Among the topics covered is how the Office 365 substrate captures compliance records for Teams channel and personal conversations, and it’s here that some interesting facts are highlighted.

Teams Compliance Records and Regulation

The report plainly lays substantial weight on the value of Teams compliance records in terms of Microsoft’s ability to satisfy different regulations. However, it also notes several times that Teams compliance record do not include user responses (for example, when someone “likes” a message) – a fact first revealed in Chapter 13 of Office 365 for IT Pros. One thing we didn’t note is that the GIFs and other graphics are represented in compliance records by links which might change over time. The report notes that Microsoft plans to capture responses in compliance records later this year (July 2019).

[November 12: Microsoft still hasn’t addressed the problem of capturing reactions in Teams compliance records. The problem is proving somewhat more difficult than they anticipated.]

Another topic discussed in the report is the way that Teams compliance records capture individual messages instead of the transcript format used to record conversations by Skype for Business. Although the complete conversation is captured, it is in the form of individual items that must be fitted together to reconstruct the flow of the conversation. Apparently, Microsoft is going to deliver a way to reform conversations from compliance records around the same time as they capture responses. This should also appear around July 2019.

[November 12: Office 365 Advanced eDiscovery is getting the ability to present Teams compliance records “in context,” which is similar to seeing a transcript. Printing off a transcript for an investigator is still not possible.]

Teams Compliance Records are for Compliance – Not Backup

Many people make the mistake that Teams compliance records are exact copies of the messages and graphics stored in the Teams Azure services. Of course, as obvious from the shortcomings noted in the Cohasset report, this is inaccurate. Which then makes it strange when backup companies claim that they support Teams because they can copy the compliance records from Exchange Online. They can certainly copy the compliance data, but can they restore conversations in a channel or personal chat? That’s the key question, and it’s not one that can be answered until Microsoft delivers a suitable API to stream data out of the Teams chats and graphics data stores in a form that can be backed up and restored.

Druva Cites Office 365 for IT Pros

Speaking of backups, the Office 365 for IT Pros team was delighted when W. Curtis Preston, Chief Technologist of backup vendor Druva, used text from Chapter 4 to support his contention that Office 365 tenants need backups. The purpose of the book is to lay out information about how Office 365 works so that tenant administrators can make better decisions. In the case of backups, we can only comment about the current state of backup technology and the capabilities available to process data from Office 365.

Old-Style Backups No Longer Viable

Four years ago, it was good enough to cover Exchange Online and SharePoint Online. Today it is not. The way that applications are more integrated than ever before and the inter-dependencies which exist between workloads mean that the old-style workload-specific thinking about backups is no longer viable. It’s also true that anything written about Office 365 before 2018 can be discarded when it comes to backups because of the new features introduced by Microsoft such as Files Restore for OneDrive for Business (and soon for SharePoint Online) and the change in work practice like the movement of communications from email to Teams. You absolutely need to understand what you can do to protect against threat using out of the box features before concluding that added protection is necessary.

The question of whether an Office 365 tenant should invest in third-party backup is a business decision that is highly influenced by industry focus, data sovereignty, applicable regulations, willingness to accept risk, and funding. In short, it’s down to the tenant to make the decision. All we can do in a book like Office 365 for IT Pros is set out questions that you should debate with backup vendors before making a decision to use backups. The decision usually comes down to risk versus cost. If you understand the risk of running without backups and know how to use the features built into Office 365 to mitigate your exposure, then you might be able to forego the extra cost and complexity of paying for a cloud backup service. It’s your call.

And to be fair to some backup vendors who don’t peddle FUD to convince customers that they need their products to resist horrible failures, I do see a willingness to discuss the issues and understand the current shortcomings. It’s good to talk.

For more about Teams compliance records, see Chapter 13 of the Office 365 for IT Pros eBook. And if you want to know about our views on backups for Office 365, that’s all explained in Chapter 4.

Exchange Online Makes It Easier to Identify Problematic Sessions

Anything that helps Office 365 tenant administrators to track attempted or actual hacks is a good thing. Microsoft’s January 4 post telling us that Exchange Online mailbox and admin audit records now include a session identifier is an example of a small but useful change. I don’t need to repeat the description of what the change is as that ground has been well covered by the original post and the many duplicates that invariably appear to repeat the information given by Microsoft. But what hasn’t been explained is how to use the session identifier in a practical sense. Let’s try here.

Office 365 Audit Log

The first thing to know is that Exchange mailbox auditing must be enabled for any records to be captured. Auditing is enabled by default for Exchange Online, but it’s always wise to check. The second thing is that a tenant must also enable the ingestion of records from workloads into the Office 365 audit log. This is a one-time action.

Once enabled, audit data from Exchange flows into the audit log. Records show up roughly 15 minutes after an event happens. The delay is because of the need to gather data and pass the records through the normalization process to transform Exchange data into Office 365 audit data before ingestion into the log.

Audit records remain in the audit log for 90 days (for accounts with Office 365 E3 licenses) or 365 days (for those with Office 365 E5 licenses). Once the retention period elapses, Office 365 removes the audit records from the log. If you want to keep audit data for longer, you need to invest in a third-party product such as Quadrotech’s Radar for Security and Audit.

Looking for Audit Records

You can use the Audit log search functionality in the Microsoft 365 Compliance Center to look for Exchange activity, and then examine details of the records. As shown below, the session identifier is among the properties revealed when you click the More information link when viewing an audit record.

Understanding AuditData

Many of the interesting properties captured in an Office 365 audit record, including the session identifier, are held in a JSON-formatted property called AuditData. It’s difficult to track all the actions that occur within a specific session using the SCC interface and the better approach is to use the Search-UnifiedAuditLog cmdlet to find relevant records and examine what they hold.

However, because the session identifier is tucked away within the AuditData property, we must convert the JSON data before we can look at the session identifier. The Search-UnifiedAuditLog cmdlet includes a SessionId parameter, but it has no relevance here as it does not filter records based on the Exchange session identifier.

Extracting and Reporting Audit Events

The process to start tracing the events belonging to a session are therefore:

1. Find the audit records for the relevant period and filter them to extract the events generated by Exchange.
2. Extract the information held in the AuditData property for each record.
3. Report what we find.

This PowerShell code is based on an example found in the reporting and auditing chapter in the Office 365 for IT Pros eBook. You’ll notice that some of the MailboxLogin records have no session identifiers. This is because these are PowerShell sessions that use basic authentication to connect rather than sessions generated by Exchange clients like OWA or Outlook. Only sessions that use modern authentication have their session identifiers recorded.

[array]$Records = (Search-UnifiedAuditLog -StartDate 4-Jan-2019 -EndDate 5-Jan-2019 -ResultSize 1000 | ? {$_.RecordType -like "*Exchange*"})
If ($Records.Count -eq 0) {
   Write-Host "No Exchange audit records found." }
 Else {
   Write-Host "Processing" $Records.Count "Exchange audit records..."
   $Report = @()
   ForEach ($Rec in $Records) {
      $AuditData = ConvertFrom-Json $Rec.Auditdata
      $ReportLine = [PSCustomObject]@{
           TimeStamp   = $AuditData.CreationTime
           User        = $AuditData.UserId
           Action      = $AuditData.Operation
           Status      = $AuditData.ResultStatus
           SessionId   = $AuditData.SessionId
           Mailbox     = $AuditData.MailboxOwnerUPN }
      $Report += $ReportLine
  }}
$Report | Sort SessionId, TimeStamp | Format-Table Timestamp, User, Action, Status, SessionId -AutoSize

TimeStamp           User                                Action       Status    SessionId
---------           ----                                ------       ------    ---------
2019-01-04T09:18:02 Administrator@office365itpros.com   MailboxLogin Succeeded
2019-01-04T18:12:46 Administrator@office365itpros.com   MailboxLogin Succeeded
2019-01-04T18:39:51 Tony.Redmond@office365itpros.com    MailboxLogin Succeeded 1229a1b9-61fc-46f4-960a-84323c91cfc2
2019-01-04T18:49:48 Kim.Akers@office365itpros.com       MailboxLogin Succeeded 1f6d382a-a2d2-4875-a6d1-264120f4392e
2019-01-04T18:51:35 James.Ryan@office365itpros.com      MailboxLogin Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:51:55 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:33 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:33 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:34 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:35 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:54:47 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:22 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:22 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:37 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T19:00:15 James.Ryan@office365itpros.com      SendAs       Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T15:36:51 Tony.Redmond@office365itpros.com    MailboxLogin Succeeded 85808ea9-a43d-4221-9338-584c4717f740

Our code works, but it outputs events from all the Exchange sessions in the chosen period. We can improve things a tad by filtering out anything but the records belonging to the session we need to examine. It’s easy to do this by adding a prompt to allow the user to input a session identifier (if they’re smart, they will cut and paste this from a record displayed by the compliance center).

$Session = (Read-Host "What session id to look for")

And now we adjust the code to process the records so that we only output those for the chosen identifier.

If ($Records.Count -eq 0) {
   Write-Host "No Exchange audit records found." }
 Else {
   Write-Host "Processing" $Records.Count "Exchange audit records..."
   $Report = @()
   ForEach ($Rec in $Records) {
      $AuditData = ConvertFrom-Json $Rec.Auditdata
      If ($AuditData.SessionId -eq $Session) {
         $ReportLine = [PSCustomObject]@{
           TimeStamp   = $AuditData.CreationTime
           User        = $AuditData.UserId
           Action      = $AuditData.Operation
           Status      = $AuditData.ResultStatus
           SessionId   = $AuditData.SessionId
           Mailbox     = $AuditData.MailboxOwnerUPN }
        $Report += $ReportLine}
  }}

The output now includes only the records for the chosen session, sorted in time order:

TimeStamp           User                                Action       Status    SessionId
---------           ----                                ------       ------    ---------
2019-01-04T18:51:35 James.Ryan@office365itpros.com      MailboxLogin Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:51:55 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:33 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:33 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:34 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:52:35 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:54:47 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:22 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:22 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T18:57:37 James.Ryan@office365itpros.com      HardDelete   Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91
2019-01-04T19:00:15 James.Ryan@office365itpros.com      SendAs       Succeeded 7ea5da96-dbc6-4f86-8b1d-1f16b6278f91

It’s pretty clear from the audit log that someone logged into the James Ryan account performed a series of hard deletes (permanent removal of mailbox items) in quick succession followed by a mail send. Now we know what happened, we can look at the individual audit records to discover which items were removed from the mailbox. That takes a little more work, but it’s relatively easy because we have the relevant audit records that contain the information.

For more information about the Office 365 audit log and many practical examples of how to use it to generate reports about different tenant activities, see the reporting and auditing chapter in the Office 365 for IT Pros eBook.

Protect but Don’t Block

Office 365 tenants who use Rights Management with Azure Information Protection (and use a cloud key rather than their own key, or HYOK) can now include the special Any Authenticated Users in the permissions configured for protection templates. Previously, you could only define permissions for users within the same tenant or named individuals in other domains *(using their email addresses). Any Authenticated User is a special permission which grants a set of permissions defined in a template to any user who authenticates by signing into:

• An Azure Active Directory account. For example, anyone in another Office 365 tenant.
• A Microsoft Services (MSA) account. For example, anyone who uses Outlook.com.
• A directory service federated with Azure Active Directory (like Google) or where a one-time passcode is used to access protected content. These types of protection are usually involved when sending email to recipients of non-Microsoft email services.

The intention behind the Any Authenticated Users permission is to give tenants a method to encrypt information sent outside the organization so that it is protected in transit and at rest while still supporting granular permissions and access control (such as expiration and offline access). In effect, you’re not worried about who opens the content if they can authenticate, but you still want some control over what they can do with the content.

Like the permissions assigned to individuals or groups, you can grant specific permissions to Any Authenticated User. For instance, you can stop people who use the permission from copying or printing the content. You can also track and revoke access to the content at any time.

Any Authenticated Users and Sensitivity Labels

As you might know, Microsoft is currently in the process of unifying protection labels as defined in the Azure Information Protection portal with Office 365 labels. This doesn’t mean that we will have a single set of labels. Rather, Office 365 will have two sets, both of which are managed through the Classification section of the Security and Compliance Center:

• Sensitivity labels, which apply protection and are shared with Azure Information Protection.
• Retention, which define for how long Office 365 keeps information like documents and email.

The migration of labels from Azure Information Protection to Office 365 is still a work in progress. Here’s what I report in Petri.com on the topic.  You can add the Any Authenticated Users to a template in the Azure portal and it will be synchronized to the Security and Compliance Center. However, you can’t yet add the permission to a label through the Security and Compliance Center.

For more information about rights management, read Chapter 24 of the Office 365 for IT Pros eBook.

Increased from 90 Days

A note in the September 25 post about Microsoft 365 compliance says:

“long-term audit log availability is now coming to public preview for Microsoft 365 and Office 365 E5 subscribers. This is an important update for organizations that need long-term access to audit logs for regulatory or security purposes. The audit log availability has now increased from 90 days to one year.”

This means that Office 365 audit log data is kept for different periods for different users. If an account has an Office 365 E3 license, Office 365 keeps audit data for 90 days; if an account has an Office 365 E5 license, audit data retention is extended to 365 days (Cloud App Security Keeps audit data for 180 days for all Office 365  E3/E5 licensed users). Accounts with Office 365 E3 or Exchange Online Plan 1 licenses can also have audit records kept for 365 days if they buy the advanced compliance add-on license.

The increase in audit log retention is being rolled out gradually. Targeted release tenants will see extended retention “soon” while those who wait for features to be generally available will have to wait for the preview period to finish. In either case, Office 365 does not reach back into the past to reveal older audit records. Accounts licensed for extended retention will begin to accumulate audit records when the feature is enabled and gradually build from that point until the last 365 days is available for those accounts.

Why the Change?

Why is Microsoft making this change, and why only for the most expensive Office 365 plan? It could be that Microsoft has realized that retaining audit data for 90 days is simply not long enough for the kind of large and complex organizations who purchase E5 licenses. It could be that storage costs have come down to a point where it is economically possible for Microsoft to dedicate more storage to keep audit records for longer and that the 365-day period will soon be extended to all Office 365 users. Or it might just be yet another prompt to organizations that they should buy E5 licenses to gain extra security (among other functionality).

Years Better Than Days

But the fact is that you don’t need to upgrade all your users to have E5 licenses to get extended audit log storage. Third-party products like Quadrotech Radar for Security and Audit already offer longer retention periods for Office 365 audit data extracted from the same sources as the events ingested into the Office 365 audit log. Radar’s basic storage is for three years with the option to hold data for longer.

You might think that you would never need to hold audit data for longer than a year. And you could be right (and lucky), but in a world where litigation is rife and law cases go back over the events from several years ago, having audit data available to prove an event happened is a very good thing.

But Problems Exist

At least, having audit data available is good if the audit data is good. And since July 5, 2018, Microsoft has struggled with the truncation of the audit records ingested into the Office 365 event log for Azure Active Directory events like group and user creation, adding a user to a group, and removing users and groups. Truncation means that data is missing, a cardinal sin for any IT infrastructure.

I first reported this problem to Microsoft on September 12 after running into truncated audit records during a demo at the UK Evolve conference. A month and a half later, it’s a blessed mystery to me that Microsoft has not deployed a fix. Again, having data is goodness as long as the data are intact and valid. The Office 365 audit log has had a huge hole in it since early July that Microsoft needs to fix fast.

Chapter 21 in the Office 365 for IT Pros eBook is where you’ll find all the information you’ll ever need about the Office 365 audit log. We even tell you how to parse out the payload that holds the interesting audit data, except for those truncated records of course…

Compliance Events Happen All The Time

It is the nature of company business that events like projects happen all the time. A simple retention scheme that operates purely on the basis of items aging out after a set period is enough to handle the bulk of information accumulating in an Office 365 tenant, but it might struggle to deal with items linked to formal events. For that reason, Office 365 data governance includes the ability to define events and link content to those events in such a way that retention countdowns start when an event happens. That way you’ll be sure that you keep documents like contracts for as long as you need after something like a project completion.

Today’s Petri.com article explains event based retention in detail. If you need more information about how Office 365 data governance works, especially labels, you can find it in Chapter 19 of the Office 365 for IT Pros eBook. We have lots more to say about data governance across all the Office 365 workloads!

Auditing Deletions

Updated: March 2021

Ever since Microsoft introduced the current mailbox auditing mechanism in Exchange 2010 (an earlier version in Exchange 2007 took a different approach), it has been used to answer the question of “who deleted that message,” an issue that usually crops up when a delegate removes items from someone else’s mailbox or a shared mailbox and won’t admit their action.

Ingestion and Normalization

Microsoft enables mailbox auditing for all Exchange Online mailboxes for accounts with Office 365 E3 and E5 licenses. Audit records are not generated for accounts with other licenses. The audit records flow through a normalization process before the records are ingested into the Office 365 audit log. Normalization makes sure that the Exchange records have the same format as records from other workloads.

Searching for Email Deletions

You can look for delete operations through the audit log search in the Compliance Center, but it’s usually more convenient (and faster) to use PowerShell and run the Search-UnifiedAuditLog cmdlet.

Here’s an example that searches for hard and soft delete operations and extracts information from the JSON payload which holds the details of the action performed. In this case, we want to find who deleted a message. The results are piped to the Out-GridView cmdlet to view on screen.

$StartDate = (Get-Date).AddDays(-90); $EndDate = (Get-Date) 
[array]$Records = (Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Operations "HardDelete", "SoftDelete" -ResultSize 5000) 
If (!($Records)) { Write-Host "No deletion records found."; break } 
Else { 
 Write-Host "Processing" $Records.Count "audit records..." 
 $Report = [System.Collections.Generic.List[Object]]::new() # Create output file  
 ForEach ($Rec in $Records) { 
    $AuditData = ConvertFrom-Json $Rec.Auditdata 
    If ($AuditData.ResultStatus -eq "PartiallySucceeded") {
        $EMailSubjects = "*** Not deleted by" + $AuditData.ClientInfoString + " ***" }
    Else {
        $EmailSubjects = $AuditData.AffectedItems.Subject -join ", " }
    $ReportLine = [PSCustomObject] @{ 
      TimeStamp          = Get-Date($AuditData.CreationTime) -format g 
      User               = $AuditData.UserId 
      Action             = $AuditData.Operation 
      Status             = $AuditData.ResultStatus 
      Mailbox            = $AuditData.MailboxOwnerUPN 
      "Message Subjects" = $EmailSubjects
      Folder             = $AuditData.Folder.Path.Split("\")[1] 
      Client             = $AuditData.ClientInfoString } 
    $Report.Add($ReportLine) }
  } 
$Report | Sort Mailbox | Select Timestamp, Action, User, Mailbox, "Message Subjects", Folder | Out-GridView

The formatted records are placed in the $Report list. You can slice and dice the records to meet your needs, or export the data to a CSV file and then format it with Excel or Power BI. For example:

$Report | Export-CSV -NoTypeInformation -Path c:\temp\ExchangeMailboxDeletes.csv


If you need to extract the records for a particular user or shared mailbox, apply a filter to the $Report list. For instance, to find just the records for a shared mailbox with a specific primary SMTP address, use a command like this to find the records for a target mailbox and pipe them to the Out-GridView cmdlet.

$Report | ?{$_.Mailbox -eq "BookBuild@office365itpros.com"} | Out-GridView

Figure 1 shows the result.

Another variant on the theme is posted in this article. The script used here is available in the Office 365 for IT Pros GitHub repository.

For more information about the Office 365 audit log and how to configure Exchange mailbox auditing, read Chapter 21 of Office 365 for IT Pros. If you want to read more about reporting from the mailbox audit log rather than the Office 365 audit log, it’s in Chapter 3 of the companion volume.

Brightening Label Names

Retention labels are a security and compliance feature. And like most things associated with security and compliance, the names given to labels are usually pretty boring. Names like Keep for Audit or Confidential or even Top Secret hardly stir the blood. The same is true for sensitivity labels, used to assign permissions to files and messages and to protect their content with encryption. For the remainder of this article, I’ll use label to refer to both retention and sensitivity labels.

To be fair, those charged with managing compliance for an Office 365 tenant might not want to excite users. But then again, they might want to add a touch of emphasis to a label, and you can do that with some special characters.

Getting Graphic

All characters you see have a code that tells the computer what to display on screen. Pressing keyboard keys inserts the codes for the most common characters into documents, programs, or anything else you might want to input into on a computer. But beyond the range of “normal” characters, we find special characters. To make the special characters appear on-screen, you must enter key combinations such as pressing the ALT key and then 26 on a numeric keypad to generate the right-arrow character → or ALT and 9781 to generate a snowman character  (here’s a good article to read on the topic).

Apart from the special characters, there’s the code to generate Unicode symbols, such as ALT+128274 needed for a lock  as well as a set of emojis (not that I ever recommend the use of an emoji in an Office 365 label).

Adding a Graphic to a Label Name

To add a special character to an Office 365 label, first create it in a Word document by inputting the necessary key combination. Then go to the Office 365 Security and Compliance Center and create a new label. Input the text part of the name and then cut and paste the symbol from the Word document to end up with something like Figure 1.

Complete the rest of the settings for the new label and save the label. Finally, add the label to a label policy and publish it to the Office 365 workloads.

Using the Graphic Label

After a short period, the label is available to SharePoint Online and OneDrive for Business (it takes longer to publish to Exchange because the Managed Folder Assistant must process mailboxes to make new labels available). As you can see in Figure 2, the label appears along with all the other published labels and can be applied to a document in the same way as any other label.

Exchange Retention Tags

Graphic symbols also work in Exchange retention tags. In Figure 3, we see two labels with graphics appear in OWA. The first (Locked Down) is created as an Office 365 label and published to Exchange, where it shows up as a personal tag. The second (Keep 10,000 days) is an Exchange personal retention tag.

PowerShell

The same technique works with other types of labels such as Azure Information Protection labels. As it should. The only issue I have run into is that the PowerShell console doesn’t like graphic symbols and treats them as non-printing characters. But you can cut and paste values containing graphic characters and use them with PowerShell. For example, to get details of the retention tag shown in Figure 3:

Get-RetentionPolicyTag -Identity "Keep 10,000 days "

Name Type Description
---- ---- -----------
Keep 10,000 days  Personal Managed Content Settings

What Will Microsoft Support Do?

I can’t see that any great harm is caused by using graphic symbols in labels. After all, the symbols are just character codes that computers can process and Office 365 is designed to be multilingual and cope with different character sets (like the way Teams deals with Hebrew and Arabic).

I haven’t tested the willingness of Microsoft Support to accept that symbols can be valid components of label names. It’s possible that some deep and dark flaw is lurking out there. And remember, once you give a name to an Office 365 label, you can’t change it because the label might have been applied to content. That small but very important point is likely the one that will stop people being more colorful with their labels.

To learn more about Office 365 labels, read Chapter 19 of the Office 365 for IT Pros eBook. Chapter 19 also explains how the Exchange Online Managed Folder Assistant works.