Maybe a Microsoft 365 Retention Policy is Better than an eDiscovery Hold

Last month, I wrote about how to replace Exchange Online litigation holds, which only preserve mailbox content, with holds applied by Purview eDiscovery cases. The advantage gained by this exercise is that eDiscovery holds can also secure the OneDrive for Business accounts owned by specific users, including those who leave the company.

My idea works, but it’s unnatural. eDiscovery cases are designed to secure information required by eDiscovery investigations, not to preserve information for indeterminate periods. Retention policies are the designated Microsoft 365 mechanism to retain information. Still, I enjoyed probing how to use eDiscovery case holds, and the good news is that much of the code written to prove the principle can be repurposed for retention policies.

Using a Retention Policy

A Microsoft 365 retention policy can cover many different types of data. In terms of mailbox data, a Microsoft 365 retention policy isn’t as granular as Exchange (“legacy”) retention tags, nor does a Microsoft 365 retention policy support the move to archive action to move items from a primary mailbox into its associated archive mailbox. For these reasons, Microsoft hasn’t deprecated Exchange retention policies and tags.

The question of granularity doesn’t arise with litigation holds because a litigation hold retains everything in the primary and archive mailbox. We can therefore replace litigation holds with a retention policy to hold everything indefinitely, and that policy will place a hold on everything in the mailboxes and OneDrive accounts that are added as locations to the policy.

Dealing with the 1,000-Location Limit

The only real limitation that exists is the maximum number of locations supported for Exchange mailboxes and OneDrive accounts. A retention policy that uses static locations can add up to 1,000 locations for each type. It’s unlikely that a tenant will have more than 1,000 mailboxes on litigation hold, but if this is the case, the choice is to either split the locations across multiple retention policies or use an adaptive scope to identify the mailboxes. A retention policy based on an adaptive scope isn’t subject to the 1,000-location limit.

The easiest way to mark mailboxes to be found by an adaptive scope is to set a value in one of the fifteen custom properties available for mailboxes. Each of the mailboxes (accounts) covered by an adaptive scope requires an Office 365 E5, Microsoft 365 E5, or Microsoft E5 Compliance license.

Creating the Retention Policy and Rule

A retention policy consists of two parts. The policy defines the set of target locations, like Exchange mailboxes, OneDrive accounts, SharePoint Online “classic” sites, and Microsoft 365 groups. Figure 1 shows the target locations for a “standard” retention policy. Specific retention policies can be created for Teams channel messages, Teams chat and Copilot interactions, and Viva Engage (Yammer) community messages.

The policy rule defines the retention settings, or what the policy does to the items found in the target locations. In this instance, the rule is very simple because the idea is to mimic what a litigation hold often does, which is to apply an unlimited hold. Litigation holds do accommodate a limited duration hold, and it would be possible to recreate this kind of hold with a retention policy, but here we’re just proving the principle, so it’s enough to show how to create the retention policy and a rule to hold continue indefinitely. Here’s the code:

Write-Host "Creating Microsoft 365 retention policy to replace litigation holds..." -ForegroundColor Yellow
$NewPolicy = New-RetentionCompliancePolicy -Name "Litigation Hold Retention Policy" -ExchangeLocation $MailboxesToHold -OneDriveLocation $OneDriveToHold  `
    	-Comment ("Retention policy to replace litigation holds created by Switch-LitigationHoldsforRetentionPolicies.PS1 script on {0}" -f (Get-Date).ToString("dd-MMM-yyyy")) `
If ($NewPolicy) {
    Write-Host ("Retention policy {0} created" -f $NewPolicy.Name) -ForegroundColor Green
    $NewPolicyRule = New-RetentionComplianceRule -Name LitigationHoldRule -Policy "Litigation Hold Retention Policy" -RetentionDuration unlimited `
        -Comment "Created by Switch-LitigationHoldsforRetentionPolicies.PS1 script" 
    If ($NewPolicyRule) {
        Write-Host ("Retention rule {0} created" -f $NewPolicyRule.Name) -ForegroundColor Green
    } Else {
        Write-Host "Failed to create retention rule" -ForegroundColor Red
        Break
    }
} Else {
    Write-Host "Failed to create retention policy" -ForegroundColor Red
    Break
}

If you want to create a more complicated retention rule, it’s probably best to do so via the Purview compliance portal GUI. You can download the script I used from GitHub.

After applying a retention policy, it can take a few days before the policy becomes fully effective. I’d wait a week and then remove the litigation holds from the mailboxes.

Dump Litigation Holds Now

I don’t hesitate to recommend phasing litigation holds out in favor of retention policies. At this point, litigation holds are a dead-end street that Microsoft is putting little or no effort into. By comparison, Microsoft 365 retention policies are more functional and under active development, which makes them a better long-term bet for meeting the retention needs of Microsoft 365 tenants.

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.

Finding Exchange Mailbox Audit Data Isn’t So Easy Anymore

From an engineering perspective, Microsoft’s decision to decommission the Search-MailboxAuditLog and New-MailboxAuditLogSearch cmdlets makes a ton of sense. Microsoft 365 apps consume shared services, and the unified audit service ingests the data used by these Exchange Online cmdlets. Why incur the engineering and support expense to keep the old on-premises cmdlets going?

Microsoft posted the news on January 14, 2025, and stopped writing audit log data to mailboxes on March 1, 2025. The cmdlets will disappear at the end of 2025. You might have missed this information because Microsoft posted to the security blog instead of the Exchange EHLO blog, where all the other Exchange-related news appears. Perhaps this is because audit data is related to Microsoft Purview and the topic therefore is in the security space. However, losing cmdlets that might be used in Exchange-related administrative processes is a big deal deserving better awareness.

In 2016, Exchange mailbox audit data was one of the first sources of audit events for the unified audit log. Ever since, mailbox audit data has flowed into the unified audit log and can be found by audit log searches, so what’s the problem?

Searching the Unified Audit Log for Exchange Mailbox Audit Data

Searches of the unified audit log can be performed synchronously using the Search-UnifiedAuditLog cmdlet or asynchronously through the Audit section of the Purview compliance portal or by submitting a job through the Graph AuditLogQuery API. Audit log searches can find mailbox data among the many other forms of workload data ingested on an ongoing basis, and searches can go back 180 days (audit standard) or 365 days (audit premium). It all sounds good.

But people build processes around PowerShell cmdlets, and when a cmdlet disappears, those processes must be redeveloped. In this instance, any script that uses the deprecated cmdlets must be altered, probably to use the Search-UnifiedAuditLog cmdlet. And let’s face it, even its biggest fans (and I’m probably in that category) wouldn’t consider Search-UnifiedAuditLog to be an easy cmdlet to use, and Microsoft has tinkered with the way the cmdlet functions over the years. Thankfully, they’ve retreated from the idea of making high completeness (very slow) searches the norm.

The parameters for audit log searches can be complex to construct, duplicate audit records can be retrieved, and there’s always the need to unpack the JSON structure contained in the AuditData property to find out what actually happened for the auditable event.

Those accustomed to interacting with the AuditData property know that every workload decides what information to include in audit events and how that data is formatted. Extracting properties from AuditData usually isn’t hard, but it’s tiresome to see how many variations Microsoft engineers can come up with when inserting data into audit events.

Apart from the issue of interpreting audit events, there’s also the simple fact that it’s easier to extract audit data for the actions of a single user from their mailbox. Finding the relevant information about mailbox events from the unified audit log is more complicated.

Find Exchange Mailbox Audit Data for a Single Mailbox

The easiest way to find audit records for a specific mailbox with the Search-UnifiedAuditLog cmdlet is to pass the user principal name for the mailbox owner (or, to search multiple mailboxes, a set of user principal names) in the UserIds parameter. Here’s an example that finds the audit records for a mailbox and reduces the set to those belonging to Exchange actions:

$RecordType = "ExchangeAdmin","ExchangeItem","ExchangeItemAggregated","ExchangeItemGroup","ExchangeSearch"
[array]$Records = Search-UnifiedAuditLog -Userids ‘kim.akers@office365itpros.com' -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -Formatted -ResultSize 5000 -SessionCommand ReturnLargeSet
$Records = $Records | Where-Object {$_.RecordType -in $RecordType} | Sort-Object Identity -Unique

Searching based on user principal names finds audit records for actions performed by that user. If you want to find audit records for actions performed by a mailbox delegate, use a free text search for the object identifier of the mailbox owner’s account. The free text search finds references to the mailbox owner in the AuditData property and includes those records in the set returned. Here’s an example of using an account identifier in a free text search. It’s important that the identifier is cast as a string as otherwise the search will fail because it will attempt to use a GUID where the cmdlet expects a string:

[array]$Records = Search-UnifiedAuditLog -Freetext ((Get-ExoMailbox -Identity Tony.Redmond).ExternalDirectoryObjectId -as [string]) -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) -Formatted -ResultSize 5000 -SessionCommand ReturnLargeSet
$Records = $Records | Where-Object {$_.RecordType -in $RecordType} | Sort-Object Identity -Unique

The Bottom Line

You might not have been aware of the change to the old cmdlets. They still work (for now), but mailbox audit data generated since March 1, 2025, cannot be retrieved using the cmdlets. In any case, it’s a good idea to check scripts to find any instances where the old cmdlets are used. The bad news is that those scripts must be redeveloped. Good luck!

Moving from Single-Workload Holds to Microsoft 365 Holds

Many tenants use litigation holds (also known as legal holds) to retain the complete content of Exchange Online mailboxes. The feature has been available since Exchange 2010 and can hold mailbox items (including associated archive mailboxes) indefinitely or for a specified period. The good thing about litigation holds, which is probably why people use them, is that it’s very easy to put one or more mailboxes on hold using PowerShell or the Exchange admin center (Figure 1).

The PowerShell equivalent to set litigation hold on a mailbox is:

Set-Mailbox -Identity Brian.Weakliam -LitigationHoldEnabled $True -LitigationHoldOwner "Tony.Redmond@office365itpros.com" -LitigationHoldDate "21-Apr-2025 16:00" -LitigationHoldDuration Unlimited -RetentionURL "https://office365itpros.com/AllAboutLitigationHold.Html"

While this command lists the set of mailboxes with litigation hold enabled:

Get-ExoMailbox -RecipientTypeDetails UserMailbox -Properties LitigationHoldEnabled, LitigationHoldDate, LitigationHoldDuration, LitigationHoldOwner -Filter {LitigationHoldEnabled -eq $True} -ResultSize Unlimited | Format-Table DisplayName, LitigationHoldDate, LitigationHoldOwner, LitigationHoldDuration

Inactive mailboxes can also be on litigation hold (and the hold might be the reason why Exchange Online retains these mailboxes):

Get-ExoMailbox -InactiveMailbox -Properties LitigationHoldEnabled, LitigationHoldDate, LitigationHoldDuration, LitigationHoldOwner -Filter {LitigationHoldEnabled -eq $True} -ResultSize Unlimited | Format-Table DisplayName, LitigationHoldDate, LitigationHoldOwner, LitigationHoldDuration

To release the litigation hold for a mailbox, set its LitigationHoldEnabled property to $false.

Set-Mailbox -Identity Kim.Akers -LitigationHoldEnabled $False

Or for an inactive mailbox:

Set-Mailbox -InactiveMailbox Dylan.Webb -LitigationHoldEnabled $False

This action clears the other litigation properties. Enabling or removing a litigation hold from a mailbox is usually effective within a few minutes but can take several hours.

The Bad Thing about Litigation Holds

Litigation Holds are easy to apply and manage and are available for all Exchange Online mailboxes. But their big downside is that litigation holds only cover mailbox items. That was an acceptable state when the need to preserve personal information for an employee only extended to email. Today, Microsoft 365 apps store so much information in a user’s OneDrive account that it is imperative to preserve this data when someone leaves.

Within Microsoft 365 today there are many other ways to communicate, including Teams, OneDrive for Business, Microsoft 365 Groups, and Viva Engage. Along with mailboxes, those locations are all covered by Microsoft 365 retention policies, which are the modern alternative to litigation hold.

However, I’m not going to cover retention policies here. Instead, I’m going to throw out a different idea, which is to use an in-place hold imposed by a standard eDiscovery case (available with Office 365 E3 and above or Microsoft E5 compliance licenses). Perhaps the recent GUI overhaul for Purview eDiscovery prompted me to investigate this solution.

Holds are only one part of eDiscovery cases, which also include searches, review sets, and exports covering multiple data sources. In the scenario where an organization wants to keep personal information for employees for a period (perhaps after employees leave), an eDiscovery case might replace litigation holds and deliver the additional benefit of holding OneDrive for Business accounts.

Creating an eDiscovery Case with PowerShell

The eDiscovery case we need is simple. It consists of:

• The case (created with New-ComplianceCase). A container for the case elements, like holds and searches,
• A case hold policy (created with New-CaseHoldPolicy) defines the set of locations (mailboxes and OneDrive for Business accounts) that the hold will apply to.
• A case hold rule associated with the case hold policy (created with New-CaseHoldRule). The rule specifies the KQL query used by the hold. In this case, to create a hold that applies to everything in the mailboxes and OneDrive for Business accounts, the KQL query is empty.

Before running any of these cmdlets, you must connect to Exchange Online and the compliance endpoint, and the account used must have the eDiscovery manager role.

An example script is worth hundreds of words. You can download my example from GitHub.

Delegated Permissions and OneDrive for Business

The script is intended for use with delegated permissions. It would be possible to use app-only mode, but I wanted to illustrate an important an important aspect of dealing with OneDrive for Business accounts.

The Sites.Read.All permission allows the signed-in user to read details of all SharePoint Online sites – but not OneDrive for Business accounts, even if the account is a SharePoint administrator. This is a little strange because the SharePoint administrative interfaces allow access to OneDrive.

The full URL for a OneDrive account is needed to add it to an eDiscovery case hold policy (or a retention policy). This is a value like:

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

Even with the Sites.Read.All delegatedpermission, you can’t use the Get-MgUserDrive or Get-MgUserDefaultDrive cmdlets to get the OneDrive URL (you can with the application permission). I therefore use a little trick of retrieving the OneDrive usage report data for the last 90 days and extracting the user principal name and site identifier from the data. The script can use the site identifier with the Get-MgSite cmdlet to find the OneDrive URL. It’s a little complicated, but the code works. It would be nice if the usage report data included the site URL. However, a longstanding problem that Microsoft seems incapable of solving means that the site URL is missing from SharePoint Online and OneDrive usage reports.

Easier Solutions Exist

It would be easier to use the Microsoft Graph PowerShell SDK in app-only mode and have full access to the OneDrive account information, but this is an example of how it’s often possible to get at Microsoft 365 data when it seems to be blocked. It would also be easier to move mailboxes (and their OneDrive accounts) from litigation hold to a retention policy instead of an eDiscovery case, but where’s the fun in always taking the easy route?

If you’re still using litigation holds, the question is why? In 2010, litigation holds were the best we could do in terms of preserving mailbox content. In 2025, we can do better, and there’s many ways to satisfy the need to preserve data, including OneDrive.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. 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.

Part of Revamp of Purview eDiscovery to Embrace a Unified Framework

Microsoft is in the middle of a campaign to modernize the Purview eDiscovery solution. Previously, I wrote about the announcement and the possible impact on tenants and eDiscovery investigators. The big idea here is that Purview eDiscovery is moving to a unified framework covering all types of eDiscovery activities with the functionality available to users being determined by the license they hold. In a nutshell, E3 means standard eDiscovery, and E5 means access to premium eDiscovery.

The nature of these things is that the devil is in the detail, which only comes out as Microsoft introduces changes to implement the grand plan. An example is in message center notification MC1055528 (14 April 2025), which explains a set of component retirements to implement some big changes from May 26, 2025.

Content Searches Presented in an eDiscovery Case

First, the Content Search option in the Classic eDiscovery (i.e., the eDiscovery UI that Microsoft revamped (badly) in 2021) will disappear. Its replacement is a new Content Search option that displays the set of content searches within the new eDiscovery UI. Be aware that the new UI (which is also used with old cases) is very different to what’s available in classic eDiscovery. The query and locations (search targets) are moved over, but the process of running searches and examining samples of results found by searches is very different.

Essentially, there’s one big eDiscovery case (called Content Search) that holds all the content searches. As you can see from Figure 1, I have content searches going back to January 2015. Someday soon I must clean out the old searches.

Note the two little icons above the list of searches. TR is for me, and EM indicates that my account holds the eDiscovery Manager role.

Removal of Classic eDiscovery Option

Today, the eDiscovery section of the Purview compliance portal includes a Classic eDiscovery option. This option is going away and is replaced by the Cases option. Essentially, all the old eDiscovery cases become standard eDiscovery cases in the new framework. The Content Search case that holds all the old content searches is one of the new cases.

Removal of Export Capability from PowerShell Cmdlets

The compliance PowerShell module contains a set of cmdlets to manage eDiscovery content searches and cases. Microsoft says that they will disable (remove) the export-related parameters from the cmdlets that manage content search actions:

• New-ComplianceSearchAction -Export parameter
• Get-ComplianceSearchAction -Export parameter
• Set-ComplianceSearchAction -ChangeExportKey parameter

All other eDiscovery cmdlets are unaffected, so you might ask why Microsoft is focusing on the export feature. I assume that two factors are in play:

1. Microsoft wants to remove content searches eventually. Removing the ability to export the results of content searches with PowerShell forces standard users to export search results via the Purview portal.
2. Different export mechanisms are used. Content searches move the results of full searches (not estimate searches) to a protected location in Azure and exports the data from there using the content download tool. Users must have the correct export key to download data. In the new eDiscovery, the export process creates export packages that are downloaded from the Purview compliance portal.

Removing the ability to export search results via PowerShell might impact some scripts. Going forward, the only way to programmatically control eDiscovery exports is with the eDiscovery Graph API (the reviewSet export API). The downside here is that the Graph API only supports premium eDiscovery cases, so if your license only allows standard eDiscovery, you can’t use the API.

A Potentially Disruptive Change

The takeaway is that processes that use content searches for various kinds of investigations must be revised before Microsoft pulls the plug on the older eDiscovery mechanism on May 26, 2025. The steps to find material through eDiscovery are different, the UI is different, and some of the terms used in the GUI and documentation are different. All in all, this is a big change that will also affect tenant administrators who use content searches for different reasons, like finding SharePoint Online files without retention labels. Prepare for some disruption!

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.

Peeling Away the Layers to Find the Cheapest Auto-Label Option

Last week, I discussed how to use auto-label policies to apply sensitivity labels to old files in SharePoint Online sites to prevent their discovery and use by Microsoft 365 Copilot. The approach works but it’s only viable if a Microsoft 365 tenant has the necessary licenses to support auto-label policies.

Understanding Microsoft licensing is an art form and getting things right is important when a licensing decision might affect everyone in a tenant. In this instance, the requirements for information protection service-side automatic sensitivity labeling from the Purview service descriptions and license guidelines page seem pretty straightforward (Figure 1).

The same information is available in the Microsoft 365 Compliance Licensing Comparison Excel worksheet (also available as a PDF).

Licensing Trainable Classifiers

Purview extends over many different solutions. In my original article, I suggest using a trainable classifier to locate old files, so we need to check that licenses under consideration also cover trainable classifiers. The same page says:

“To auto-apply retention labels using a trainable classifier, the following licenses provide user rights:

• Microsoft 365 E5/A5/G5
• Microsoft 365 E5/A5/G5/F5 Compliance and F5 Security & Compliance
• Microsoft 365 E5/A5/F5/G5 Information Protection and Governance”

Licensing Costs

It seems clear then that the licensing requirement is met by having one of these SKUs (listed in order of cost):

• Microsoft 365 E5 (or Office 365 E5).
• The Microsoft E5 Compliance add-on ($12/user/month)
• The Microsoft E5 Information Protection and Governance add-on ($7/user/month).

Microsoft 365 E5 Information Protection and Governance add-on is a subset of the Microsoft 365 E5 Compliance product. According to this page, the Information Protection and Governance add-in is available for the following base licenses (Figure 2):

Interestingly, although Microsoft 365 Business Premium supports the E5 Security add-on, Microsoft still doesn’t support the E5 Compliance add-on for these customers – but Microsoft 365 Business Premium tenants can buy the Information Protection and Governance add-on. It’s an anomaly.

The takeaway is that if a tenant can restrict its licensing requirements to as tight a set as possible, it might be possible to reduce the overall cost for extra licenses quite considerably.

Who Needs the Licenses?

Microsoft’s general licensing guideline for Purview solutions is that anyone who benefits from a feature must be licensed for that feature. In practical terms, this means that anyone with access to a SharePoint Online site that’s processed by an auto-label policy requires a license. The same rule applies to other forms of auto-labeling, such as defining a default sensitivity label for a document library.

The DIY Option to Sensitivity Labeling

Let’s imagine that you don’t want to pay Microsoft any more licensing fees but still want to apply a sensitivity label to a bunch of old files. It’s possible to do this with a DIY app, but it will still cost because the Graph assignSensitivityLabel API is a metered API and costs $0.00185 each time the API applies a label to a file, or $185 per 100,000 files.

Sensitivity labels can’t process every type of file that’s found in SharePoint Online. The API can only deal with Office documents and PDF files. Older Office documents (.DOC, .XLS, and .PPT files) are unsupported, so some testing is needed to establish exactly what in the target content can be processed.

If you only plan to apply sensitivity labels to a set of known files and don’t need to use advanced capabilities like trainable classifiers to find items like invoices, customer orders, project plans, and so on, then the DIY option could be the right choice. The code to report the files in a SharePoint document library isn’t hard, and once you have a list of files, you can review and trim the set and then use it as input to an app to apply sensitivity labels.

Depending on how many files are to be processed, the DIY

approach can save a lot of money over licensing costs. Apart from having to pay to create, test, deploy, and support the code, the downside is that DIY labeling is a one-off mechanism without the benefits of ongoing automatic labeling or any of the other advanced processing built into Purview. You pay your money and make your choice!

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.

Microsoft E5 Security for Microsoft 365 Business Premium Now Available

On April 6, 2025, Microsoft announced that the Microsoft E5 Security add-on is available to Microsoft 365 Business Premium tenants. Microsoft 365 Business Premium is one of the packages for small to medium businesses (up to 300 licensed seats). The E5 Security suite is a bundle of high-end features to improve the security of a tenant. Until now, Microsoft has targeted the add-on at enterprise customers with Office 365 E3 or Microsoft 365 E3 that want the extra security features without upgrading to Office 365 E5 or Microsoft 365 E5. This is the first time that Microsoft has made the add-on available for a small to medium product.

Finding Savings in Software Bundles

The unique selling point for the add-on is that it’s cheaper to buy it than license each of the features separately (Figure 1). Everyone loves a bargain, and saving 57% seems like a true deal.

The truth is that the E5 Security add-on is a bargain if your tenant can use its functionality. Careful assessment of each of the licensed features is necessary to understand where the tenant can gain value. For instance, if the organization currently doesn’t have the capacity to deploy Defender for Endpoint, that wipes $5.20 off the add-on’s value. If nothing can be gained from Entra P2, an extra $9 disappears, and suddenly the saving to license the other three features goes from $16.20 to $2. That’s still a saving of up to $600 monthly/$7,200 annually for a 300-person Business Premium tenant, which is not quite as impressive as the headline. And to get that saving, you must invest $43,200 annually to license the 300 seats.

On the other hand, if Entra P2 stops a tenant being compromised through an account that can be identified as risky or an attacker can be stopped because Defender for Cloud Apps detects a problematic app, then the cost of the E5 Security add-on is more than justified. It all depends on how a tenant can extract value.

The same point is valid for the Microsoft E5 Compliance add-on (also available for $12/month in the U.S.). A bunch of interesting compliance technology is covered by the add-on, but if you don’t want to use features like Insider Risk Management, Communication Compliance, customer lockbox, customer key (for sensitivity labels), and Information Barriers, the value proposition becomes much less attractive.

Playing the Licensing Game

License management is an essential competence for tenant administrators. I don’t mean negotiation of licensing deals with Microsoft. Instead, I’m referring to understanding what licenses are needed for the functionality required by the business, knowing the cheapest way to license that functionality, and keeping track of how licenses are used. Tools like the Microsoft 365 licensing report script can help here. If you don’t want to build your own tools and want an off-the-shelf product to manage licensing, I recommend CoreView license management (the sponsor of the Office 365 for IT Pros eBook).

The higher the individual license cost, the more important it is to track active and ongoing usage. Microsoft 365 Copilot is a good example. It doesn’t make sense to assign $360/year licenses to people who don’t use Copilot, so tracking Copilot usage to ensure that people with licenses use those licenses is important.

Have a Deployment Plan Before Buying Anything

If you need and can use their features, Microsoft 365 add-ins can be great value. I don’t recommend buying these add-ons unless a tenant has a plan to deploy and use the licensed technology to achieve well-defined results. Having something that you cannot use isn’t a great idea and buying expensive software just because it seems like a bargain has never been a great tactic. Small to medium enterprises might not have the expertise to assess the true worth of the functionality bundled in E5 Security add-in. If you’re in that situation, engage an expert to help build your plan.

For more information about using Microsoft E5 security with Microsoft 365 Business Premium, see the Microsoft documentation. The Microsoft E5 Compliance add-on is not available for Business Premium (but that might change).

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.

Combining Auto-Label Policies, Trainable Classifiers, Sensitivity Labels, and DLP to Stop Copilot Accessing Old But Still Confidential Files

I’ve been on the TEC 2025 European Roadshow this week. Monday was London, Tuesday Paris, and Dusseldorf is the final stop on Thursday. These trips sound like they should be great fun, but running events in three major cities over four days takes a brutal amount of effort.

In any case, my topic this week is protecting Microsoft 365 data in the era of AI. During the talk, I recommend that people use features like Restricted Content Discovery, sensitivity labels, and the (preview) DLP policy for Copilot to exert control over confidential and sensitive documents and restrict access to Copilot for Microsoft 365 and Copilot agents.

Find and Protect Old Confidential Material

All of which led to a great question at the London event: “how do I apply sensitivity labels to thousands of old but still confidential material files stored in multiple SharePoint Online sites.” It’s a good example of the kind of practical issue faced by tenant administrators during deployments.

The obvious answer is to use an auto-label policy to apply sensitivity labels that are then blocked by the DLP policy for Copilot. An auto-label policy can find Office documents at rest that don’t have sensitivity labels and apply a chosen label (manually-applied sensitivity labels are never overwritten but a policy can overwrite a lower-priority sensitivity label.

Trainable Classifiers

The issue is to identify the target set of confidential files. This is where a trainable classifier can help. Purview Data Lifecycle Management includes 75-odd built-in trainable classifiers that Microsoft has taught to find different types of documents like business plans and credit reports.

It might be possible to identify old confidential material using a built-in trainable classifier. If not, tenants can create custom trainable classifiers by using machine learning to process a training set of documents unique to the business. The process isn’t difficult, and the hardest part is often to find a suitable set of sample documents to train the classifier with. Running a simulation will quickly tell if machine learning can extract an accurate digital structure from sample documents to use as a classifier.

I have a couple of trainable classifiers in use to auto-label files. To test the process, I selected the default Source Code classifier (Figure 1). Behind the scenes, Purview looks for some matching documents to demonstrate how each of the built-in classifiers work. In this case, Purview had found several items in a projects site where I store files like drafts for blog posts. Some of the matching items had sensitivity labels, others did not. It was a good set to test the theory against.

Creating an Auto-Label Policy

The next step is to create an auto-label policy. Because we want to apply sensitivity labels, the policy is created in the Purview Information Protection solution. The policy settings are very straightforward. Look for files matching the source code trainable classifier in all SharePoint Online sites and apply the Confidential sensitivity label. Figure 2 shows the rule created to find files that match the trainable qualifier.

You can choose to run an auto-label policy in simulation mode before making it active. Even though the trainable classifier shows some sample files that it found, it’s still a good idea to run the simulation, just to be sure. When you’re happy with the results, you can activate the policy to have Purview assign the chosen sensitivity label to the files found by the policy. Once the files are labelled, they’ll be invisible to Copilot for Microsoft 365.

Background Processing Runs Until the Job’s Done

Depending on how many old files need to be protected, the entire process to create a trainable classifier, tweak the classifier until it’s accurate, and run auto-labeling might take several weeks to complete. Most of the work happens in the background at a pace dictated by demands on the service. The auto-label policy will continue to run unless you stop it, once all those old but still valuable files are labelled.

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.

Filter, Refine, and Report File Sharing Events from the Audit Log

A recent article about auditing file sharing activities in Teams generated some questions. The accompanying script searches for FileUploaded events, which have nothing to do with sharing. SharePoint Online captures FileUploaded events when users create new files in SharePoint sites.

In any case, after reading the article, it makes a case to keep an eye on files uploaded to Teams channels because it’s possible that someone might share information that results in a data leak. It’s a tenuous proposal that only makes sense in a weird sort of way. I am not saying that no one has never uploaded a file to a Teams channel that they shouldn’t have. Some mistakes will happen given that people create billions of files in SharePoint Online daily. But the sheer volume of FileUploaded events created in the unified audit log means that a simple report detailing these events is never going to be valuable. Filtering and analysis are required to extract value.

Most file activity logged by SharePoint Online is innocuous. To find value in the audit log, administrators need to know the data they want to find. As an example, it seems like it would be good to know who shares files from SharePoint Online, both through Teams and the SharePoint browser interface, and who they share the files with (internal and external).

Microsoft documents how to use audit data to track sharing activities. There’s lots of good information in that article to help you understand how SharePoint Online generates the content of the audit events generated to track sharing activities.

Finding File Sharing Events in the Audit Log

When I begin to figure out what audit data might be valuable for investigative purposes, I usually use several accounts to perform the activities I’m interested in (in this case, sharing documents), wait about 30 minutes, and then go through the events that turn up in the audit log. Searching the audit log with a command like this returns SharePoint sharing events. Make sure that the start and end dates are limited to the period when the actions of interest occur:

[array]$Records = Search-UnifiedAuditLog -StartDate '2-Apr-2025 19:00' -EndDate (Get-Date) -Formatted -SessionCommand ReturnLargeSet -ResultSize 5000 -RecordType SharepointSharingOperation

Analyzing the audit data revealed that SharingSet events happen to set up a sharing link. UserExpirationChanged events are also found if the sharing link policy sets expiration dates for sharing links. If you cast the audit net wider and look for other events, you’ll also find Send events logged when SharePoint Online sends notification messages to inform people that someone has shared a file with them.

Filtering File Sharing Events

The audit log is a rich source of information that can be overwhelming because of the amount of logged data. When searching for answers, it’s important to focus. In this instance, I extracted only the SharingSet events and then filtered the returned set to remove sharing events that I wasn’t interested in. These events included:

• Sharing for SharePoint embedded applications such as Loop and Outlook Newsletters.
• Sharing performed by the background app@sharepoint app. For instance, when SharePoint Online shares the recording of a Teams meeting (stored in the OneDrive of the meeting organizer) with meeting participants.
• Sharing set operations to adjust SharePoint lists. When a user shares a document, SharePoint Online adjusts the group that controls access to that item within the site, which results in audit events being logged for groups like “Limited access system group for list.” A Microsoft article covers permission levels and explains what these groups mean.

Essentially, the only sharing events I am interested in are those involving member and guest Entra ID accounts (i.e., humans).

The lesson here is that retrieving a set of events from the audit log seldom delivers useful results. It’s usually the first stage in a process to remove unwanted events to focus on the valuable information.

Parsing and Reporting Sharing Audit Events

The next step is to parse the information contained in the remaining audit events to answer the questions who shared what with whom and what level of access did they grant? Most of this information is hidden in plain sight in the AuditData property of audit events. The data must be extracted, cleaned up, and enhanced.

For example, if your organization uses sensitivity labels to protect files (and you should), the audit events note the GUID of the label applied to the shared file and the GUID of the label applied to the host site (container management label). Resolving the GUIDs to label names makes this information more accessible. Knowing that a shared file has a sensitivity that will block unauthorized access is always a nice feeling.

The result is a report of file sharing events (Figure 1) that answers the question of who shared files from SharePoint Online with whom and what access was granted.

In addition, because the script extracts the email addresses of sharees, you can analyze the volume of sharing to external domains:

$AuditReport | Group-Object TargetDomain -NoElement | Sort-Object Count -Descending | Format-Table Name, Count

Name                        Count
----                        -----
microsoft.com                  11
o365maestro.onmicrosoft.com     4
contoso.com                     2
proton.me                       1

Report File Sharing Events to Meet Your Requirements

Like anything published on the internet, the script (available from GitHub) might or might not satisfy your requirements. But it’s PowerShell, so you can change the code to meet your needs. I used the Graph AuditLog Query API to retrieve audit data. The same data is available by running the Search-UnifiedAuditLog cmdlet.

The takeaway is that real value is seldom extracted from audit logs without some additional processing to refine, filter, and interpret the information. Articles that merely extract and report audit data don’t add much value because they don’t tell the full story and reveal the actionable data that administrators need.

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.

Use Audit Events to Track Down Retention Label Assignments

A reader of my article about how to write a PowerShell script to report files and folders in a SharePoint Online document library observed that while the report details the retention labels assigned to items, it doesn’t say who assigned the labels. This is absolutely true, and it’s because SharePoint Online doesn’t note details of the last retention label assignment (date, user, etc.) in the information available through the Files Graph API. If the data isn’t available, it cannot be included in a report.

But retention label assignment is an auditable action. Details of assignments are captured by SharePoint Online and ingested into the unified audit log roughly 30 minutes after someone assigns a retention label to an item.

Searching for Retention Label Assignments

It’s easy to search the audit log for the logged events (the “TagApplied” operation is used here; the ComplianceSettingChanged could also be used) and report that information. Here’s some simple code to find the relevant audit events:

[array]$Records = Search-UnifiedAuditLog -Operations TagApplied -StartDate $StartDate -EndDate $EndDate -Formatted -SessionCommand ReturnLargeSet -ResultSize 5000

If ($Records.Count -eq 0) {
    Write-Output "No TagApplied events found in the last 30 days"
    Break
}   Else {
    # Get rid of duplicates
    $Records = $Records | Sort-Object Identity -Unique
    Write-Output ("Processing {0} retention label assignment events..." -f $Records.Count)
}

If the search is likely to return more than 5,000 events, it’s probably best to use the Graph AuditLogQuery API to perform an asynchronous search. Background searches can find hundreds of thousands of audit records if necessary.

The search finds assignment events when labels are applied manually by a user or automatically by an auto-label policy. In many careful scans of the audit log, I cannot find any events captured when files are uploaded to a document library and receive the default retention label configured for that library. The documentation says that events are triggered when retention labels are applied manually or automatically to a document but perhaps default retention labels are omitted.

Parsing the Audit Records

After finding relevant events, the next step is to remove any duplicates and sort the set by date.

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

The code then loops through the set to extract details and create a report. The name of the retention label and details of the file such as its name and host site and folder are in the AuditData structure, which must be converted from JSON to a PowerShell object to allow easy extraction of the properties.

The next issue is to find out who assigned the retention label. This is simple when users assign retention labels manually because the audit record stores the user principal name in the UserIds property. It’s less straightforward when auto-label policies are involved because the UserIds property contain the GUID of the retention policy rule that caused the label assignment to occur.

To translate the rule GUID back to a policy name, we need to find the GUID of the policy (because that’s how the rule links to its policy) and then extract the policy name. The code to resolve the rule GUID is not difficult, but it depends on being able to lookup the registered compliance policy rules and policies in the tenant. I use hash tables for this purpose and populate the tables with the Get-RetentionCompliancePolicy and Get-RetentionComplianceRule cmdlets.

Two GUIDs couldn’t be resolved by this method. I assume these represent background processes run by SharePoint Online to apply policies, so I declared the GUIDs in an array:

[array]$SharePointAutoLabelId = 'eba15bfd-c28e-4433-a20e-0278888c5825', 'a405a596-28e7-43c6-8ac7-76e0fc13ee0f'

If the GUIDs are found in audit records, the code reports them as “SharePoint Auto Label process.” One of the two GUIDs (‘eba15bfd-c28e-4433-a20e-0278888c5825’) is involved with the application of retention labels for document versions for cloudy attachments captured by a special policy, so I think it’s reasonable to assume that the other GUID represents some other form of background processing. Figure 1 shows some sample output.

You can download the full script from the Office 365 for IT Pros GitHub repository.

Chasing Default Retention Label Assignments

Although using the audit log to answer the question about who assigned retention labels to files is reasonably accurate, I’m unhappy to find that default retention label assignments aren’t audited. Or at least, I can’t find the right audit event to report. I’ve asked Microsoft about the issue and hopefully they can clarify what’s going on.

Need some assistance to write and manage PowerShell scripts for Microsoft 365? Get a copy of the Automating Microsoft 365 with PowerShell eBook, available standalone or as part of the Office 365 for IT Pros eBook bundle.

DLP Policy for Microsoft 365 Copilot to Restrict Access to Sensitive Documents

Ever since the introduction of Microsoft 365 Copilot in March 2023, organizations have struggled to stop the AI consuming confidential or sensitive documents in its responses. Some of the early tools, like Restricted SharePoint Search, were blunt instruments hurried out as responses to customer requests. Microsoft’s current best answer is SharePoint Restricted Content Discovery (RCD), a feature normally licensed through SharePoint Advanced Management (SAM). All tenants with Microsoft 365 Copilot licenses are due to receive access to RCD and the deployment process is ongoing.

Microsoft says that the key use case for RCD is to “prevent accidental discovery of [files stored in] high-risk sites.” RCD works by limiting the ability of end users to search selected sites. By excluding sites from search, RCD prevents Copilot Chat (and agents based on Copilot Chat) from using the files stored in those sites in its responses. It’s still possible for Copilot to use information from a sensitive document if the user has the file opened in an app like Word. At this point, the sensitive content is open in memory and available for Copilot to process.

Blocking files from user access doesn’t stop system functions like eDiscovery working.

Update April 21: MC1059677 announces the extension of DLP protection to Copilot in Office apps (Word, PowerPoint, Outlook, and Excel).

Blocking Access to Individual Files

RCD is a good way to cast a protective net across multiple sites. But what about protecting individual files that might be in sites that aren’t covered by RCD? Until now, the answer has been to use sensitivity labels to stop Copilot Chat using sensitive files to generate its responses. Although sensitivity labels can stop Copilot using the content of protected files, it cannot prevent Copilot finding reference protected files through a metadata search.

Creating a DLP Policy for Microsoft 365 Copilot

A solution to that problem might be coming in the form of a new type of Data Loss Prevention (DLP) policy. The feature is described in message center notification MC937930 (last updated 6 February 2025, Microsoft 365 Roadmap ID 423483). DLP policies are usually used to block external sharing of confidential information, like Teams meeting recordings. Blocking files for internal consumption is a new step.

Essentially, tenants can create a DLP policy to check for specific sensitivity labels and block Copilot Chat (and agent) access to files with those labels. The functionality is now in preview and is scheduled for general availability in June 2025 (complete worldwide by the end of July 2025). Some gaps are always expected in preview code, and the gaps right now include alerts, incident reports, policy simulation, and audit records. In other words, it’s very hard to know when a DLP policy match happens to block access. But testing indicates that the DLP policy works.

The DLP policy for Microsoft 365 Copilot is a special form of policy in that the policy only covers Copilot and no other type of data (Figure 1).

The rules used in a DLP policy for Microsoft 365 Copilot are simple. The policy checks if a file has a specific sensitivity label, and if the sensitivity label is found, DLP executes the action to “prevent Copilot from processing content” (Figure 2). A rule can check for the presence or one or more sensitivity labels. In some respects, it might be easier to create a separate rule for each label.

Testing the DLP Policy for Microsoft 365 Copilot

To test the new DLP policy, I created several documents referring to regulations governing cryptocurrency in Iceland (a topic selected at random because I knew that my tenant was unlikely to store any files relating to the topic). I used Copilot for Word to generate the text for each file and added a reference to a mythical regulation to the text of each document to give Copilot an easy target to find. The first check asked Copilot Chat to find documents relating to cryptocurrency in Iceland with special relevance to the regulation. The sensitivity labels assigned to the documents were not covered by a DLP policy for Microsoft 365 Copilot, and Copilot found all the documents (Figure 3).

After applying sensitivity labels covered by the DLP policy for Microsoft 365 Copilot to two of the three documents, the search was rerun and Copilot found only one document (Figure 4).

I don’t pretend this to be a full test. However, it’s the only way to check preview software that doesn’t generate audit records or other traces to show when DLP policy matches occur to force DLP to execute the defined actions.

New DLP Policy Shows Promise

I’ll look forward to retesting the DLP Policy for Microsoft 365 Copilot after the software reaches GA and the full array of auditing and reporting options are available. Auto-label policies can only apply sensitivity labels to Office files and PDFs, and I suspect that this limitation won’t be lifted. That’s a pity because it stops the DLP policy being able to control access to items like the .MP4 files used for Teams Meeting Recordings (transcripts).

The nice thing is that users see no trace of a sensitive document show up in Microsoft 365 Copilot Chat. Unlike basic sensitivity label protection, which allows Copilot Chat to show metadata found in its searches, the DLP policy is silent. And that’s just the way you’d want it to be when dealing with sensitive data.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. 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.

On Demand Classification Processes Cold Files to Find Sensitive or Confidential Information

Message center notification MC1013459 (21 February 2025) announces that Microsoft will introduce a new Information Protection service to find and classify “historical data in SharePoint Online and OneDrive for Business,” or as Microsoft 365 roadmap item 475062 says “scan cold files.”

The idea seems to be that tenants might have a bunch of files in SharePoint and OneDrive that have never been scanned or not been scanned in some time. Purview solutions like Data Loss Prevention (DLP) and Information Protection (sensitivity labels) tend to operate against active files created and edited by users. Cold files gather the digital equivalent of dust and might never be accessed, and it’s possible that those files contain many types of sensitive data.

Closing the gap by finding and classifying the information discovered in “cold files” is what the new On Demand Classification service is all about. By processing historical data, an organization can make sure that the files present in the tenant are classified appropriately. Once classified, policies can be automatically invoked to apply actions like assigning sensitivity or retention labels to files.

Preview of On Demand Classification in March 2025

Perhaps because trainable classifiers are an important method for tenants to find information that’s specific to their business, On Demand Classification is available through the classifiers section of the Purview DLP solution.

Microsoft expects to begin the deployment of a preview version of the code to targeted release tenants in late March 2025 with the goal of attaining general availability in mid-June 2025. Dates have been known to slip in the past, especially with new services, so treat these dates with caution.

Pay As You Go On Demand Classification

The On Demand Classification service is an example of the kind of new functionality that Microsoft bundles into its Office 365 E5 and Microsoft 365 E5 products to tempt customers to upgrade. That’s not the situation in this case. On Demand Classification is the first Purview Pay-as-you-go (PAYG) service.

PAYG is not unknown in Microsoft 365. SharePoint Online has PAYG services like Microsoft 365 Backup, Microsoft 365 Archive, and Document Translation, all of which require customers to have an Azure subscription attached to a valid credit card to pay for metered resource consumption. Other examples include the Graph API to apply sensitivity labels programmatically to Office documents and PDF files in SharePoint Online and OneDrive for Business and the export APIs for Teams and Exchange Online.

The case can be made that all the PAYG offerings are optional and not mainline services. They fill niches that not every Microsoft 365 customer wants or needs. It would be possible to include these services in the Microsoft 365 E5 product, but likely at an increased cost for everyone. Overall, it seems fairer for Microsoft to do the software engineering to create the solutions and realize a return by selling metered services to customers that need these capabilities.

No Details about Service Limitations

Microsoft hasn’t released any details about potential service limitations like the 100,000 items per day maximum an auto-label policy (sensitivity labels) can process within a tenant. We don’t know what kind of cold file types can be processed or if specific policy-invoked actions are restricted to certain types. The screenshot released by Microsoft (Figure 1) doesn’t give any insight into how long a scan might take or how long the subsequent processing might require.

All will be revealed when we get the software to test sometime in March 2025. Of course, some historic data must be found for On Demand Classification to process, but I’m sure that I have some old articles or book files hanging around that deserve to be heated up.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. 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.

Event Alert Policies Retired from March 25, 2025 but Activity Alerts Stay

Publish bad news on Friday is the advice for anyone who wants the news to create less of a fuss. Publishing the news late on Friday before a holiday the following Monday (U.S. Presidents’ Day) might do an even better job of suppressing criticism. Some will consider the announcement in Message center notification MC1006620 (15 February 2025) that “Purview will retire the event alerts capability within the Purview Audit solution on March 24, 2025” to be bad news. It all depends on whether you use alerts based on audit events to learn when something happens in a tenant.

Activity Alerts Remain Unaffected

An earlier version of this article reported on the retirement of activity alerts. As it turns out, my reading of the situation was incorrect. All I can plead is that the wording of MC1006620 obscured the true intent, which is that Microsoft plans to remove the ability to create event alert policies from the Purview Audit solution because this capability duplicates what’s already available in the Data Loss Prevention solution. Alert policies remain unaffected by the change and it’s still possible to create and manage activity alerts in PowerShell even if Microsoft’s position is that “Activity alerts have been effectively replaced by alert policies.”

Microsoft introduced activity alerts and alert policies soon after the introduction of the unified audit log in July 2015. The idea is simple. The audit log holds some extraordinarily valuable information about what happens in a tenant, but a busy tenant can generate hundreds of thousands of audit events daily. Human administrators don’t have the time to keep on checking if events of interest (for whatever reason) show up in the audit log. Computers are very good at checking data, and activity alerts are predefined checks against new audit events as workloads ingest data into the audit log. If an event of interest is found, Purview sends email to administrators to tell them about the event (Figure 1).

Using the Get-ActivityAlert cmdlet to review the activity alerts configured in my tenant reveals that I haven’t done much with these alerts for some time. However, the descriptions give you an idea about the kind of operations activity alerts can monitor.

Get-ActivityAlert | Format-Table Description, WhenCreated

Description                                                         WhenCreated
-----------                                                         -----------
This alert fires when ATP for SharePoint detects malware in a file. 21/12/2017 18:29:50
When a group is deleted...                                          04/04/2018 18:39:25
Creation of a new Team                                              27/07/2019 16:07:12
Fire when a team is deleted                                         28/01/2020 11:02:09
Any modification of chapter 19                                      14/12/2016 14:41:28
An alert to monitor the Send As and Send on Behalf of actions       14/12/2016 14:41:31
Alert for add user events                                           17/10/2016 11:57:23
Checking for excessive downloads                                    30/05/2016 00:03:29
All document check in events                                        30/05/2016 00:03:29

Better Tools to Analyze Audit Events Exist

Although useful (and still in use), a case can be made that activity alerts have passed their sell-by-date. The unified audit log holds an increasing amount of data generated by workloads from Entra ID to SharePoint Online to Teams to Purview. Better tools exist to allow tenant administrators to monitor events of interest, including connecting Office 365 data to Microsoft Sentinel where the data can be analyzed along with information gleaned from other sources. Many organizations run background jobs to extract audit events from the unified audit log for ingestion into an external SIEM. There’s even a Splunk add-on to extract audit data for Microsoft 365. And if you want to involve AI, there’s Security Copilot to consider.

And if off-the-shelf software isn’t available, PowerShell can be used to extract and analyze audit events using either the Search-UnifiedAuditLog cmdlet or the AuditLogQuery Graph API. The signs are that Microsoft wants customers to use asynchronous Graph-based audit searches because these searches absorb fewer resources. Removing the monitoring of new audit events to be able to generate audit alerts seems to be another attempt to restrict the resources consumed by audit activity.

Using either the cmdlet or Graph query, the same kind of processing to find and email alerts for audit events of interest is easily done using a combination of PowerShell and scheduled Azure Automation jobs.

Confusion with DLP Alerts

Data Loss Prevention (DLP) policies can also signal alerts when policy rules detect violations. MC1006620 confuses the issue slightly by reassuring tenants that DLP alerts are unaffected by the retirement of audit-based activity alerts.

In any case, as noted above, a range of options exist to monitor audit events and signal alerts if something of interest is discovered.

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

Use Azure Automation for Audit Searches

In the past, I published articles covering the basics of using Azure Automation to process Microsoft 365 data. The articles cover the basics of using an automation account to execute runbooks (PowerShell scripts based on the Microsoft Graph PowerShell SDK), how to output results to a SharePoint Online list, and how to attach runbooks to automation schedules to make sure that processes execute automatically and reliably.

This article covers how to execute Microsoft 365 audit searches in runbooks and how to send the results extracted from the audit searches via email. I’m going to use the scenario discussed on 24 January about a flaw found in Entra ID that allowed users to change their user principal names. Microsoft has since addressed the problem, but the fact still remains that changes to user principal names can have consequences for services other than authentication. Any change like this deserves oversight. The purpose is to explore the principles rather than the details of a solution, and the techniques used here can be applied to any audit log search.

Basic Outline to Create a Runbook for a Microsoft 365 Audit Search

Two methods are available to search the unified audit log.

• Synchronous searches performed by the Search-UnifiedAuditLog cmdlet from the Exchange Online module.
• Asynchronous searches performed by the AuditLogQuery Graph API. The API is in still in beta but it’s how the Purview Audit search solution works. SDK cmdlets are also available for the API.

Opting for the Graph API makes sense for an Azure Automation job. Asynchronous searches take longer but that doesn’t matter when the job executes in the background, especially if it’s a scheduled run. In terms of the code, Microsoft has temporarily withdrawn the Get-MgBetaSecurityAuditLogQuery cmdlet and the Get-MgBetaSecurityAuditLogQueryRecord sometimes doesn’t work, so we use Graph API requests in this example. I used V2.25 of the Graph SDK and the cmdlets might have returned by the time you read this text.

The basic processing steps are:

• Construct the parameters for the audit log search. The Update User operation captures changes made to user accounts, so that’s what the search looks for over the last seven days.
• Submit the search and monitor its progress until completion.
• Retrieve the audit records.
• Process the audit records to check if any are for changes to the userPrincipalName property and capture details of these events.
• Create a HTML fragment containing the events and use it to create the HTML content for a message.
• Run the Send-MgUserMail cmdlet to send the message to a predetermined recipient. This can be any valid email address. In production, it’s likely that the recipient would be a distribution list, but it could be a Microsoft 365 group, or even a Teams channel.

Testing the Runbook for a Microsoft 365 Audit Search

As always, it’s wise to test the runbook code by running it interactively in a Microsoft Graph PowerShell SDK session. The automation account must have the AuditLogsQuery.Read.All application permission to access audit logs and Mail.Send to be able to send email. See my earlier post for how to assign Graph permissions to automation accounts. In production scenarios, you should use RBAC for Applications to restrict access for the automation account to specific mailboxes.

To mimic what happens when Azure Automation executes the runbook, use an app-only session by signing in with an app identifier, tenant identifier, and a certificate uploaded to the app. The app must have consent to use the two permissions listed above. Once everything works interactively, copy the code and create a new Azure Automation runbook and test that the code runs in that environment (Figure 1).

When everything checks out, you can register the runbook with an automation schedule. This check is a good example of something that should be done bi-weekly. Of course, what the recipients do when they receive the message (Figure 2) is up to them.

Better than Microsoft 365 Audit Policies?

Similar functionality in terms of sending email notifications for events found by Microsoft 365 audit searches available through Microsoft 365 audit policies. The reason why a DIY version might be preferable is that you have full control over the content presented in messages and the advice given to recipients, plus any associated processing you might want to do. For instance, you could log the highlighted audit events in a SharePoint Online list and require administrators to attest that they checked each event to make sure that it’s appropriate. That might be too much, but it’s possible.

The code I used for testing can be downloaded from the Office 365 for IT Pros GitHub repository.

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.

Poorly Thought-Out Decision will Reduce the Effectiveness and Usefulness of the Search-UnifiedAuditLog Cmdlet

Update: On January 27, 2025, Microsoft announced that they will postpone the change to “address these concerns before making any lasting changes in the behavior of the cmdlet, and to minimize any impact on customers relying on this cmdlet.” Let’s hope that they do address the stability and performance issues noted in high completeness audit log searches.

On December 12, Microsoft published message center notification MC955752 to inform tenant administrators of a fundamental and problematic change in the way the Search-UnifiedAuditLog cmdlet behaves. In a nutshell, Microsoft proposes to make high completeness searches the only type of supported audit log search. That would be fine if these searches worked and were capable of finishing in a reasonable time. The problem is that high completeness searches are unreliable and take too long to complete.

Microsoft says that high completeness searches focus on retrieving a complete set of audit results in response to administrator queries. By contrast, they characterize the current behavior of the Search-UnifiedAuditLog cmdlet as speedy but can return “a subset of results.” My experience is that the current default tends to return too many results, which is why you should always sort the output set to exclude duplicates.

Microsoft then goes on to say that, out of the goodness of their hearts, they’re changing the way the Search-UnifiedAuditLog cmdlet works so that it will always run high completeness searches starting in late January 2025. To be fair, Microsoft notes that “search queries may take longer to finish.” I guess that they cannot get away from the fact that high completeness searches take between ten and twenty times longer to complete than the current searches.

A Complete Mess

I dislike the proposed change because I believe that making all audit log searches “highly complete” will affect scripts running in production today in ways that Microsoft has not anticipated.

As far as I can tell, the developers think about audit log searches as simple activities to recover audit log data. Those working with tenants use audit log searches for many other purposes, from forensic investigations following potential attacks to extracting audit results on an ongoing basis for ingestion into an external SIEM. Some ISVs use the cmdlet to extract audit information for their customers to use as the basis for some reporting.

Another example is where Microsoft engineering uses the Search-UnifiedAuditLog cmdlet to find evidence of the Exchange Web Services App Impersonation RBAC role in use. The script provided by Exchange engineering quickly becomes unusable when every iteration to find audit records takes ten minutes to complete.

Many scripts call the Search-UnifiedAuditLog cmdlet to find evidence of specific user activity. The searches might return just one or two records, enough to prove that someone is active, or they might deliver a more comprehensive assessment of the actions taken by a user account during a day. Waiting for ten minutes for a high completeness search to complete makes it impracticable for these scripts to use Search-UnifiedAuditLog (or the Graph API).

The Unreliability of High Completeness Searches

An even bigger problem is the unreliability of high completeness searches. I pointed this problem out when Microsoft released the feature in preview in April 2024. Things don’t seem to have improved much since. As an example, I ran the script to find SharePoint file operations to identify the last accessed time for documents, which is information that the Graph API for SharePoint cannot return. The search u looks for specific operations over a set period and is typical of the normal usage in Microsoft 365 tenants:

Write-Host ("Searching for SharePoint file operations in the {0} site between {1} and {2}" -f $TargetSearchSite, $StartDate, $EndDate)
[array]$Records = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -RecordType "SharePointFileOperation" -ResultSize 5000 -SessionCommand ReturnLargeSet -Formatted -ObjectIds $TargetSearchSite
If (!($Records)) {
    Write-Host "No audit records found"
    Break
}
# Remove any duplicates
$Records = $Records | Sort-Object Identity -Unique | Sort-Object {$_.CreationDate -as [DateTime]} 
Write-Host ("{0} SharePoint Online file operations audit records found" -f $Records.Count)

Running against the site I use to store the source documents for articles, a normal search retrieved 3,879 records in 31.02 seconds. This time included the sort to remove duplicates. Running the same search with the high completeness flag set resulted in a series of failures. For example:

Measure-Command {[array]$Records = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -RecordType "SharePointFileOperation" -ResultSize 5000 -SessionCommand ReturnLargeSet -Formatted -ObjectIds $TargetSearchSite -HighCompleteness}

WARNING: Failed to process request via HighCompleteness flag, returning HttpRequestException. Exception: InternalServerError , Reason: Internal Server Error.

Days              : 0
Hours             : 0
Minutes           : 8
Seconds           : 11
Milliseconds      : 42
Ticks             : 4910423270
TotalDays         : 0.0056833602662037
TotalHours        : 0.136400646388889
TotalMinutes      : 8.18403878333333
TotalSeconds      : 491.042327
TotalMilliseconds : 491042.327

In fact, despite many attempts over several days, the search never completed. Failures happened after six, seven, or eight minutes, even during the weekend when the service experiences light demand. Using high completeness searches was a deeply unsatisfying experience that doesn’t cast a good light on Microsoft engineering or software testing.

The Microsoft Imperative to Constrain Resource Demand

Microsoft has history in messing around with the Search-UnifiedAuditLog cmdlet in ways that affect production scripts. In September 2023, they changed the way searches worked so that fewer results were returned by default. Microsoft didn’t make any announcement at the time and denied that any change had occurred even though the evidence was clear and obvious that the cmdlet now functioned in a dramatically different way.

It seems to me that Microsoft is a victim of the audit log’s success. When it was first introduced, the audit log ingested data from core workloads like Entra ID, Exchange Online, and SharePoint Online for a relatively small number of events. Eight years later, thousands of different events are ingested from multiple workloads, which increases the resources required to store and process audit events. Another extra demand for resources came when Microsoft had to up the retention period for Purview Audit standard customers from 90 to 180 days. Conserving resources is why the Audit search in the Purview portal (Figure 1) only performs asychronous searches and doesn’t use the Search-UnifiedAuditLog cmdlet.

Microsoft points to the AuditLog Query Graph API as a method for programmatic access to audit data. This is true, but setting up and running AuditLog Query searches takes substantially more effort than running Search-UnifiedAuditLog does, even using the Microsoft Graph PowerShell SDK cmdlets to interact with the API. It’s one thing for Microsoft to switch the Audit search solution in the Purview portal to use the Graph API; it’s quite another to ask customers to upgrade all their PowerShell scripts to replace Search-UnifiedAuditLog. Making this suggestion in the message center notification displays a callous lack of appreciation about how paying customers use Microsoft software.

A Problematic and Concerning Change

The lack of robustness in high completeness searches is nothing but problematic. If you can’t rely on searches completing, you can’t include search processing in scripts. Although running interactive synchronous searches obviously takes more resources, it’s how paying customers extract value from the audit log.

Changing audit searches to high completeness is bad. It might save Microsoft some computing resources, it will impact production processes by forcing Microsoft 365 tenants to use unreliable and fallible methods to access what is, after all, their audit data. Microsoft should leave well enough alone and fix high completeness to make it an optional, slow, but (when fixed) dependable alternative for audit log searches.

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.

Analyze the Audit Events for a User Over a Single Day

I’m speaking about decoding the Microsoft 365 audit log at the ESPC conference in Stockholm, Sweden today. As part of the preparation for the session, I wanted to create a demo to highlight some of the challenges of interpreting audit records to attendees. I have many examples of PowerShell scripts that perform different tasks, like finding the last accessed date for documents stored in SharePoint Online. These scripts work well and solve problems, but they don’t shine a light onto the biggest single issue with audit log data. That issue is the maddening inconsistency found in the audit data payload contained in audit records.

The Two Parts of Audit Log Records

Audit records have two parts. The first is a consistent set of properties that must be respected by workloads when they generate audit records. These properties include the unique identity (GUID) for the record, a timestamp, the name of the user or process who performed an action, and the name of the action. The second part is the audit payload, a JSON structure contained in the AuditData property. Microsoft 365 workloads like Exchange Online and SharePoint Online control what they insert into the audit payload for their events, and no consistency and sometimes no reason governs what turns up in audit payloads.

The lack of consistency means that anyone attempting to interpret audit data must figure out what the audit payload contains and put it into context with what you know about the action captured by the event. The content differs from Exchange Online to SharePoint Online to Teams to Planner to Entra ID. The lack of consistency and the obvious errors in audit data points to poor control and attention to detail by engineering groups, both the team responsible for the audit log and the teams responsible for generating workload events.

Investigating User Actions for a Day

To illustrate the problem, I decided to create a script to report details of all actions taken by an individual user over a single day. I developed the script by fetching the audit records (about 2,200) logged for me on 27 November 2024 and reporting what I found. I stripped UserLoggedIn events from the set because of the number (946) of sign-ins to different applications from multiple devices. Most of the sign-ins are silent and result from the renewal of an access token. Figure 1 shows what the output report looks like.

The set of actions spanned interactions with multiple workloads for user activities like creating and updating documents, sending messages via Exchange and Teams, and reading a Planner task list. It also included some administrative actions like conducting an eDiscovery search, running some Exchange PowerShell cmdlets, and so on. No set of audit events for any single user will be 100% representative of what you’ll find across Microsoft 365, but I am confident that the results found in this set of audit records demonstrates the problem.

The script unpacks the audit payload for each event to extract a small set of properties for the report. A large Switch statement is used to interpret each type of event. It would be practically impossible to include every possible event, so I concentrated on common events and some that illustrate the problem.

In some cases, some of the properties contained in compliance audit records are obscured through Base64 encoding. Unfortunately, the encoding is resistant to PowerShell decoding unless you remove spurious characters at the end of the string. For example, here’s how the script handles events for the Get-ComplianceSearch action (retrieve details of a content search):

"Get-ComplianceSearch" {
   $Action = 'Compliance search retrieved'
   If ($AuditData.Parameters -eq '-ResultSize "Unlimited"' ) {
      $Object = "All results"
    } Else {
      $Object = [System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String( $AuditData.Parameters.Split('"')[1].SubString(0,32)))
    }
      $Location = $AuditData.Workload
      $Workload = 'eDiscovery'
   }

Some audit events contain details for multiple events. This is done for very good reason as the actions being captured are very common and would otherwise flood the audit log with data. The MailItemsAccessed event is a good example. This event is now available to Purview Audit Standard (Office 365 E3) customers and captures details of email items accessed by a user. The audit payload for a MailItemsAccessed event can contain details of 20 or 30 messages. MailItemsAccessed events can also contain details of sync actions (see this article and the associated script for details).

You can download the script to generate a report of user audit events for a day from GitHub. It’s easy to add processing for other events if you wish.

Consistency Would Make Administration Easier

The bottom line is that interpreting audit events takes a lot of knowledge and persistence. Like anything else in technology, the combination brings you a long way. It’s regrettable that Microsoft has allowed a situation to develop where nearly 2,000-odd audit events might need different processing to extract real value. Life would be so much easier if audit data was more consistent.

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.

New Names for Sensitivity Label Permissions Clarify Usage

Every time you look around, something is changing with sensitivity labels, like the introduction of dynamic watermarking. More prosaic but still important, a recent update posted by Microsoft covers changes to the names for the four default permissions used for sensitivity labels. The new names for the permissions are:

• Co-owner is now Owner.
• Co-author is now Editor.
• Reviewer is now Restricted Editor.
• Viewer retains the same name.

Microsoft changed the names to make their usage more apparent to end users. I think the change makes sense. Co-author was always a name that troubled me. If you’re the co-author of a document, surely it makes sense to share equal ownership rights for the document with the other authors?

Sensitivity Label Permissions and Usage Rights

Each permission is a set of usage rights deemed appropriate for a certain level of interaction with a file or email. Figure 1 shows the set of default usage rights for the Editor role. Notably, the Export usage right is excluded from the permission set, so anyone holding this role is unable to save a copy of a labelled item to remove encryption. They also can’t replace or remove a sensitivity label from an item.

It’s always best to assign sensitivity label permissions to groups, including the special groups defined for sensitivity labels like everyone in your organization and all authenticated users. The caveats are that everyone in your organization excludes guest accounts, and all authenticated users means anyone who can authenticate with Entra ID or a federated directory service, like Google. If you want to assign a permission to all full-time employees (or a similar category), use a dynamic Microsoft 365 group or security group to identify the recipients.

Changing the Usage Rights for Sensitivity Label Permissions

If you don’t like the usage rights assigned in one of the four default permissions, you can create a custom permission and include whatever rights you think users need. For example, you might decide that the OBJMODEL (right to run macros) is not required for the Viewer permission. This right was needed when Azure Information Protection displayed an information protection bar in the Office apps. That need disappeared when the Office desktop apps introduced the sensitivity bar. The Viewer permission allows people to read, edit, and save documents and doesn’t (as far as I see) need the right to run macros any longer.

The EXTRACT usage right gets a lot of attention these days because Microsoft 365 Copilot uses this right to copy content from protected documents to use to ground prompts to the LLM. Copilot runs in the context of the signed-in user, so if a sensitivity label assigns that person the right to extract content, Copilot can use the content in its generated responses, such as document summaries. For this reason, some organizations have removed the Extract right from all but the Owner and Editor permissions.

Stopping Copilot using content from sensitive documents won’t stop Copilot finding those documents. To hide documents from Copilot, you must limit search in some way, like blocking search results for sites or document libraries. Microsoft limits Copilot with the Restricted SharePoint Search (an allow list for sites available to Copilot) and Restricted Content Discoverability (a deny list for sites blocked for Copilot) features.

Figuring Out the Best Usage Rights for Sensitivity Labels

In any deployment, it’s important to make sure that sensitivity labels grant users the usage rights necessary to get their jobs done. Part of the design process to create sensitivity labels is to understand what information they will likely protect and how people interact with that content. This knowledge then guides the selection of permissions to define in each label. The change in permission names is a prompt to reflect on whether the permissions for existing labels are still the best mixture of protection and usability. If not, it’s easy to adjust.

Granting Owner permission for everyone in the organization is a step on the sorry path to oversharing while restricting people to Viewer permission is likely to be overly restrictive. Restricted Editor looks like the new baseline sensitivity label permission to give everyone, with higher level permissions assigned as dictated by what interaction people need with protected documents.

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.

Sensitivity Label Downgrades and Removals Could be Potentially Suspicious User Behavior

The publication of message center notification MC934733 on November 15, 2024 (Microsoft 365 roadmap item 466742) provoked some thought. The notification is about an update to Purview Insider Risk Management, a compliance solution to detect activities that might potentially expose the organization to risks like IP theft or data leakage. The solution is part of Microsoft’s E5 Compliance Suite and is also included in Office 365 E5/Microsoft 365 E5.

In this case, the update covers the detection of risk that might be indicated if people downgrade or remove sensitivity labels from files stored in SharePoint Online sites. This kind of behavior could indicate that a user is preparing to exfiltrate files from the organization, perhaps when they leave in the near future.

By removing sensitivity labels from files, they remove the block that Microsoft Information Protection would otherwise place on people who cannot prove their right to access the files. Normally, proof is secured by authentication, which is then compared against the set of rights defined for a file. Downgrading a label can have the same effect if the chosen label allows free access to files through a right like “any authenticated user.”

The ability to remove or change a sensitivity label for a file is governed by the rights assigned to a user in a label. If the user can edit the rights for a file, they can change or remove a sensitivity label. This right is included in the co-author role that is sometimes assigned to everyone in the organization or everyone in a group.

Use the Audit Log to Track Sensitivity Label Downgrades and Removals

This kind of check is very useful, but it might not be enough for an organization to invest in license add-ons or upgrades. If your tenant has Purview Audit Standard (check this PDF for product licensing information), then you can use PowerShell to analyze the events captured in the unified audit log to track and report sensitivity label downgrades and removals.

The idea is simple. Here’s what has to happen in a script.

• Connect to Exchange Online.
• Connect to the compliance endpoint.
• Run the Get-Label cmdlet to fetch details of the sensitivity labels used with files and store them in a hash table. In fact, two hash tables are used for fast lookup. One resolves label identifiers to return label display names. The other resolves label identifiers to return the label priorities. Each label has a priority number from 0 (least sensitive) up. By comparing the priority numbers when a label update occurs, you know if the update is a downgrade or an upgrade. The audit records include a property called Sensitivitylabeleventdata.LabelEventType. This seems to store values of 1 for label upgrades, 2 for downgrades, and 3 for removed. It’s possible that Insider Risk Management uses these values to detect employees preparing to exflitrate data.
• Run the Search-UnifiedAuditLog cmdlet to look for FileSensitivityLabelRemoved and FileSensitivityLabelChanged events over whatever lookback period seems appropriate. See this article for more information about reporting sensitivity label events.
• Process each event to decide what happened and capture details in a PowerShell list.
• Do some analysis to figure out if an abnormal number of label downgrades or removals have happened and which accounts are involved.
• Report the details.

I put together a script to illustrate the principles involved in finding and analyzing the audit event information. You can download the script from GitHub. Figure 1 shows the results reported by the script when I ran it in my tenant. Clearly, the tenant administrators only have to worry about me…

Container Management Labels Are Changed Too

The sensitivity labels discussed so far are information protection labels that can apply rights management encryption to protect files. The other type are container management labels, which are used to apply settings to “containers” (teams, sites, and groups). Unhappily, just like someone can change a sensitivity label for a file, a container owner can change the assigned container management label. There’s no way for an organization to lock a label for a container.

However, you can monitor container label changes using the audit log using audit events and reapply the original label if a change is detected. The original article uses Exchange Online management PowerShell, and it’s also possible to monitor container management changes with the Graph APIs, albeit in a more complicated arrangement because of the need to store original label assignments for containers in a Graph-accessible location.

Detecting Sensitivity Label Downgrades Proves the Value of the Audit Log

Being able to track sensitivity label changes and removals for files is another example of how audit log information can prove useful for tenant administration. If you know what’s happening inside a tenant, there’s probably an audit log event captured for the action, and once you can find the audit log event, you can analyze it.

Learn about using the unified audit log and the rest of Microsoft 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.

Separate Retention Policies Coming for Teams and Copilot Compliance Records

On November 6, 2024, Microsoft issued message center notification MC926899 to inform tenants that they plan to split retention processing for compliance records created by the Microsoft 365 substrate for Teams and Microsoft 365 Copilot interactions. The current situation is that Purview Data Lifecycle management allows a single retention policy to apply to both types of compliance records. In the future, you’ll be able to have separate policies. The change is covered by Microsoft 365 roadmap item 407897.

MC926899 says that a Microsoft 365 Copilot license is required to use this feature. That statement is inaccurate insofar as administrator actions are concerned. You can configure a retention policy to process Copilot interactions without a Copilot license. The only need for a Copilot license arises when someone wants to use Copilot in apps, like Copilot in Word or Copilot in Teams.

Microsoft plans to roll out the update to public preview in mid-November 2024 with worldwide deployment in general availability following in January 2025. As always with dates for updates, some slippage can happen.

A Thoroughly Justified Change

The change is totally justified. Storing Copilot interactions alongside Teams compliance records in the hidden TeamsMessagesData folder in user mailboxes was always a short-term exercise to allow Microsoft to claim support for Purview by Microsoft 365 Copilot. Like compliance records generated for Teams messages, the records are modified versions of mail items that hold just enough information about a Copilot interaction to make the data useful for eDiscovery and compliance purposes, such as review by communication compliance policies.

But the biggest reason why this change makes sense is that organizations are likely to have radically different retention strategies for different compliance records. For instance, many organizations like to remove Teams chats after a few days (which is why Purview supports a 1-day retention period for Teams). However, throwing away Copilot interaction records after a day might not be the preferred approach. Being forced to use a single policy that enforces the same retention period to both (Figure 1) is too inflexible, and that’s why creating the ability to have a separate retention policy for Copilot is the right thing to do.

Current Retention Policies and Copilot Interactions

Microsoft hasn’t said what will happen to current retention policies that process both Teams chats and Copilot interactions. My assumption is that they will remain in place and be unaffected by the change. In other words, if you apply the same retention period to Teams and Copilot, you have nothing to do. However, if you process the two types of data together, any flaw in the retention policy settings will affect both, hopefully not to the degree experienced by KPMG in 2020.

The only work item created by the change is for organizations that want to have separate retention policies. In this scenario, administrators will need to remove Copilot interactions from the current policy and create a new policy specifically for Copilot. Unless the organization uses multiple retention policies scoped at different sets of accounts, the update should only take a few minutes.

Storage Location for Copilot Interaction Records

I don’t know yet if Microsoft plans to move the storage location. Yammer (Viva Engage) uses a separate location for its compliance records as does Planner, so it makes sense if the Copilot records move to a new folder. When it does, I’ll have to update my PowerShell script to analyze Copilot interactions and report the prompts and responses between users and apps.

The change required by the script should be straightforward. Once we know the folder where Copilot stores its interaction records, the script can use Get-ExoMailboxFolderStatistics to find the Store identifier for the folder and run some code to convert the value to a REST identifier that works with Graph API requests. At least, that’s the theory. I’ll know more when the new retention option is available in tenants.

Keep up to date with developments in Purview 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.

Microsoft 365 Substrate Captures Interaction Details for Microsoft Copilot

After writing about how to use the Microsoft Graph PowerShell SDK to analyze the interactions between users and Microsoft 365 Copilot in various apps, I was asked if the code reports interaction records for Microsoft Copilot. This is the free version of Copilot that appears in the Microsoft 365 app when a signed-in Entra ID user account doesn’t have a Microsoft 365 Copilot license.

The big difference between the free and paid-for version is that Microsoft 365 Copilot can use Graph queries to find email, Teams messages, and documents to ground its queries while Microsoft Copilot is limited to Microsoft’s LLMs and Bing web searches. In addition, Microsoft 365 Copilot comes with extra features, such as custom Copilot agents for SharePoint Online.

Both versions support enterprise data protection (EDP). Microsoft added support for EDP to Microsoft Copilot in August 2024 and the announcement specifically says that information about prompts and responses is retained for eDiscovery purposes.

Asking Microsoft Copilot

My first step to gather information was to ask Microsoft Copilot if it generates interaction compliance records. Figure 1 shows the negative response.

Looking Behind the Scenes

As Microsoft Copilot couldn’t answer the question, it was time to look behind the scenes. I figured that the Microsoft 365 substrate would store anything it captured for Microsoft Copilot interactions in the same hidden TeamsMessagesData folder in the user’s mailbox.

Some are curious why Microsoft selected TeamsMessagesData as the storage location for these records. It doesn’t really matter what folder is used if it’s hidden and indexed for eDiscovery, but I think Microsoft chose TeamsMessagesData because the Copilot chats are very much like regular Teams one-on-one chats. The substrate captures Teams compliance records for one-on-one chats in the same folder.

MFCMAPI is the best tool to investigate mailbox contents. After using Microsoft Copilot several times, I opened the TeamsMessagesData folder with MFCMAPI and discovered that the substrate had captured compliance records for the Copilot interactions. Figure 2 shows the record captured for the prompt shown in Figure 1.

Once I located the compliance records, it was easy to update the PowerShell script to extract and report the Microsoft Copilot interactions. The updated code is available from GitHub.

No Data Shown for Responses

I noticed that compliance records captured for Microsoft Copilot responses do not include the response in the Body and BodyPreview properties. The same is true for responses generated for Microsoft 365 Chat (BizChat) responses. Looking back through records for Microsoft 365 Chat interactions, it appears that the only output is any documents located by Copilot to form its response. In Figure 3, we see a reference to a document in a Microsoft 365 Chat response followed by some base 64 encoded text.

Inputting the encoded text into an online decoder reveals the text (Figure 4). It looks like whatever routine Microsoft uses to generate the compliance record doesn’t decode the text before it’s written into the mail item used to store the record in TeamsMessagesData.

The encoded state of the information also explains why the Activity Explorer in the AI Hub in the Purview portal can’t display Copilot’s response to a prompt (Figure 5).

Summarizing Microsoft Copilot and Compliance Records

The answer to the question is that compliance records are generated for Microsoft Copilot interactions. However, the information logged in the compliance records isn’t as easy to access as it should be. The flaw shared by Microsoft Copilot and Microsoft 365 chat suggests that some buggy code is shared by the two apps. It should be easy for Microsoft to decode responses from base64 before including clear text in compliance records.

The issue is reported, but quite when a fix will appear is anyone’s guess. Hopefully, because the problem means that compliance records aren’t as useful as they should be, the fix should appear soon.

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.

Use Microsoft Search to Find Emails with Sensitivity Labels

In June 2023, I wrote about how to search SharePoint Online for files with sensitivity labels. The key point is to use the InformationProtectionLabelId property in the KeyQL query in a search, passing the label identifier to search for. As described in the article, the label identifier for a sensitivity label is found by running the Get-Label cmdlet and it’s possible to search for items with several different sensitivity labels at one time.

Unfortunately, I might have inadvertently created the impression that only SharePoint Online supports searches against InformationProtectionLabelId. That’s not true because Exchange Online supports searches against the same property. It’s just not a well-known fact.

Viewing Sensitivity Label Data with MFCMAPI

When I was asked recently whether it was possible to search for email with a specific sensitivity label (for instance, all messages sent by a user labeled as Confidential), my initial action was to fire up the MFCMAPI utility to see what properties Exchange Online stores for labeled email. A bunch of properties are found, including the person who labeled the email (Drmowner) and the organization that “owns” the item from a rights management perspective. The most relevant is the MSIPLabelGuid property (Figure 1), which holds the identifier of the label.

it’s quite likely that a schema normalization process will transform the property in different ways, such as giving it a different name. That’s exactly what happens here because the MSIP (Microsoft Information Protection) Guid ends up in the item’s InformationProtectionLabelId property.

Use Microsoft Search to Find Emails with Sensitivity Labels

To test the theory, you can search for labeled emails using the search box available in the Microsoft 365 browser app. Type in InformationProtectionLabelId: followed by the identifier for the label to search for. The emails found by the search are listed under the Messages tab (Figure 2). Only labeled emails received by the signed-in account are found by this search.

Even better, because Outlook clients use the Microsoft Search index, you can find email with sensitivity labels by using the same syntax with Outlook search (Figure 3).

Use Purview Content Search to Find Emails with Sensitivity Labels

Searching from a browser only finds messages in the signed-in user’s mailbox. To find labeled emails in other mailboxes, you must use a Purview content search. Microsoft is currently in the middle of “modernizing” Purview eDiscovery, but the basic idea of creating a search with a KeyQL query to find items still holds true. In this case, I used the very simple search

informationprotectionlabelid:2fe7f66d-096a-469e-835f-595532b63560 (c:c) (Kind=email)

to look for items. Content searches find all emails, received and sent. Figure 4 shows the result.

Obviously, the query could be more complex to focus on certain mailboxes, which is where the query builder comes in useful. In fact, the query builder in the modern eDiscovery UI supports sensitivity labels as a condition, and you can add a condition to search for one or more labels very easily (Figure 5).

Interestingly, when you use the modernized query builder to add sensitivity labels as a condition for a search, the query uses MipSensitiveLabel instead of Informationprotectionlabelid, and you can end up by mixing and matching the two properties in a query like this:

informationprotectionlabelid:2fe7f66d-096a-469e-835f-595532b63560 (c:c) ((Kind=email) AND ((Date=2024-01-01..2024-10-01)) AND (((SubjectTitle:Project) OR (SubjectTitle:Important) OR (SubjectTitle:Critical))) AND (((MipSensitiveLabel=2fe7f66d-096a-469e-835f-595532b63560) OR (MipSensitiveLabel=8b652c9a-a8b7-40ec-bb1a-c5334b1b7fef) OR (MipSensitiveLabel=27451a5b-5823-4853-bcd4-2204d03ab477) OR (MipSensitiveLabel=810b94b5-8ff8-4670-ab07-3e2daeda47d2))))

Searching against the MIPSensitiveLabel property works, but the older query builder doesn’t like using an equals sign between the property and value. A semi-colon works just fine.

Several Ways to Find Emails with Sensitivity Labels

The bottom line is that you can search for emails protected by sensitivity labels (with or without encryption). eDiscovery searches are the most powerful and flexible when the need arises to find a very specific item, but Microsoft 365 search in the browser can find items too.

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.

Group Members Become the Target Set for the Adaptive Scope

Adaptive scopes are queries executed against Entra ID to find users, Microsoft 365 groups, or SharePoint sites for processing. Like dynamic groups, the idea behind adaptive scopes is that if the directory is accurate, policies like Microsoft 365 retention policies will always process the correct target set of locations without requiring administrator intervention as people, groups, and sites join or leave the organization. Adaptive scopes require Office 365 E5 or advanced compliance licenses.

All of this is well-known information. Adaptive scopes have been around since late 2021, and people have figured out by now if they want to use adaptive scopes with users and groups or SharePoint Online, with or without the extra layer of complexity that using adaptive scopes alongside administrative units can introduce.

Creating a User Adaptive Scope Based on Group Membership

Then I was asked if it was possible to create an adaptive scope based on the membership of a group. Out-of-the-box, this isn’t a supported scenario. Adaptive scopes to target user resources like mailboxes and OneDrive accounts are quite different to those targeting Microsoft 365 groups, and the query builder for a user adaptive scope doesn’t include member of a group as an option.

The logic for having a group involved is the desire to use the group for communication, either as a plain distribution group for email-based communication or a team for channel-based discussion and to control access to other resources like a SharePoint site. It makes sense to align the retention policies applied to all members of such a group, especially if the accounts share a common geography or job type.

Where there’s a will, there’s often a way. In this case, the solution is to base both the group membership and the adaptive scope on a common attribute. The best option for such an attribute is likely to be one of the fifteen custom attributes available for Entra ID accounts. The custom attributes are supported as a queryable property by dynamic distribution lists, dynamic Microsoft 365 groups, and adaptive scopes.

Populating User Accounts

To illustrate the concept, I found a custom attribute that wasn’t in use. This can be difficult because organizations use custom attributes for many different purposes and all the attributes might already be in use. If this is the case, then another common attribute is needed. For instance, the attribute could be department, office, or job title.

To populate the attribute, I found the set of target mailboxes and updated them with Set-Mailbox. For example:

Get-Mailbox -RecipientTypeDetails UserMailbox -Filter {Office -eq "New York"} | Set-Mailbox -CustomAttribute11 "Permanent Employee"

Create a Dynamic Microsoft 365 Group

Next, I created a Microsoft 365 group and used the same attribute (and same value) in the membership rule (Figure 1):

Finally, I created an adaptive scope which again checks the same attribute for the same value. Microsoft says that it can take five days for a background process to evaluate the query to find the set of target accounts. That was certainly true in the early days of adaptive scopes, but the day is more like a day now. After the background process to run the query, the set of target users is visible in the Purview portal (Figure 2).

Everything works and we have an adaptive scope whose target set of user accounts for retention processing is dictated by the membership of a dynamic group. As changes occur to user accounts, they join or leave the group and will subsequently join or leave the adaptive scope.

Stitching Stuff Together

This isn’t a particularly high-tech solution nor is any innovation present. Instead, it’s an example of combining existing features to work around an apparent functionality gap. The trick is to get to know Microsoft 365 components well enough to know how to stitch them together, and that’s an ongoing and onerous task.

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.

Announcement of New DLP Policy Tips Masked by Unclear Text

As described in message center notification MC894577 (21 Sept 2024), Microsoft plans to make some changes to the Data Loss Prevention (DLP) policy tips exposed to Outlook users. Regretfully, the text of the notification raises several questions that deserve clarification. This might happen as Microsoft rolls out the update in late October 2024. At least, let’s hope so.

The first issue is client support. The notification specifies the new Outlook for Windows but doesn’t mention OWA. Typically, any new feature now introduced for the new Outlook also turns up in OWA, if not in Outlook classic.

Microsoft has committed to support Outlook Classic until at least 2029). Enterprise customers are not rushing to adopt the new Outlook due to its functionality deficit want to see new features being delivered, especially anything related to security. What’s curious here is that Microsoft’s documentation for conditions that support policy tips for Outlook explicitly include Outlook classic in the clients due to support the new conditions. According to the documentation, you can expect to see the policy in production version 2303 & Build 16.0 16216.10000 or higher, and semi-annual channel version 2302 & Build 16.0.16130.20478 or higher.

Groups, What Groups?

The documentation also mentions that the Sender is a Member of condition is supported by Azure-based dynamic distribution groups. The other two supported group types are distribution lists and mail-enabled security groups. The three group types are Exchange Online objects and dynamic distribution groups are not found in Entra ID (or Azure AD as it was). I have no idea what Microsoft means by Azure-based dynamic distribution groups.

The Advent of Premium DLP Policy Tips

The larger issue is revealed in the warning that “any existing conditions outside this updated list, which may currently trigger Policy Tips in New Outlook, will stop working after October 18th, 2024.”The updated list is the set detailed in MC894577 and the documentation, so that’s clear. What’s not known is what existing conditions (Figure 1) will suddenly stop working on October 18.

Until now, there hasn’t been much differentiation between the DLP policy tips displayed in Outlook to accounts with Office 365 E3 licenses and those with Office 365 E5 licenses (or equivalents). This is unlike Teams, where DLP support has always required Office 365 E5 licenses.

The warning might mean that from October 18, 2024, Microsoft will differentiate between Office 365 E3 and E5 licenses when DLP decides what policy tips to display in Outlook. Even if a policy match dictates that a specific policy tip should appear, it won’t show up in Outlook unless the account has an appropriate license. The way the documentation is laid out and the clear separation of sets of policy tips into basic (E3) and premium (E5) conditions support this interpretation, as does the bald statement that “Features mentioned above are enabled based on Licenses.”

Premium DLP Policy Tips Are Another Reason for Customers to Upgrade

The text of MC894577 is unclear and misleading. Discovering that Microsoft wants to introduce premium DLP conditions isn’t surprising because it aligns with the general direction throughout Microsoft 365 to find places to introduce new functionality that requires high-end licenses. As I have noted many times. Microsoft wants to grow the annual revenue per user (ARPU) they generate from the Office 365 installed base to increase cloud revenues and profits. Increasing the ARPU by selling add-on licenses or convincing customers to move from low-price to higher-price bundles has been happening for years, but it is becoming increasingly obvious.

Updating DLP to increase the set of conditions that can indicate potential data leakage issues to users through policy tips is a good thing. Making the new conditions a premium feature is OK too, even if it makes management of DLP policies a little more complex and potentially more expensive, if you decide that the new conditions are a must-have.

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.

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 6-Dec-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 audit events retrieved from the unified audit log. It’s an interesting technique that caused me to investigate the information captured for Copilot interactions. In this context, Copilot interactions mean events generated by activity with Microsoft Copilot and Microsoft 365 Copilot.

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: 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 5000 -SessonCommand ReturnLargeSet
$Records = $Records | Sort-Object Identity -Unique
$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 assign a sensitivity label with a higher priority to an Office document or PDF than the container management sensitivity label assigned to the SharePoint Online where the file is stored.

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 Microsoft 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 and to the site owners. The notification contains details of the document which caused the problem and the label assigned to the document and to the site (Figure 1).

Although site owners can step in to downgrade the sensitivity label assigned to the highlighted document, resolving the issue should be left to the person who assigned an inappropriate label to the document. They should know the true sensitivity of its content and should be able to find a better sensitivity label to assign to the document.

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.