Decision to Use Sublabels is an Implementation Issue

One of the topics that should be discussed before the implementation of sensitivity labels in a Microsoft 365 tenant before the creation and publication of labels to users is whether to use sublabels. Take the example in Figure 1 where three sensitivity labels (General, Confidential, and Highly Confidential) are parents to sets of sublabels. The General label has two sublabels (also called child labels).

A sublabel works like a primary label and can apply protection (rights management-based encryption) to email and files. It’s not When you use sublabels, the parent label acts as a container and cannot be chosen by users to label content in applications, even if it has settings to apply protection. Only the sublabels are selectable.

The Logic Behind Using Information Protection Sublabels

The main reason to use sublabels is to create a logical structure to guide users to apply the most appropriate label to content. The logic is that the parent labels are the major entry points for users to choose from. For instance, using the structure shown in Figure 1, if the user wants to label a file that’s not personal or public, they have three options to choose from. Their knowledge about the information in the file should help them to distinguish between General, Confidential, and Highly Confidential. Once they’ve made that important decision, they then decide the degree of sensitivity of the information and apply the most appropriate sublabel.

The Logic for Avoiding Information Protection Sublabels

The argument against using sublabels is that if the implementation team isn’t careful, it is easy to create a complex structure that hinders rather than helps users make the right decision. The logic is that a simple flat list of sensitivity labels ranked from least important (at the top) to the most confidential (at the bottom) is easier for people to understand.

This approach works if users are presented with a limited number of labels to choose from. Showing six labels with carefully chosen names that clearly communicate the level of confidentiality is likely easier for users to understand and navigate than a list of fifteen labels. In international deployments, the display names for sensitivity labels can be translated into different languages. In this scenario, it’s important that the label names have the same relevance in all languages.

Deployment of Information Protection Sublabels

Creating sublabels follows the same process as creating a regular label. The big difference is the starting point. To create a sublabel, you select the parent label (which logically must be created first) and then choose the option to create a sublabel (Figure 2). Part of the creation process is to determine the priority order for sublabels within the parent label’s set, but aside from that, if you can create a regular label, you’ll have no difficulties creating a sublabel.

Like regular labels, sublabels must be deployed to end users through label publishing policies. Each policy publishes a selected set of labels to target users. If a policy includes a parent label, make sure to include all its sublabels.

The Purview compliance portal doesn’t allow regular labels to become sublabels or vice versa. However, this can be done using PowerShell. To do this, you must sign into the Exchange Online management module and then connect to the compliance endpoint to retrieve details of the sensitivity labels defined in the tenant. The important information you need is the ImmutableId, the GUID that identifies a sensitivity label. Here’s how to sign into the compliance endpoint and list the current set of sensitivity labels:

Connect-IPPSSession

Get-Label | Format-Table Name, ImmutableId

Name                             ImmutableId
----                             -----------
Public                           2fe7f66d-096a-469e-835f-595532b63560
No Encryption                    8b652c9a-a8b7-40ec-bb1a-c5334b1b7fef
Non-business use                 a49e1277-93db-4a2f-8105-43c5196b4fef

Find the label you want to be the parent and the label you want to make into a sublabel. Then run the Set-Label cmdlet to connect the two labels using their GUIDs.

Set-Label -Identity "969ca0c8-9699-4950-a943-32c1e044b546" -ParentId "d179cfc9-43d4-41b6-9ddb-3e1aaf3224c8"

Transforming a regular sensitivity label to become a sublabel changes the priority order of the label. This can lead to priority mismatches when users apply the sublabel to files stored in SharePoint Online if container management labels are used to manage sites. It’s a small point to be aware of.

To disconnect a sublabel from a parent label, run Set-Label and set the parent label identifier to $null. These commands disconnect a sublabel and resets its priority:

Set-Label -Identity "969ca0c8-9699-4950-a943-32c1e044b546" -ParentId $null
Set-Label -Identity "969ca0c8-9699-4950-a943-32c1e044b546" -Priority 30

Organizational Culture Drives the Decision

Deciding to use or avoid sublabels essentially comes down to organizational culture. Companies with a computer-literate user community might find the granular nature of sublabels easy to use where a tenant supporting less technology-oriented groups might find that a simple list of sensitivity labels is the best approach. As part of the deployment process, it’s a good test to test both approaches to see which works best.

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.

Compliance through Sensitivity Labels, Audit Events, and Compliance Records

Now that the fuss around the general availability of Microsoft 365 Copilot (November 1) is fading, organizations face the harsh reality of deciding whether to invest a minimum of $108,000 (300 Copilot licenses for a year) to test the effectiveness of an AI-based digital assistant is worthwhile. Before deploying any software, companies usually have a checklist to validate that the software is suitable for their users. The checklist might contain entries such as:

• Training available and suitable for users and administrators.
• Requisite software (like Outlook Monarch) and licenses in place.
• Users to receive licenses are identified.
• Success factors quantified and documented.
• Support for compliance technology available.

In MC686593 (updated 6 November, 2023), Microsoft addresses the last point by laying out how Purview compliance solutions support the deployment of Microsoft 365 Copilot. Rollout of the capabilities are due between now and mid-December 2023.

Sensitivity Labels Stop Microsoft 365 Copilot Using Content

Microsoft 365 Copilot depends on an abundance of user information stored in Microsoft 365 repositories like SharePoint Online and Exchange Online. With information to set context and provide the source for answering user prompts, Copilot cannot work. The possibility that Copilot might include sensitive information in its output is real, and it’s good to know that Copilot respects the protection afforded by sensitivity labels. The rule is that if a sensitivity label applied to an item allows a user at least read access, its content is available to Copilot to use when responding to prompts from that user. If the label blocks access, Copilot can’t use the item’s content.

Audit Events Record Microsoft 365 Copilot Interactions

Recent changes in the Microsoft 365 unified audit log and the surrounding ecosystem have not been good. The Search-UnifiedAuditLog cmdlet doesn’t work as it once did, a factor that might impact the way organizations extract audit data for storage in their preferred SIEM. Some will not like the removal of the classic audit search from the Purview compliance portal in favor of the asynchronous background search feature. Both changes seem to be an attempt by Microsoft to reduce the resources consumed by audit searches. This tactic is perfectly acceptable if communicated to customers. The problem is the deafening silence from Microsoft.

On a positive note, the audit log will capture events for Copilot prompts from users and the responses generated by Copilot in a new Interacted with Copilot category. These events can be searched for and analyzed using the normal audit retrieval facilities.

Compliance Records for Microsoft 365 Copilot

The Microsoft 365 substrate captures Copilot prompts and responses and stores this information as compliance records in user mailboxes, just like the substrate captures compliance records for Teams chats. Microsoft 365 retention policies for Teams chats have been expanded to process the Copilot records. If you already have a policy set up for Teams chat, it processes Copilot records too (Figure 2).

Although it’s easier for Microsoft to combine processing for Teams chats and Copilot interactions, I can see some problems. For example, some organizations like to have very short retention periods for Teams chat messages (one day is the minimum). Will the same retention period work for Copilot interactions? It would obviously be better if separate policies processed the different data types. Perhaps this will happen in the future.

Because the substrate captures Copilot interactions, the interactions are available for analysis by Communication Compliance policies. It should therefore be possible to discover if someone is using Copilot in an objectionable manner.

Block and Tackle Support for Microsoft 365 Copilot

None of this is earthshattering. SharePoint Online stores protected documents in clear to support indexing, but it would be silly if Microsoft 365 Copilot could use protected documents in its response. Gathering audit events treats Copilot like all the other workloads, and compliance records make sure that eDiscovery investigations can include Copilot interactions in their work. However, it’s nice that Microsoft has done the work to make sure that organizations can mark the compliance item on deployment checklists as complete.

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 Container Management Sensitivity Labels to Force Specific Teams Privacy Mode

Yesterday, I wrote about how to control the creation of Microsoft 365 groups (and teams) using Microsoft Graph PowerShell SDK cmdlets to update the directory object setting used for the tenant groups policy. This led to a question from a reader who referred to a Microsoft Technical Community discussion about how to force those allowed to create new teams to only create private groups. A private team is one where the team owners control the membership. By contrast, anyone can join a public team.

I’m not quite sure why this is any better than allowing people to have a choice between private and public (Figure 1) in terms of preventing group sprawl, but it is an interesting example of using sensitivity labels for container management.

The technique outlined here only affects new groups created through Teams, Outlook, OWA, and SharePoint Online clients. It doesn’t affect existing groups nor will it stop an administrator creating a new public group through an administrative interface like PowerShell or the Graph APIs.

Implementing the Block on Public Teams

The steps to block new public teams starts with creating or selecting a container management sensitivity label (one that exerts control over teams, groups, and SharePoint sites). I have a well-populated set of sensitivity labels in my tenant, so I choose to use one called Confidential Access.

It’s critical that the privacy settings for the label dictate that groups and teams assigned the label can only have private access (Figure 2).

Next, create a label policy to publish the selected label to selected users. For instance, you could decide to publish the policy to the same users who are allowed to create new groups or limit publication to a subset. Unfortunately, you can’t choose a security group for the target set, so you’ll need to include each user separately (Figure 3) or use a Microsoft 365 group or distribution list to establish the scope for the policy.

Make sure that the label policy requires users to apply a default label to sites and groups. Because only one label is covered by the policy, this is the only one that can be assigned by default (Figure 4).

Make sure that the label policy has the highest priority so that it takes precedence over any other label publishing policy. This is the usual state for the most recently-created label policy but it’s wise to check and adjust if necessary.

Wait for Effect

Publication is not immediate. Behind the scenes, Microsoft Purview processes the new label publishing policy and makes the label available to the target set of users. It could take up to 24 hours before the user account and relevant applications learn about the new policy and its settings.

When the label policy is in force, the dialog to create a new team prepopulates the sensitivity label with the default label specified in the policy. Because the label specifies that private access is the only permitted option, this action disables the choice of public access (Figure 5).

Changing Other Teams to Private Access

As mentioned above, implementing a sensitivity label for container management in the manner explained here does nothing to existing teams. If you want to make all teams private, you must search for teams with public access and update them to private access. Here’s some based on the Microsoft Graph PowerShell SDK to do the job.

Connect-MgGraph -Scopes Group.ReadWrite.All
[array]$Teams = Get-MgGroup -Filter "resourceProvisioningOptions/any(x:x eq 'Team')" | Where-Object {$_.Visibility -eq 'Public'} | Sort-Object DisplayName
If ($Teams) {
   Write-Host ("Processing {0} teams with public access..." -f $Teams.count)
}
ForEach ($Team in $Teams) {
   Write-Host ("Updating team {0} to private access..." -f $Team.DisplayName)
   Update-MgGroup -GroupId $Team.Id -Visibility 'Private' 
}

I’m still unconvinced that forcing all teams to be private will address the problems of group sprawl, or unused and obsolete teams. But it’s an interesting approach. Maybe it’ll work for you.

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.

No Good Reason why SharePoint Limits Administrator Access to Document Libraries

A reader asked if a programmatic method exists to set the default sensitivity label for a SharePoint Online document library. The simple answer is “yes,” because the only way initially available to set a default sensitivity label when the feature was in preview was to use the SharePoint REST API. Microsoft subsequently updated the SharePoint browser GUI to allow site owners to set a default sensitivity label for a document library.

Using the REST API still works, but my reader wanted something like a nice simple PowerShell cmdlet. Something like this would be nice:

Set-SpoSite -Identity $SiteURL -DocumentLibrary "Documents" -DefaultSensitivityLabel c29e68f9-bc4f-413b-a741-6db8e38ad1c6

The command would be nicer if you could pass the name of a sensitivity label, but the display names for sensitivity labels can be translated into multiple languages, which might cause some issues in multilingual tenants.

In any case, the Set-SPOSite cmdlet doesn’t support the functionality today and I haven’t heard of any plans to change in this area.

Reasonable to Allow Administrator Access to Some SharePoint Online User Data

I think it’s perfectly reasonable for SharePoint Online administrators to be able to update the default sensitivity labels for document libraries, especially because assigning a default sensitivity label incurs the requirement for Syntex-SharePoint advanced management licenses. An unwitting site owner could decide to assign a default sensitivity label to a document library (Figure 1) without realizing that the organization is now on the hook for some licenses, and that’s not a good thing. SharePoint administrators should be able to review, assign, and remove default sensitivity labels.

But this stance goes against the general approach Microsoft takes to SharePoint Online administration which holds that administrators can operate at the site level but cannot interact with objects within the site. Apparently, a site can have up to 255 document libraries, all of which are invisible to SharePoint administrators unless they’re a member of the site.

I understand the perspective that drives the approach. Administrators shouldn’t have access to user data. However, while Exchange Online administrators can see the folders inside user and shared mailboxes and Teams administrators can remove user data such as chat threads. It’s also possible for administrators to analyze and report the tasks in Planner plans. And sometimes even SharePoint Online administrators can take action with user data, like removing the sensitivity label for protected files using the Unlock-SPOSensitivityLabelEncryptedFile cmdlet. Inconsistency is rife across the Microsoft 365 workloads.

Greater Flexibility Required

I’m not advocating for SharePoint Online administrators to be able to open and examine documents and other files held in document libraries. The ability to report the contents of document libraries is already possible, albeit with some effort. What I would like to see is greater access to document library settings through PowerShell or a Graph API (which means that PowerShell support becomes available through the Microsoft Graph PowerShell SDK). For instance, why shouldn’t an administrator be able to do this to create a simple listing of all files found in the document libraries for a site:

$DocumentLibraries = Get-SpoSite -Identity $SiteUrl -DocumentLibraries
ForEach ($DL in $DocumentLibraries) {
   $Documents = Get-SPODocumentLibrary -Identity $DL 
   ForEach ($Doc in $Documents) {
    Write-Host (“Document found {0} in folder {1}” -f $Doc.Title, $Doc.Folder)
  }
}

SharePoint Online is not the center of its own universe as is the case with on-premises SharePoint Server. SharePoint Online is a highly capable document management service that’s consumed by other Microsoft 365 workloads. As such, its administrative capabilities should be on a par with other workloads, and that means greater flexibility and access to the settings for document libraries. Being able to report, configure, and remove the default sensitivity label for a document library is just the start.

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.

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.

AES256-CBC Will Protect Office Documents and Email

Last year, some researchers expressed worries that the AES 128 ECB (Electronic Cookbook Mode) cipher used by Microsoft Information Protection to encrypt documents and emails could be compromised. Microsoft uses the cipher to ensure backward compatibility with older Office versions.

The need for backward compatibility appears to have lifted. Announced in MC590144 (June 15, 2023, Microsoft 365 roadmap item 117576), Microsoft Information Protection will start using AES 256 in Cipher Block Chaining (AES256-CBC) mode from late August 2023 with full deployment expected by the end of September 2023.

Sensitivity Labels Apply Better Protection

In practical terms, if you apply a sensitivity label (Figure 1) to an Office document, export an Office document to a PDF, or email (including meetings), or use the Purview Message Encryption feature (previously Office 365 message encryption or OME) to set Do Not Forward or Encrypt-Only for emails, the level of encryption protecting those items will increase. Items previously protected will receive the upgraded protection the next time the items go through an encryption/decryption cycle. For instance, if someone edits a protected document stored in a SharePoint Online document library, SharePoint will apply the improved encryption when it saves the file. Full details are available in this Microsoft Technology Community post.

Enhanced protection is available in the Microsoft 365 apps for enterprise, SharePoint Online, Exchange Online, Purview Message Encryption, the Azure Information Protection (AIP) unified labelling client (version 2.17 or later), AIP PowerShell module (2.17 and later), and the Purview Information Protection Scanner for on-premises repositories.

Third-party applications built using the Microsoft Information Protection SDK 1.13 or later support items protected with AES256-CBC. This includes the paid-for versions of Adobe Acrobat that can apply and manage sensitivity labels. It might take a little time for ISVs to issue upgraded versions of their products that support AES256-CBC.

Impact on Four Groups

Although the transition to AES256-CBC should be seamless for Microsoft 365 tenants, Microsoft calls out four groups of customers that the change will impact. These are organizations:

• Using the subscription version of Office (Microsoft 365 apps for enterprise) with Exchange Server (on-premises or hybrid). The Exchange development group is working on a patch to allow Exchange Server to support AES256-CBC that should be available in July. However, the patch will only be available for Exchange Servers with support, so that means the latest versions of Exchange 2016 and Exchange 2019. Microsoft will automatically exclude organizations using the Azure Rights Management connector from using AES256-CBC until January 2024 to allow them time to apply server upgrades.
• With applications built using the Microsoft Information Protection SDK. These organizations must upgrade their applications to V1.13 of the SDK.
• Using perpetual versions of Office (2016, 2019, and 2021 LTSC). These versions can consume items protected with AES256-CBC, but some work is needed to allow clients to create items protected with the new cipher.
• Using the current version of the AIP Viewer, PowerShell module, or Scanner. Workstations need to upgrade to the latest version of the unified labeling client to enable support for AES256-CBC for components installed by the client.

Failure to take action to upgrade installations before Microsoft rolls out the change in August 2023 will result in Exchange Server failing to decrypt protected email. More details are available in Microsoft’s Technical community post.

Moving to Stronger Encryption

Even if the potential for compromise required attackers to follow an unlikely path, Microsoft has answered the doubts expressed by researchers with this update. That’s a welcome change that will kick in during August 2023. Users shouldn’t be aware of the transition and won’t be impacted by the change if administrators of the highlighted organizations take action.

For more information about the transition to AES256-CBC, see Microsoft’s documentation.

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.

Making Plans to Introduce Sensitivity Labels for Meetings

I previously wrote about how sensitivity labels protect meetings created in Outlook and OWA and the way that labels can apply settings to Teams meetings, if meeting organizers have Teams Premium licenses. In that article, I said that introducing sensitivity labels for meetings requires up-front planning. This article discusses some of the topics that such a planning exercise might cover.

Label Scoping

Scoping defines to what objects applications can apply labels. In the past, the split was simple: information protection (encryption) for files and emails or container management for groups, sites, and teams. The introduction of meetings and a recent update to introduce separate scopes for emails and files (MC514980, updated 3 Mar 2023, Microsoft 365 roadmap item 99939) means that things are a tad more complex now (Figure 1).

Looking at the options to define the scope for a sensitivity label, you can select the following for items:

• Emails: Labels are only available to Outlook clients.
• Files: Labels are available in Word, PowerPoint, and Excel (Online, subscription, and mobile). These labels are also assignable to PDFs by the Adobe Acrobat paid-for products (or by export from Office) and to files stored outside Office 365 by the AIP extension for Windows Explorer.
• Meetings: Labels are available for meetings created in Outlook and OWA and the Teams desktop and browser clients. Because meetings include elements of email (meeting notifications and responses) and files (attachments), if you select this option, you must also enable the label for Emails and Files.

In the past, I have recommended having separate sets of sensitivity labels for information protection and container management. I think this approach leads to easier management because labels serve one purpose. The question now is should we have separate labels for meetings?

It’s a harder question to answer because meetings require files and emails. If Microsoft had created a scope for meetings that implicitly includes files and emails but didn’t display these labels for users to apply to email and documents, then I’d say yes. Because they didn’t, any label created for meetings is also available for email and documents, so we need a different approach to guide users.

Label Naming

The obvious answer is the display name assigned to sensitivity labels for meetings. By including “Meeting” in some form in the display name of labels created to protect meetings, hopefully people will use the labels for their intended purpose and not to label documents and emails.

To start, we might create a limited set of sensitivity labels for meetings:

• Public (no protection – label is for visual marking only).
• Internal meeting (protection limits editor access to tenant members).
• External meeting (protection limits access to anyone who can authenticate against Azure AD).

As time goes by and experience develops, the need might emerge for other labels. For example, if the finance and legal departments work with external advisors, the organization might decide to create sensitivity labels for their meetings with a label policy to publish the labels to users in those departments. The protection in these labels could assign co-editor permission to people in the domains owned by the external advisors to allow them to edit documents shared in meetings.

You can create display names for sensitivity labels with a maximum of 64 characters (excluding % \ & < > | ? : and ;), so plenty of room exists for innovative naming schemes. Just remember some basic facts about labeling:

• Applications have limited space to display label names (especially mobile apps).
• If you create a wide range of sensitivity labels for different scopes, users might have difficulty deciding upon the most appropriate label to apply to items.

Figure 2 shows the effect of scoping and naming, Only four sensitivity labels in the tenant are scoped for meetings. Each has a name that is clear in its purpose (the Very Secret label is a little tongue in cheek; Confidential would be a better name). A checkmark appears beside the Internal meeting label, meaning that it is the selected label. When a label is automatically selected for new meetings, it’s because it is the default label for meetings selected in the sensitivity label policy published to this account.

Keep It Simple

Keeping it simple is key. Use scoping to make sure that applications make appropriate sensitivity labels to users. Give the labels clear and understandable names. If necessary, translate the display names of labels for use in multinational organizations. Follow those two simple rules with the sensitivity labels used for meetings and users should be happy.

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.

Teams Meeting Templates are part of Teams Premium

Now that Microsoft considers Teams Premium to be generally available, it’s appropriate to investigate some of the functionality enabled by the new product to see if it’s worth the $10/month/user fee. In The 30-day trial license for Teams Premium remains available.

Microsoft has introductory pricing for Teams Premium of $7/month/user until June 30, 2023, possibly because some of the features aren’t yet available. For example, branded meetings won’t be available until mid-February and the much-hyped intelligent meeting recap powered by GPT 3.5 is scheduled for sometime in the second quarter of 2023. Given the delay, you might want to wait before testing.

Managing Teams Meeting Templates

Meeting templates are available now. These are essentially policies to apply to meetings to control settings that are otherwise set by the meeting organizer. The idea is to speed up meeting creation by using templates. A new meeting inherits options from the template used.

Management of meeting templates is through the Meetings section of the Teams admin center. Figure 1 shows that the organization has four custom templates and one default (for virtual appointments).

The process of creating and editing templates proceeds in the same way as managing other Teams objects. The only odd thing I encountered is the ability to create meeting templates with duplicate names. Although each template has a unique identifier, having multiple templates with the same display name is likely to confuse users.

Meeting Templates and Sensitivity Labels

When you create a new meeting template, you can set values for a range of meeting options, including using a sensitivity label. You don’t have to choose a sensitivity label, but if you do, the template inherits settings from the label and locks them against change (Figure 2), meaning that meeting organizers cannot change these settings for individual meetings. You can also lock settings in templates that don’t use a sensitivity label.

The control a sensitivity label exerts over a meeting template is similar to the way sensitivity labels manage containers (sites, teams, and groups). Using a sensitivity label in a meeting template does not mean that Microsoft Information Protection will encrypt the meeting and its associated artifacts (attached files, attendance report, and so on).

Configuring Sensitivity Labels for Teams Meeting Templates

Before a sensitivity label can be used with a meeting template, administrators must configure it with Teams settings (Figure 3). These are the settings inherited by a meeting template from the sensitivity label.

Sensitivity labels with Teams settings are tagged with “meetings” when listed in the Information Protection section of the Microsoft Purview Compliance portal. If you want, you can find the set of labels available for Teams by running this PowerShell snippet:

Connect-IPPSSession
[array]$Labels = Get-Label
$TeamsLabels = [System.Collections.Generic.List[Object]]::new() 
ForEach ($Label in $Labels) { 
    If ($Label.ContentType -Like "*Teamwork*") { # It's a label for Teams
      $DataLine = [PSCustomObject] @{
        LabelId     = $Label.ImmutableId
        DisplayName = $Label.DisplayName
        Priority    = $Label.Priority } 
      $TeamsLabels.Add($DataLine) } 
}
$Output = $ContainerLabels.DisplayName -Join ", "
Write-Output ("These labels support Teams Meetings {0}:" -f $Output)

Meeting Template Policy

Users gain access to meeting templates through the meeting template policy assigned to their accounts. The default meeting template policy for the organization allows access to all templates, but you can create policies to restrict access to specific templates. For example, you could have a policy allowing access to a set of templates that’s assigned to members of a certain department.

When planning meeting templates and the policies used to publish templates to users, it’s a good idea to focus on a scheme that gives users an appropriate amount of choice. If you use a single policy to publish 10 templates to users, people might find it difficult to select the right template for a meeting. Three or four templates is a practical number to aim for.

Creating Meetings from a Template

To create a meeting from a template, select the template from the list revealed by the down arrow beside the New meeting button (Figure 4). Teams creates a new meeting and populates its options from the template settings.

Apart from the number of templates shown here, the importance of good template names becomes apparent. For instance, what’s the difference between a confidence meeting and a secure meeting or a private meeting? Differences may well exist in terms of the settings meetings inherit from each template, but it’s hard for users to differentiate between the templates.

Meetings created using templates have their options set. The options that the organizer cannot change have a lock icon to indicate their status (Figure 5). Other options can be amended as usual.

Apart from having predetermined options, meetings created from templates work in the same way as do regular meetings.

The Promise of Templates

Microsoft says that meeting templates reduce “the time and thought process it takes to create and get the meeting right.” And “With templates, leaders can ensure that their meetings adhere to company best practices and policies.” I never expended too many brain cells when creating Teams meetings in the past, but I see value in applying standards to specific types of meetings. Whether that’s worth the extra license fees is a different matter. But I suspect that meeting templates will not be the key functionality that justifies an organization buying Teams Premium.

Keep up to date with developments like Teams meeting templates 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.

Understanding Who Does What with Sensitivity Labels

The Activity explorer is in the Data Classification section of the Microsoft Purview Compliance portal. Its intention is to allow tenant and compliance administrators to understand how users apply retention and sensitivity labels to files and messages over the last 30 days. The Activity explorer also surfaces retention label usage and DLP activities, but in this discussion, we focus on analyzing the use of sensitivity labels.

The information presented in the Activity Explorer comes from the unified audit log. Microsoft’s documentation says that extraction “transforms” the audit data. In other words, Activity Explorer extracts the relevant information from the audit event payloads and presents the data in a more accessible form along with a set of filters to cut and dice the data in whatever way you want.

Good as the Activity Explorer UX might be, it’s not a tool to perform any in-depth analysis of audit data relating to sensitivity labels, especially when the volume of events generated daily grows. In this article, I explain how to extract the audit payload information for events relevant to user application of sensitivity labels to documents and messages and answer questions like who applies sensitivity labels and what labels they use.

I’ve been down this path before to explore the audit events generated for sensitivity labels after Microsoft introduced the feature in early 2021. Time moves on and changes happen, so it was time to write a new script (available from GitHub) to demonstrate the principle of analyzing sensitivity label audit records. Feel free to expand its code to meet your needs.

Fetching Sensitivity Label Data

Many audit events related to sensitivity labels hold the immutable identifier for the label rather than its display name. To find the set of labels in the tenant, connect to the compliance endpoint with Connect-IPPSSession and run the Get-Label cmdlet. To make it convenient to convert an identifier to the label name, put the results in a hash table.

Write-Host "Retrieving sensitivity labels used in the tenant"
$Labels = @{}
[array]$LabelSet = Get-Label | Select-Object ImmutableId, DisplayName
If (!($LabelSet)) { Write-Host "Can't find any sensitivity labels - exiting"; break }
ForEach ($L in $LabelSet) { $Labels.Add([string]$L.ImmutableId, [string]$L.DisplayName) }

Fetching Audit Data

The next step is to retrieve relevant audit records from the audit log. This code:

• Declares the set of audit operations to fetch.
• Sets start and end dates for the audit log search. Office 365 E3 tenants can go back 90 days while Office 365 E5 tenants can fetch data for the last year.  Depending on the volume of audit events generated in your tenant, you might need to reduce the timespan for the search.
• Calls the Search-UnifiedAuditLog cmdlet to perform the audit log search.
• Removes any DLP events returned by the search. If a DLP policy applies a sensitivity label to an email message, Exchange also logs an MIPLabel event. The script only needs to process one event, so it drops the DLP events.

$Operations = ("SensitivityLabelUpdated", "SensitivityLabelApplied", "FileSensitivityLabelApplied", "MIPLabel")
$StartDate = (Get-Date).AddDays(-90)
$EndDate = (Get-Date).AddDays(1)
[Array]$Records = Search-UnifiedAuditLog -StartDate $StartDate -EndDate $EndDate -Formatted -ResultSize 5000 -Operations $Operations
If (!($Records)) { Write-Host "No audit records for sensitivity label application found - exiting" ; break }

$Records = $Records | Where-Object {$_.RecordType -ne "ComplianceDLPExchange"}

Analyzing Audit Data

Every audit record has a payload in a JSON-formatted property called AuditData. Although some of the important properties for an audit event, such as the user, operation, and timestamp, are available without going near AuditData, to extract details of the action captured in an audit record, the code must convert AuditData.

After converting AuditData, a Switch statement processes audit records for the different operations. For instance, here’s what happens for a SensitivityLabelApplied event:

    "SensitivityLabelApplied" {
     $Type = "Label assigned by user"
     $LabelAdded = $Labels[$AuditData.SensitivityLabelEventData.SensitivityLabelId]
     $Application = $AuditData.Application
     $ObjectId = [System.Web.HttpUtility]::UrlDecode($AuditData.ObjectId)
     $Item = $ObjectId.Split('/')[-1]	
     $Site = "https://" + $ObjectId.Split("/")[2] + "/sites/" + $ObjectId.Split("/")[4] + "/"
    }

Before writing out details of an audit event, the code checks if the user noted is one of the special SharePoint accounts. In addition to manual user application of a sensitivity label to an Office document or PDF file, the system can assign labels through an auto-label policy or if an administrator defines a default sensitivity label for a document library. To highlight these operations, the code updates the type property for the report.

If ($UserId -eq "app@sharepoint") {
     $Type = "Default label applied by document library" 
 } ElseIf ($UserId -eq "SHAREPOINT\system") { 
   $Type = "Label applied by auto-label policy" } 

Assigning sensitivity labels as the default for a document library or through an auto-label policy requires Office 365 E5 or Microsoft 365 Compliance E5 licenses. See Microsoft’s compliance licensing guidelines or the PDF download specifying Purview features and licensing requirements.

Reporting the Data

After processing each audit record, the code updates a PowerShell list containing the report output. As usual, you can do whatever you want with the data. To answer the questions posed above, I used the Group-Object cmdlet to generate this result:

Most commonly used sensitivity labels
-------------------------------------

Name                  Count
----                  -----
Public                  109
Confidential             33
Internal                 15
Eyes Only                 5
Sensitive Stuff           3
Black Matter              3
No Encryption             1
Secret                    1
Market Sensitive          1

Given that the Public label is the default for the document library I use to hold blog posts, it’s not surprising that it’s at the top of the list. When reviewing who applied sensitivity labels (Figure 1), it was no surprise that that my account came in on top. I also found non-tenant users listed among those who applied labels. This can happen if the tenant has a mail flow rule that applies sensitivity labels to inbound messages.

Exporting Activity Explorer Data

If you’re interested in a more general export of the data used by the Activity Explorer, Microsoft released the Export-ActivityExplorerData cmdlet to general availability in October 2022. It’s not the most elegant cmdlet available in the Exchange Online management module (V3.0 or later), but it might do a job for you. For more information, Vasil Michev covers the Export-ActivityExplorerData cmdlet on his blog.

No Consistency in Audit Payloads

It would be nice if Microsoft 365 engineering groups all generated the same kind of content in audit records. The basics of audit records are consistent, but the information inserted into the audit payload varies dramatically across workloads. The lack of consistency means that those who want to interrogate the audit log to extract information (including the Activity Explorer) must jump through hoops to get what they need. That’s a real pity because it makes the audit log a less accessible asset for tenant administrators.

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.

But What the Two Products Will Deliver is Very Different

Among the features listed by Microsoft at the launch of the Teams Premium product at Ignite 2022 are sensitivity label support for Teams meetings and intelligent meeting recap. Sounds good, but then the Outlook team revealed that they will ship sensitivity support for Outlook meetings and a meeting recap feature among the set of new capabilities planned to be available to targeted release customers before the end of 2022.

The Teams Premium product is currently slated to cost $10 user/month, yet Outlook appears to be about to deliver the same functionality at zero cost. Does that make sense? Actually, it does, but in a weird kind of way.

Teams and the Exchange Calendar

Teams depends on Exchange for its calendar. The Teams calendar app is built on top of the Exchange calendar, which handles the scheduling of meetings. Teams uses a deeplink to connect the scheduled events in the Exchange calendar to the online space used to host meetings. As far as Exchange is concerned, it delivers a scheduling capability for meetings and nothing more. What happens to extend that basic functionality is entirely under the control of the app that creates the extension. This is how Teams handles features like meeting roles, the lobby, and so on.

Outlook, Teams, Meetings, and Sensitivity Labels

Outlook will “provide the capability to apply sensitivity labels to meeting invites and protect them too. ” In other words, Outlook will allow organizers to apply a sensitivity label to a meeting and the protection assigned by the label will apply to meeting artifacts, like attachments.

The Teams description focuses more on the automatic application of sensitivity labels (an Office 365 E5 feature) “to apply relevant meeting options automatically.” Apart from the automatic application of labels, the assignment of meeting options is a capability like the way that containers (Teams, Groups, and Sites) inherit settings like privacy and guest user access from sensitivity labels.

It therefore appears that Outlook will extend the existing method of protecting messages with sensitivity labels to cover meeting invitations. Teams Premium will inherit settings from sensitivity labels to make sure that critical meetings and all the artifacts associated with the meeting are properly protected.

Meeting Recaps

Outlook’s definition of meeting recap is that “users have new discoverability and productivity features to easily find and access information about a meeting including files, transcript, and the recording directly from the calendar event in Outlook.” The screen shot for Outlook meeting recap posted by Microsoft shows how users can click a View meeting recap link in meeting properties to see the meeting transcript and other information. It’s a nice way to catch up with what happens during a meeting.

Teams Premium applies Artificial Intelligence to derive more value from the same meeting data. Microsoft says that “intelligent recap uses AI to suggest action items and owners” and “After the meeting, intelligent recap will create smarter recordings with automatically generated chapters and insights such as when your name was mentioned, when a screen was shared, or when you left a meeting early.” This is a more proactive and expansive use of information gathered during a meeting.

Of course, whether users will like Teams suggesting action items and owners automatically is quite another matter. And adding automatically generated chapters (markers) to the video recordings of Teams meetings is only useful if someone actually goes back to review the recording. As we know from the data Microsoft shared when they introduced the auto-expiration feature for Teams meeting recordings, relatively few people consult a meeting recording after it is stored and available to participants.

Confusing Naming

It would be nice if Microsoft product groups didn’t use the same terms for very different features. The bottom line is that the public information revealed by Microsoft to date indicates that Outlook will deliver support for sensitivity labels for meeting items and a basic meeting recap. Teams Premium uses more from Microsoft’s bag of AI tricks to introduce intelligence into understanding what meeting data means and how it could be better used. Of course, all of this could change before the software is generally available, so final judgment must be reserved until we see the Outlook and Teams Premium implementations in real-life scenarios.

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.

Azure AD Admin Center Doesn’t Respect Sensitivity Label Settings

Last June, I tested the preview of nested dynamic Azure AD groups and encountered an odd “Per label policy, the selected visibility is not allowed” error when attempting to create new groups in the Azure AD admin center. Pressure of time forced me to ignore the problem and create the groups I wanted with PowerShell, but time allowed me this week to return to the problem.

It didn’t take long to reproduce the problem and track down the root cause (Figure 1).

Visibility Set to Private for New Microsoft 365 Groups

I used the Graph X-Ray tool to look at the PowerShell generated by the Azure AD admin center when it adds new Microsoft 365 groups. Here’s what Graph X-ray reported:

$params = @{
	DisplayName = "Viva Topics Management"
	MailEnabled = $true
	SecurityEnabled = $true
	GroupTypes = @(
		"Unified"
	)
	Description = "People who manage Viva Topics"
	MailNickname = "VivaTopicsManagement"
	AssignedLabels = @(
		@{
			LabelId = "e42fd42e-7240-4df0-9d8f-d14658bcf7ce"
		}
	)
	Visibility = "private" }}

I copied the command and ran it interactively and saw this error:

New-MgGroup -BodyParameter $params
New-MgGroup : Property visibility is not compliant with the assigned label.
At line:18 char:1
+ New-MgGroup -BodyParameter $params
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: ({ body = Micros...ftGraphGroup1 }:<>f__AnonymousType1`1) [New-MgGroup
   _Create1], RestException`1
    + FullyQualifiedErrorId : Request_BadRequest,Microsoft.Graph.PowerShell.Cmdlets.NewMgGroup_Create1

Changing the command to set the visibility property in the parameters to “Public” allowed the command to run successfully and create the group. This is what I expected because the container management settings for the sensitivity label chosen for the new group sets its visibility to Public.

The root cause is that the command generated by the Azure AD admin center sets the access type for the new group incorrectly. Instead of reading the group’s access type (visibility) from the sensitivity label, the command uses “Private” for the value. This means that the command works for any group created with a sensitivity label that sets the access type to Private but fails for public groups.

The Azure AD admin center UI doesn’t include a field to allow the visibility to be selected for a new group, so some overhaul of the UI is needed to display the visibility inherited when a sensitivity label is selected. In addition, Microsoft’s documentation for creating a new group in the Azure AD admin center doesn’t mention visibility at all, so there’s no hope in interpreting the error message.

Inconsistent Microsoft 365 Group Management

I’m unsure of how many new Microsoft 365 groups are created in the Azure AD admin center. My feeling is that most administrators create new groups through the Microsoft 365 admin center or a workload-specific portal like the Teams admin center or SharePoint Online admin center, or even a client like OWA or Teams. All these interfaces (and PowerShell) respect the container management controls imposed by sensitivity labels. If the Azure AD admin center was heavily used, I’m sure Microsoft would have heard about the problem before I reported it on August 15.

In any case, this is not the only example of inconsistency between the Azure AD admin center and the workload portals. Take the security enabled property for a group. This is set to $True by the Azure AD admin center and $False by the Microsoft 365 admin center. That doesn’t sound too serious, but it means that groups not created in the Azure AD admin center can’t be used for purposes like group-based license management. This is where you manage license assignments by allocating them to members of a group. It’s a convenient way to manage licenses (Figure 2).

The security enabled property isn’t exposed in the Azure AD admin center UI, so if you want to update a group to make it available for group-based license management, you need to use PowerShell. The steps are simple using the group management cmdlets from the Microsoft Graph PowerShell SDK. The first command finds the group to use. The second updates its SecurityEnabled property.

$Group = (Get-MgGroup -Filter "DisplayName eq 'HR Working Group'")
Update-MgGroup -GroupId $Group.Id -SecurityEnabled:$True

After the Update-MgGroup cmdlet runs, you should be able to use the group for group-based license management.

Small But Irritating Issues

Neither of the issues described here are earthshattering. Both can be worked around by competent tenant administrators who understand how Microsoft 365 works. The problem is that issues like this cause grief to inexperienced administrators and complicate the learning curve for cloud services. That’s a great pity.

Learn more about how the Office 365 applications really work 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.

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.

The Long Road to Progress

Sensitivity labels do an excellent job of protecting Office documents, largely because the applications include the necessary code to apply and access encrypted documents. The situation is less successful when dealing with other common business file formats (like protected PDFs). The now-almost obsolete unified labeling client contains an Explorer extension that allows users to Classify and protect files. This approach works for some file types (like the MP4 files generated by Teams meeting recordings), but needs to be tested to ensure that it works and is usable for other kinds of files.

Things would be much better if maintainers of file types incorporated code from the Microsoft Information Protection (MIP) SDK into their products. For example, Adobe PDF is a very common file format used for business purposes. In December 2018, Adobe and Microsoft announced the availability of an integration of MIP with Adobe Acrobat Reader. Essentially, Adobe added code to support the opening of protected PDFs using a plug-in created by Microsoft.

Edge and Protected PDFs

In 2020, Microsoft upgraded the Edge browser to open protected PDFs. This made life easier because Edge can use cached credentials (from accessing other Microsoft 365 apps like OWA or OneDrive for Business) to validate a user’s identity and establish their rights to access protected content.

One issue that continues with Edge is that although it displays a banner to inform the user that they’re accessing a protected PDF, it doesn’t reveal the name of the sensitivity label (Figure 1). By comparison, Adobe Acrobat Reader DC displays the label when it opens a protected PDF (Figure 2).

Considering their tendency to throw the kitchen sink into Edge in terms of new features, it’s a curious omission on the part of the Edge developers.

On small point: since the launch of the MIP plug-in for Adobe, a registry value controls the display of the information bar for sensitivity labels. Originally, it was necessary to have a single DWORD value called bShowDMB set to 1 at HKEY_CURRENT_USER\SOFTWARE\Adobe\Acrobat Reader\DC\MicrosoftAIP to expose the information bar.

For whatever reason, with the latest update, Adobe appears to have moved the value to HKEY_CURRENT_USER\SOFTWARE\Adobe\Adobe Acrobat\DC\MicrosoftAIP. Or maybe the value needs to exist in both locations. My PC currently only has bShowDMB set at Adobe Acrobat\DC\MicrosoftAIP and everything is working.

Issues with Protected PDFs

Although it became less difficult to open protected PDFs, two issues remained:

• Microsoft deprecated the unified labeling client. Its strategy is to build native MIP support into applications instead of depending on a separate client. The unified labeling client is now in maintenance mode.
• Having to download and install a separate MIP plug-in for Adobe Acrobat is a separate administrative operation that users often overlook. This leads to frustration when they can’t access protected PDFs.

Another issue is that you can’t apply sensitivity labels to items stored in SharePoint Online or OneDrive for Business through the browser GUIs. This doesn’t matter so much for Office documents because sensitivity label support is available in the application. However, it means that if you want to protect PDFs, you must apply sensitivity labels using the unified labeling client before uploading the PDFs to Office 365. This action requires users to have Azure Information Protection licenses.

Improving Sensitivity Label Support for PDFs

Help is on the horizon. Three developments are coming together to make protected PDFs easier to generate and use.

• The latest Office Insider build includes the ability to output protected PDFs when saving, exporting, or sharing Office documents with sensitivity labels. The output PDFs inherit the same protection as applied to the source documents. Some gotchas exist, like the need for developers of PDF add-ins to potentially update their code and the inability to retain protection when printing to PDF. Even so, this is a big step forward because it removes the need to use the unified labeling client to apply a sensitivity label to protect PDFs.
• The latest version of Adobe Acrobat Reader DC (version 22.001.20142 and later) bundles the MIP plug-in with its installer, removing the need for a separate installation. The benefit of hindsight is that bundling the plug-in is something that Adobe probably should have done sooner.
• Microsoft 365 roadmap item 93331 (due in preview in June with general availability in October 2022) describes an integration with Adobe Acrobat to allow users to apply sensitivity labels within the application on Windows and macOS. Apparently, this covers the paid-for versions of Acrobat rather than the free reader, but it’s still an improvement. (update: the integration is now available)

While the Office update is the most important, collectively, these changes will make it much easier to create protected PDFs.

Keep up to date with developments like changes in sensitivity labels and Office 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.

Public Preview Available Now

Message center notification MC337330 (February 28) announces co-authoring for protected documents on both iOS and Android mobile devices. Microsoft 365 roadmap item 88512 explains the new feature as “Multiple authors can edit labelled and protected documents in Word, Excel, and PowerPoint simultaneously, frictionless, and with auto-save, as if they were regular documents.”

Protected documents are those assigned a sensitivity label with rights-management based encryption. Protected documents stored in SharePoint Online and OneDrive for Business are unencrypted to allow system services like Microsoft Search and Data Loss Prevention policies to access both document metadata and content. Encryption is applied when users download documents.

Co-Authoring History

Office online first supported co-authoring for protected documents in November 2019. General availability of the capability in both the Windows and Mac versions of the Microsoft 365 apps for enterprise (desktop) arrived in late 2021. Before co-authoring can happen in a tenant, the setting to enable the feature must be set in the Microsoft 365 compliance center (Figure 1).

I’m sure that the new mobile support will be most appreciated by those who use iOS and Android tablets rather than mobile phones. Anecdotal evidence suggests that many senior employees use tablets when away from the office, and those are the people likely to receive protected documents for review. However, even on an iPhone, it’s perfectly feasible to edit protected documents when other users have the documents open. In Figure 2, we see that Word has locked a paragraph because another user is active there. Locking makes it easier to avoid multiple conflicting changes in the same location.

The AutoSave (synchronization) mechanism isn’t the same as used by the Office online or desktop apps. It seems like the mobile apps synchronize with the server every minute or so rather on an ongoing basis as co-authors input and amend text. If you leave a document open in a co-authoring session and come back to it several hours later, the app downloads the latest content.

Joining the Co-Authoring Preview

Co-authoring of protected documents on mobile devices is now in public preview. It’s not a general preview as you must submit a request to Microsoft to have them enable the preview for your tenant. You’ll also need to upgrade the Office apps on your device to version 16.0.14931 or higher on Android or 2.58.207 or higher on iOS. More information is available in this Microsoft Technical Community post.

Teams Calendar Search

Another recent update that didn’t get much publicity is the inclusion of calendar meetings in search results in the Teams mobile client. Naturally, because it depends on access to the calendar in your Exchange mailbox, search for calendar items only works when you are signed into your home tenant. The feature is generally available to all tenants. You might need to update your Teams mobile client to see calendar items show up in search results.

The search results (Figure 3) look as you’d expect. Search can find any calendar item, and if the item is a Teams meeting, you’ll see the option to join the call (even long after the meeting finished).

On the grand scheme of things, neither of the two features is especially important. They’re more like fill-in functionality to round out how an application works and to make it more useful. You might never use either feature. But if you do, you’ll be glad that Microsoft added them to the mobile apps.

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.

Handling Encryption, Signing, and Permission Controlled Email

A recent question in the Microsoft Technical Community about Data Loss Prevention (DLP) policies covered the difference between encrypted, permission controlled, and signed messages. In this instance, the DLP policy rule included an exception to allow a message containing some sensitive data to pass if encrypted. However, the exception wasn’t triggered for messages protected by Office 365 message encryption (OME) or sensitivity labels. The documentation covering email exceptions didn’t add much insight.

Email encryption has been around for years. S/MIME and PGP are two examples of commonly used email encryption technologies. First supported by Exchange Server 2003, S/MIME support for message encryption and signing is still available in Exchange Online, with the caveat that tenants must take charge of the details of deploying and managing S/MIME to users.

Microsoft acknowledges that its OME and sensitivity labels technologies are direct competitors to S/MIME. These products are based on Azure Rights Management rather than public key technology. For Office 365 tenants, Microsoft protection is easier to deploy and manage, and it can encrypt email sent to other Microsoft 365 tenants and external domains without the need for the receiving organizations to take any action.

It’s even possible to configure sensitivity labels to use S/MIME instead of rights management protection. This is a custom configuration for sensitivity labels that requires the unified labeling client (and Azure Information Protection licenses). I have never used this facility and do not know how well it works in practice.

Email Exceptions for DLP

All of which brings me to the set of email message type exceptions available for a DLP rule (Figure 1). When Microsoft started to develop service-wide Data Loss Prevention capabilities, the set of actions, exceptions, and conditions available for Microsoft 365 DLP policies was more limited for email than Exchange Online DLP. Over time, Microsoft 365 DLP processing capabilities became better and better. Building out the exceptions available in rule processing is an example of where improvements have occurred. A year or so ago, tenants could move their Data Loss Prevention focus away from Exchange Online transport rules (ETRs) to Microsoft 365 DLP without losing functionality.

Apart from wanting to maintain the same DLP processing for both on-premises and cloud email workloads, I don’t know of any obvious reason to continue using ETRs within Microsoft 365. That being said, some organizations have enormously complex DLP rules which require substantial effort to move to Microsoft 365 DLP policies. In some cases, these tenants will stay using ETRs until they’re forced to move.

What we learn from Figure 1 is that the available message types for DLP exceptions are:

• Signed messages (digital signature applied by S/MIME).
• Encrypted messages (S/MIME). See this Exchange 2010 documentation.
• Permission controlled (rights management).

Permission controlled is an odd term. I can understand why it’s used because rights management is all about granting permissions to users or groups to interact with content, but the term doesn’t tell the administrator that it means rights management. But it does, and despite the fact that rights management can encrypt email, using Encrypted as an exception won’t work for messages protected by OME or sensitivity labels.

Permission Controlled the Way to Go

For most organizations, the Signed and Encrypted message types are now firmly in the legacy category, and they’ll never need to deploy Data Loss Prevention rules to deal with these types. The majority will use OME and/or sensitivity labels and should therefore use the permission-controlled message type in DLP policy rule exceptions. I never knew this detail until now. Discovering new things about how Microsoft 365 works daily is one of the unique joys (or pains) of coping with the cloud. At least, I think it does…

Learn more about how the Office 365 applications really work 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.

Privacy and Protection Might Not be Enough

MVP Ingo Gegenwarth’s post about Outlook and private items is a good example of the problems which arise when user assumptions running into software limitations. The assumption is that if you mark an item as private, only you can see its contents. The limitation is that it depends on clients containing code to respect private items. Some do, and some don’t, much to the chagrin of users when they find out.

Delegate Access to Protected Email

Similar confusion exists around protected email which arrives in a user mailbox and is read by a delegate. Email protected by a sensitivity label uses rights management to know what a user can do with the content. If they don’t have the right to view the encrypted content, the mail client shouldn’t open the message. But if someone has delegate access to a user or shared mailbox, they might be able to read protected messages. It all depends on the client used and the rights assigned in the sensitivity label.

For instance, here’s an example where a protected message arrives in a mailbox. The delegate (full mailbox access) can read the protected message with OWA (left), but not with Outlook desktop (right). They can also read the message with Outlook mobile if they add their delegate account there.

Change Coming for Some Outlook Clients

In their FAQ for protected email, Microsoft says:

“Is delegated access supported with opening encrypted messages? Even if a delegate has full access to another user’s mailbox?

Delegated access of encrypted mail is supported in Outlook on the web, Outlook for Mac, Outlook for iOS, and Outlook for Android. Outlook for Windows does not support delegated access.”

A change described in Microsoft 365 roadmap item 88888 appears as if it will help. The item says:

“Outlook will provide consistent access control on protected emails for delegates and shared mailbox members. For delegates or shared mailbox members, when they have full access of the owner’s mailbox but are not allowed to read encrypted email, Outlook will have a new setting to block the owner’s protected email access which covers ad-hoc encrypted email as well as email with protected MIP sensitivity labels.”

According to the roadmap, we will see this change in April 2022. However, it only applies to OWA, Mac, iOS, and Android. Outlook for Windows remains an outlier. And that’s the problem because Outlook for Windows is often the client of choice for administrative assistants who process email on behalf of others.

Protecting Confidentiality

Is there anything that can be done in the situation where the organization uses sensitivity labels to protect confidential email and documents and want to be sure that delegates cannot access this material? Well, you could remove OWA and Outlook Mobile access from delegate accounts to force them to use Outlook desktop, but that’s probably not realistic.

Instead, an old technique from on-premises Exchange might be useful. For executives who need the assurance that delegates cannot access protected email, you could create two accounts with mailboxes. Let’s take the example of the CEO. They would have:

• A primary mailbox accessed by the delegate to manage inbound email and the calendar. The mailbox appears in the GAL and is accessible to anyone in the organization (or maybe not, as the case demands).
• A hidden mailbox which only the owner can access. This mailbox is not listed in the GAL and is limited so that only certain people can send email to it. This mailbox is used for protected or other confidential email, so the rights assigned in sensitivity labels grant access to the hidden mailbox instead of the primary mailbox.

A certain amount of configuration to make sure that the two accounts work as planned. However, if protected email is sent to the hidden mailbox and only the owner of that mailbox accesses the email, there’s no chance that the delegate can see confidential material.

Yes, this is a pain. Delegate access to protected email should work better with Outlook for Windows. Let’s hope that Microsoft moves on this point soon. Perhaps it’ll be an example of their One Outlook strategy of bringing OWA features to Outlook desktop.

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.

Seeking Protection Against Forwarding

A question came in about the best way for internal email to be protected against external sharing. The company in question uses dynamic distribution lists for employee communications like organizational announcements. Management wants recipients to be unable to forward this email to external people. It’s a common request that goes back to the earliest days of information protection.

Outlook and OWA support encryption through the two default templates made available through Office 365 Message Encryption (OME) to users with Office 365 E3 and E5 licenses. The Encrypt-Only template protects email in transit and makes sure that only people on the addressee list can open messages. The Do No Forward template adds in a block to prevent forwarding. On the surface, it seems like the Do Not Forward template is a good choice. And is it, but only if you use regular distribution lists. OME-protected messages don’t work with dynamic distribution lists. The reason is simple and comes down to the inability to obtain use licenses from the Information Protection service.

Dynamic Membership Stops Protection Licensing

Exchange Online resolves the membership of a dynamic distribution list to know who should receive copies of messages sent to the list. For years, resolution happened when the transport service processed a message sent to a dynamic distribution list. Recently, Microsoft changed this to a timed basis, meaning that Exchange Online resolves the recipient query against the directory to find list membership daily. List membership is less dynamic than it once was, but the lack of immediacy doesn’t usually make much difference in practice.

When Exchange Online processes email sent to a dynamic distribution group, it bifurcates the message to create a copy to deliver to each recipient. If the message is protected with OME, recipients receive an encrypted copy with their email address in the message recipients. To open the copy, the recipient needs the right to access the content, which works for OME because the publishing license for the message includes the recipient. However, because Exchange Online creates message copies in the transport pipeline for list recipient, the publishing license doesn’t include their details. Email clients cannot verify that the recipient has the necessary permission, so they cannot open the message (Figure 1).

In a nutshell, OME templates work well when sent to individual recipients present in messages when sent. They just can’t deal with the way Exchange Online adds recipients to messages during transport.

Use a Sensitivity Label to Protect Confidential Email

Although dynamic distribution lists cannot be used with OME, sensitivity labels offer a solution. You cannot control the rights assigned through an OME template, but this control is possible in a sensitivity label. The key is to include the special All users and groups and your organization group in the permissions assigned in the label (Figure 2).

You can also assign permissions to individual users or groups (but not dynamic distribution lists). If you do this for a label used with dynamic distribution lists, make sure that you assign permissions to cover everyone in the list. If you don’t, some recipients will be unable to read messages. All users and groups in your organization is a convenient way to ensure that everyone in the tenant can read content protected by the sensitivity label, including documents stored in SharePoint Online and OneDrive for Business.

When you add permission assignments to the label, you define the rights the assignees receive. While you can create a custom permission set containing specific rights, Microsoft makes it easy to assign rights through predefined sets. Details of the Viewer role appear in Figure 3. Recipients with this role can read content but they cannot perform other actions like print or forward. Assigning this role to the special group in a sensitivity label ensures that everyone with an account in the tenant can read any content protected by the label.

After configuring the sensitivity label, it can be made available to users through a label publishing policy. This process will take some hours because it requires clients to refresh their label cache. Once this happens, users can apply the sensitivity label to email sent to dynamic distribution lists, and tenant accounts who are members of those lists can read the messages (Figure 4).

If someone forwards a message to someone outside the tenant, that user won’t have the necessary rights to open the message and all they’ll see is a message with an encrypted attachment. They can follow the directions in the message to the OME portal and attempt to open the message there, but without rights, nothing will happen. This is a good example of rights management in action.

Rights Management and Office 365

Anyone with an Office 365 license can read content protected with sensitivity labels. To apply sensitivity labels, you need at least an Office 365 E3 license. Remember that sensitivity labels also support container management for Groups, Teams, and Sites, so they’re more than just a way to apply encryption.

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.

Making Sure Confidential Documents are Retained

By their very nature, sensitivity labels are intended to mark documents and files as containing important information. With this thought in mind, it makes sense to apply retention labels to files based on the sensitivity of the information they contain. Given that they know the content, you can ask users to assign appropriate retention labels to files, but humans are imperfect and often forget, which is where auto-label retention policies come in.

Auto-label retention policies run in the background to check Exchange Online messages, and files in SharePoint Online sites and OneDrive for Business sites. Auto-label retention labels also support Microsoft 365 Groups, meaning that they apply to the messages in group mailboxes and the files in the SharePoint Online team sites belonging to groups (including Teams). The basic principles of auto-label retention policies are:

• Identify the objects to label through a content query. The query could be the presence of a sensitive information type known to Microsoft 365, like a credit card number. Microsoft 365 includes over 250 different sensitive information types, and organizations can create their own types to handle business requirements. Organizations can also create trainable classifiers based on business documents and use classifiers with auto-label policies. Finally, you can use a search constructed with the Keyword Query Language (KQL), which is what we’ll use.
• Define a retention label for the policy to apply when it finds content matching its conditions. You can choose any retention label defined in the organization.

Auto-label retention policies are an advanced compliance feature, meaning that any account which comes within the scope of a policy must have an appropriate license (like Office 365 E5 or Microsoft 365 compliance).

Working Through an Example

In this example, we’ll create an auto-label retention policy to assign a retention label to documents and messages protected by the Highly Confidential sensitivity label. To do this, you:

• Connect to the compliance endpoint with PowerShell by connecting to Exchange Online and then running the Connect-IPPSSession cmdlet.
• Find the unique identifier (GUID) for the selected sensitivity label by running the Get-Label cmdlet. The ImmutableId property contains the GUID.

Get-Label | ? {$_.DisplayName -eq "Highly Confidential"} | Select-Object -ExpandProperty ImmutableId

Guid
----
9ec4cb17-1374-4016-a356-25a7de5e411d

• Use SharePoint search to test the KQL query for the auto-label policy. The search term is in the form InformationProtectionLabelId:9ec4cb17-1374-4016-a356-25a7de5e411d wherethe managed SharePoint property used to hold sensitivity labels (InformationProtectionLabelId) is combined with the GUID identifying the sensitivity label you want to search for. Run the search and open one of the documents returned by the search to check that it has the correct sensitivity label. If no documents are found, it might indicate that the GUID is incorrect or that your account has access to no documents assigned this sensitivity label.
• If the search term finds the correct documents, go to the Information governance section of the Microsoft 365 compliance center to create an auto-label retention policy. The condition of the policy uses the same search term as the content query to find the target documents. The policy action applies a suitable retention label to keep the documents for the desired period. Figure 1 shows the KQL query inserted in the settings of an auto-label retention policy.

• Configure the policy with target locations. Remember to use Microsoft 365 Groups to cover SharePoint sites owned by groups and teams. Publish the policy when everything is complete.
• After ten days or so, check that documents with the sensitivity label have the correct retention label, remembering that if a user assigns a retention label to a document, an auto-label policy won’t replace it.

The ten days mentioned above is an estimate rather than a guarantee. It can take SharePoint Online anything from seven days to two weeks for a new auto-label retention policy to become operational and start to apply retention labels.

Retention and Sensitivity

If you have the necessary licenses, auto-label retention policies are a great way to make sure that important information is kept for as long as required or that other information is removed once no longer required. Another example is to apply retention labels to Teams meeting recordings (a more flexible option than the default Teams-only retention for meeting recordings).

Microsoft’s original labeling plan features labels that had both retention and sensitivity capabilities. That plan fell by the wayside, perhaps because such labels might have been very complex to implement and manage. We now must implement retention labels and sensitivity labels separately. Auto-label retention policies are one way to bring the two together in some small way.

The Office 365 for IT Pros eBook includes chapters with in-depth coverage of both retention labels and sensitivity labels. If you’re planning a deployment which includes these components, you can benefit from our insight.

Unexpected Announcement at a Curious Time

In an unexpected twist just as people were leaving for the holiday period, Microsoft announced on December 21 that, effective January 1, 2022, the Microsoft Information Protection unified labeling client is in maintenance mode. In their post, Microsoft is clear that this status means only that they will not invest in new functionality for the client as they prefer to dedicate engineering resources to building out Microsoft Information Protection (MIP) capabilities in other ways. Although Microsoft won’t enhance the software, they will maintain it to allow customers to continue using the unified labeling client and fix bugs.

Unified Labeling Client Functionality

The unified labeling client includes four major pieces of functionality.

• Adds the Sensitivity button to the menu bar of Office desktop applications (perpetual versions) to allow users apply sensitivity labels to Office files. The Office applications in Microsoft 365 apps for enterprise include these UI elements. The code to encrypt and decrypt files is in the unified labeling client.
• Integrates with Windows File Explorer to allow users apply sensitivity labels to files stored outside Microsoft 365 through a Classify and Protect option in the right-click menu.
• Installs a viewer to allow the display of protected content when an application can’t handle these files.
• Installs a PowerShell module to allow administrators to manage protected files.

The unified labeling client replaced the original Azure Information Protection client, which Microsoft deprecated on March 31, 2021. The software only runs on Windows. Its heritage goes back to the original Azure Information Protection project when add-on software was the only way to enable information protection functionality. Things are very different now because the Office apps (mobile, click-to-run desktop, and browser) used with Microsoft 365 include native support for sensitivity labels and don’t need any add-on software. By native, I mean that the apps include the necessary MIP code to fetch and display sensitivity labels and encrypt and decrypt files as necessary.

Customer Needs for Information Protection

However, some customers use older versions of the Office desktop apps which don’t support MIP, want to apply sensitivity labels to files stored outside SharePoint Online, OneDrive for Business, and Exchange Online, or need to apply labels to non-Office formats which support sensitivity labels (PDF is a good example). These are the classic use cases when customers decide to deploy the unified labeling client and pay for the necessary Azure Information Protection licenses. See this page for the latest information about the client.

Although Microsoft emphasizes that the unified labeling client remains available and supported, customers will want to see continued progress to build out the MIP ecosystem in both Microsoft and third-party apps. There’s no point in making an investment in MIP if its domain is limited to Microsoft 365 and the Office apps. The role of the MIP SDK is critical in terms of convincing ISVs to support protection of non-Microsoft application data. Adobe’s implementation of MIP to protect PDF files is an example of what’s needed.

In other news conveyed in the same post, Microsoft says that they will sunset the AIP mobile viewer apps for iOS and Android on December 31, 2022. In addition, as announced in early 2020, Microsoft will remove the ability to manage AIP labels in the Azure portal on March 31, 2022. This is not unexpected as full (and better) support for sensitivity label management is available in the Microsoft 365 compliance center.

Better Communication Would Help

Most organizations don’t like surprises which affect their IT strategy. Posting an announcement in the Microsoft Technical Community just before Christmas to inform customers that software is going into maintenance mode nine days later is not an example of good communications. The text creates more questions than it answers. For instance, how long will the unified labeling client remain in maintenance before Microsoft decides to depreciate it? Are more ISVs including native MIP support in their applications? Will customers have to continue to pay for licenses at the same rate to use software that’s no longer under active development?

No doubt Microsoft will answer these and other questions as time goes by. It just would have been better to give customers more notice and more information when this announcement appeared. At least Microsoft made the announcement in time for us to include the information in the January 2022 update for Office 365 for IT Pros!

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.

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.

First In-Person Event Since 2019

The last in-person event I spoke at was the European SharePoint Conference in Prague in December 2019. Much has happened since, but as society gradually recovers from the effects of the Covid-19 pandemic, conferences are beginning to cast off the constraints imposed by having to run as virtual gatherings. Don’t get me wrong. Virtual conferences filled a gap while travel was impossible or restricted, but the energy, vitality, and enthusiasm present when gathering to listen to a series of sessions delivered by Microsoft Teams or Zoom is very different to an in-person event.

All of which means that I am looking forward to being in Dusseldorf, Germany for the European Collaboration Summit (ECS) starting on November 29. ECS runs alongside its sister event, the European Cloud Summit. Both events are being run under strict Covid-19 protocols to protect all those involved.

ECS is a community event which isn’t run purely on a commercial basis (costs must be covered, so the event is sponsored). The result is that the ECS vibe is quite different. Because it’s a community event, ECS sessions deliver more independent and diverse thought about how technology works and how to extract value from deployments. Compared to the blandness of a Microsoft event like Ignite, the level of marketing hyperbole, overpromising, and under delivery is far less.

Although I enjoy seeing the range of expertise available in most ECS sessions, I consider it regrettable that all the ECS keynote sessions feature Microsoft employees. This is no criticism of the Microsoft speakers, most of whom I know well. Instead, it’s a desire for conferences to surface diverse leadership opinions instead of automatically assuming that the only source of inspiration and knowledge comes from those with a Microsoft badge. There’s surely some independent thinking available in the Microsoft collaboration community suitable for a keynote to replace and counterbalance the sameness of the messages delivered by Microsoft at conferences around the globe. Remember, if we all believed the marketing bluster received from Microsoft in the past, everyone would be communicating by Yammer instead of using email and Teams.

My Schedule

ECS begins with a day of workshops on Monday with sessions delivered over the following two days. I’ll cover All About Microsoft 365 Sensitivity Labels at 14:45 on Tuesday, 30 November in Room 1 (Aurum room) while fellow Office 365 for IT Pros author and MVP Paul Robichaux will present on Email is the Easy Part: 5 Pitfalls to Avoid in Tenant-to-Tenant Migrations at 15:00 on Wednesday, 1 December at the Teams Stage.

I’ve covered the development of sensitivity labels and their spreading influence within Microsoft 365 since the debut of the technology. Recent articles include:

• How Sensitivity Labels can control the external sharing capability for SharePoint Online Sites.
• How to Decrypt SharePoint Online Documents using PowerShell and the Graph API
• How to use Sensitivity Labels to protect Teams meeting recordings.
• Synchronizing Sensitivity Labels from Microsoft 365 Groups to Update SharePoint Online Sites.
• How to Report the Audit Events Generated by Sensitivity Labels.
• Power BI Support for Sensitivity Labels.
• Using Advanced Settings for Sensitivity Labels with Outlook.
• How to Monitor Changes in the Sensitivity Labels Applied to Sites, Teams, and Groups.

Hopefully, I will have some new information to share with attendees. That’s the plan, but like most plans, it will go out the window once the first slide hits the screen. We’ll see how things evolve based on audience participation, questions, and whatever comes into my head at the time.

Here’s a downloadable copy of my presentation (not protected by a sensitivity label)

Regretfully, I won’t be at ECS on Wednesday. Other commitments bring me back to Dublin on Wednesday morning. However, there’s a bunch of good sessions scheduled for day 2 of ECS, so I suspect I’ll be one of the few leaving early.

Learn about protecting Office 365 content by subscribing to the Office 365 for IT Pros eBook. Use our experience to understand what’s importance and how best to protect your tenant. We have a full chapter explaining all you need to know about Information protection.

Investigating Unlabeled SharePoint Sites

Microsoft is fond of equipping its administrative consoles with cards containing insights which administrators might action. Yesterday, I noticed that the SharePoint Online admin center highlighted that my tenant had many sites had no sensitivity label (Figure 1).

As you might recall, Microsoft 365 uses sensitivity labels to apply settings to “containers” (teams, groups, and sites). Controlling the external sharing capability of SharePoint Online sites is a good example of the power of this approach. By default, I assign sensitivity labels to when creating new Microsoft 365 groups and teams, so it surprised me to discover the unlabeled state of so many sites.

Explaining Unlabeled Sites

Using the Manage unlabeled sites link, I examined the sites. Because I use sensitivity labels for the sites used for groups and teams, I expected to find that some sites in the tenant had no labels. These include:

• Hub sites.
• Communication sites.
• System sites (such as the one used to manage Viva Topics).

Knowing that teams created using templates didn’t ask team owners to assign a sensitivity label until Microsoft fixed the problem in October 2021 (MC281936, Microsoft 365 roadmap item 84232), I could account for some other unlabeled sites. However, stripping all the explainable sites from the 126 noted by SharePoint still left a bunch that I couldn’t explain except by concluding that at some points in the past, the synchronization of sensitivity labels didn’t work as well as it should between SharePoint Online and the other workloads. This is an important thing to fix because if SharePoint Online doesn’t know about a sensitivity label assigned to a site, it can’t apply the management controls defined in that label.

For the record, the synchronization of sensitivity labels for new groups works well. This might be the vestige of a long-solved problem.

Fixing Up Site Sensitivity Labels

To address the problem, I decided to write some PowerShell. The first stage was to find all the sites created for teams and Microsoft 365 Groups that didn’t have a label. To do this, the code:

• Runs the Get-SPOSite cmdlet to find all sites created using the team site template.
• Run Get-SPOSite against each site to find sites without a sensitivity label. You need to access each site to find if it has a label because Get-SPOSite doesn’t return this property when run against multiple sites.
• Store the unlabeled sites in a list.

Here’s the code I used:

[array]$Sites = Get-SPOSite -Limit All -Template Group#0
If (!($Sites)) { Write-Error "No sites for Microsoft 365 Groups found... exiting!" ; break}
   Else { Write-Host ("Processing {0} sites" -f $Sites.Count) }

$SitesNoLabels = [System.Collections.Generic.List[Object]]::new()
ForEach ($Site in $Sites) { #Check each site to see if it has a sensitivity label
        $SiteData = Get-SPOSite -Identity $Site.Url
        If ([string]::IsNullOrWhiteSpace(($SiteData.SensitivityLabel)) -eq $True) {
           Write-Host ("Site {0} has no label" -f $SiteData.Url) 
           $SiteInfo = [PSCustomObject][Ordered]@{  
              URL    = $SiteData.Url
              Title   = $SiteData.Title   }
           $SitesNoLabels.Add($SiteInfo) }
} #End ForEach Sites

The properties of a Microsoft 365 group store the GUID of the sensitivity label, if one is assigned to the group/team. The next step is to retrieve the sensitivity label information for all groups. It’s possible to match a group with a site because the group properties include the site URL. I therefore:

• Used the Get-UnifiedGroup cmdlet to find all Microsoft 365 Groups. This won’t be a fast operation in large tenants, but it’s acceptable because this is a one-time operation. In the largest tenants, consider replacing the Get-UnifiedGroup cmdlet with the Groups Graph API (see the call to fetch all Microsoft 365 groups in a tenant described in this article).
• Removed any group that didn’t have a SharePoint site URL in its properties (sometimes an error in the provisioning process leaves this property blank. Microsoft 365 will eventually synchronize the site URL from SharePoint Online to Exchange Online).
• Store the site URL and sensitivity label GUID in a hash table. A list would also do, but it’s much faster to lookup against a hash table.

Here’s the code for this segment:

Write-Host "Retrieving sensitivity label information for Microsoft 365 Groups"
[array]$Groups = Get-UnifiedGroup -ResultSize Unlimited 
$Groups = $Groups | ? {$_.SharePointSiteUrl -ne $Null}
$GroupsTable = @{}
$Groups.ForEach( {
       $GroupsTable.Add([String]$_.SharePointSiteUrl, $_.SensitivityLabel) } )

We now have a list of sites without labels and a table with the labels assigned to the underlying groups. The next step is to check each site against the groups table to see if we can find what label the site should have. If we find a match, we can update the site. The next code segment does the following:

• Loop to check each unlabeled site.
• Use the site URL as a lookup against the groups table.
• If the site URL matches, use the label GUID to update the site with the Set-SPOSite cmdlet.

This code applies sensitivity labels to sites using the information from Microsoft 365 Groups:

[int]$Updates = 0; [int]$NoUpdates = 0
ForEach ($Site in $SitesNoLabels) {
    $Label = $Null
    $Label = $GroupsTable.Item($Site.Url)
    If ($Label) { # Update the site with the label we find
       Write-Host ("Updating site {0} with label {1}" -f $Site.Url, $Label.Guid) 
       Set-SPOSite -Identity $Site.Url -SensitivityLabel $Label.Guid 
       $Updates++ }
    Else {
       Write-Host ("Can't find sensitivity label for site {0} - group might be deleted" -f $Site.Url)
       $NoUpdates++ }
} #End ForEach Sites

The complete script is available from GitHub.

A Better Card

Of the 126 unlabeled sites reported by SharePoint Online, 116 were team sites. The technique described above managed to apply sensitivity labels to 103 sites. The remaining 13 are deleted sites kept by SharePoint Online because of a retention policy (the associated Microsoft 365 group is gone). The card displayed in the SharePoint Online admin center looks better (Figure 2) and all the sites belonging to Microsoft 365 groups and teams have their correct labels. All is well.

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.

Discovering Some Nuggets from Microsoft’s Coverage

It’s been a busy week for anyone following the Microsoft 365 ecosystem as Microsoft released a slew of blog posts and announcements to support keynotes and other sessions at the Microsoft Ignite Fall event. You could spend hours reading about new features and functionality and wonder when the code will appear in your Office 365 tenant and if any additional licenses are necessary.

This post captures notes about several features available now that I noticed as I perused Microsoft’s coverage. By themselves, each is not enough to warrant a separate post, but they’re interesting all the same. These changes are examples of the stuff we track to maintain the content of the Office 365 for IT Pros eBook. All our chapter authors have been busy this week.

SharePoint Online and OneDrive for Business

Sharing links show who you’ve shared a document with. This feature was announced in June but seems to have taken its time to roll out. The idea is simple. When you send a new sharing link, SharePoint Online and OneDrive for Business tell you who the document is already shared with (Figure 1), including a thumbnail of each person (if available in Azure AD). You can hover over a thumbnail to see who the person is. The number of active sharing links also appears. It’s a small but useful change.

Easy to overlook, the SharePoint Online admin center now displays connected channel sites when a site used by Teams creates private channels (Figure 2). If you can’t remember which sites have private channel sites, connect to SharePoint Online PowerShell and run:

Get-SPOSite -Limit All -Template TeamChannel#0 | ? {$_.TeamsChannelType -eq "PrivateChannel"}

If you click the channel sites link, the admin center displays details of those sites. Teams manages the settings for these sites, but it’s nice to be able to have easy access to the information. Shared channels, which are delayed until early 2022, also use channel sites.

OneDrive for Business supports Known Folder Move (KMF) and Files on Demand on MacOS, which is nice if you’ve invested in a brand-new M1-powered Mac.

If your tenant uses sensitivity labels and has SharePoint Syntex, you can apply sensitivity labels to protect the document understanding models. The application of a label in this manner flows through to protect individual documents identified by models. It’s another way of automatically applying labels to sensitive content.

Sensitivity label control over sharing capabilities of SharePoint Online sites is now generally available. In addition, co-authoring and autosave of protected documents is generally available in the Microsoft 365 apps for enterprise (Word, Excel, and PowerPoint). We use protected documents heavily to store chapter files for the Office 365 for IT Pros eBook, so this is a welcome advance.

Exchange Online

Microsoft Scheduler can now dynamically adjust the scheduling of recurring meetings. This is message center notification MC295855 (November 2) and it’s a great idea. Static recurring meetings are all too often cancelled or rescheduled because someone is sick or otherwise unavailable. After a recurring meeting finishes, Scheduler looks for the best time slot for the next instance and books that time.

Everyone’s probably familiar with the Exchange Online campaign to remove basic authentication for email connection protocols (that October 2022 date is getting nearer!). PowerShell is on the list of protocols to be blocked for basic authentication, but the Exchange Online management PowerShell module still uses basic authentication to communicate with WinRM on a local workstation. Work is under way to remove the need to use WinRM. Microsoft has released a preview version (2.0.6-3preview) of the module to demonstrate how they will remove the dependency by using a REST API in the background. Exchange Online has many cmdlets, not all of which have been converted to use the new mechanism, but you can test the preview now.

On the downside, Microsoft didn’t say anything at Ignite about the next version of on-premises Exchange. This is strange given the September 2020 announcement said the next version of Exchange Server would be available in the second half of 2021.

Microsoft 365

Microsoft says that Visio web app is rolling out to Microsoft 365 commercial tenants (all tenants with Office 365 enterprise plans). The rollout goes through to the end of January 2022, so keep an eye on the app launcher to see when Visio web app (aka Visio in Microsoft 365) shows up in your tenant.

Microsoft Cloud App Security (MCAS) is now Microsoft Defender for Cloud Apps (surely MDCA?). The app governance add-on is now generally available. It’s a good way to chase down apps registered in Azure AD that are over-permissioned or not being used. If you don’t have MDCA or don’t want to pay for the add-on, use our DIY audit method for Azure AD apps.

Access to the knowledge available in topic cards created by Viva Topics has been restricted to some lesser-used applications up to now. Things will change when topic cards appear in OWA and Teams. Apparently, this will happen soon and should be a game changer for the organizations who have invested in the work needed to harvest organizational knowledge through Viva Topics.

Teams

Microsoft prioritized Teams at Ignite as the center of a new way to work (see my practical365.com article), so there were lots of Teams-related developments discussed, most of which can be left until they appear in a tenant near you. One snippet in a blog post about improving meeting quality is that noise suppression in Teams meetings will be available for iOS soon. Microsoft claims that they saw a “31% decline in comments about background noise distractions” after the launch of noise suppression. This sounds like a good thing, but a single statistic provided without any further context or detail is worthless. We don’t know the sample size, whether the clients were Windows or Mac. What kind of meetings, and what is meant by “comments” (good, bad, or indifferent). Like many Microsoft statistics, there’s plenty of room for fudging an issue.

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.

Personal and Organization Document Management for Microsoft 365

I don’t know why Microsoft ever thought that it was wise or desirable to consider SharePoint Online and OneDrive for Business as two separate workloads. The decision might have made sense years ago, when Microsoft began to extract itself from the legacy of its on-premises servers and wanted to demonstrate that it had multiple services to offer within Office 365. It makes none in the context of today’s cloud services.

The simple fact is that OneDrive for Business is no longer an optional extra for Office 365 users. Teams uses OneDrive for Business to share files, including the components built using the Fluid framework, in chats. Recordings of Teams personal meetings also go into OneDrive for Business, and Whiteboard is about to make the transition to OneDrive storage too. If you save an email attachment from Outlook, OneDrive is the preferred target. Users are encouraged to move their files stored in well-known folders from local workstations to OneDrive for Business to take advantage of features like Autosave and differential synchronization.

Increasing Importance of OneDrive for Business

Microsoft makes large amounts of storage available to OneDrive for Business users to make it possible to store data online. All signs indicate that Microsoft will continue to move application and personal data to OneDrive for Business storage whenever possible because it makes it easier to index and search files, including eDiscovery support. In a nutshell, the central importance of OneDrive for Business to cloud users increases as time passes.

The Demise of the OneDrive Admin Center

Which brings me to the elimination of the OneDrive for Business admin center. Or at least, the move of OneDrive settings into the SharePoint Online admin center (Figure 1), which removes the need for the OneDrive admin center. The SharePoint Online admin center has always had settings which affected OneDrive for Business, like sharing controls. Now we have a single place to manage system and personal document and file management for Microsoft 365, which is what these products deliver.

Microsoft covered the move of the OneDrive settings in a July 2021 blog post. With so many blog posts, announcements, updates, and other information about different aspects of Microsoft 365 appearing each week, you might not have noticed the transition. If you go to the Settings section of the SharePoint Online admin center (Figure 2), you’ll find the OneDrive for Business controls.

Checking Sensitivity Labels and Sites

Another topic featured in Microsoft’s July blog is the new insight card to report the number of unlabeled sites. These are sites that don’t have an assigned sensitivity label. As you might notice from Figure 1, my tenant reports 128 of these sites. Given that I’ve invested lots of time working to implement sensitivity labels for container management, this seemed like a high number.

After checking the list of sites, I discovered that the set includes:

• Sites retained by a compliance policy after removal of the original Microsoft 365 group.
• System sites like the App Catalog site and the home site and its predecessor.
• Sites created for Yammer communities before the switch of the Yammer network to Microsoft 365 native mode.
• Teams created from a template (to close the gap, MC281936 describes an update rolling out soon to allow team owners to assign a sensitivity label when creating a new team from a template).
• The Viva Topics center site.
• The site created for the group used to control who can create custom templates for the Teams Approvals app.

In short, a bunch of sites turned up, some of which could do with a sensitivity label and others which don’t. In other words, a list that’s well worth reviewing.

Simplification is Goodness

I strongly approve of Microsoft’s move to incorporate OneDrive for Business management into the SharePoint Online admin center. There are still too many administrative consoles across Microsoft 365 and this step simplifies the tenant management landscape.

With the introduction of the new Exchange Online admin center and the transition of the old Security and Compliance Center to the Microsoft 365 compliance center, we’re also seeing rationalization of user interfaces. On the downside, the switchover from old to new consoles seems to be taking forever. Maybe it’s because it people need time to absorb change, but sometimes you’d wonder if it wouldn’t be better if Microsoft pulled the plaster off quickly and launched a family of new fully-functional administrative tools.

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

Learning from the MIP Pros

If you’re interested in Microsoft Information Protection (MIP), you should consider joining the Yammer group where the MIP team share information about how their products work. Which is where I came across a thread covering a situation where someone (for whatever reason) deletes an RMS protection template. This isn’t good because RMS (Rights Management Services) templates underpin components like the sensitivity labels used by people to protect Office documents and PDFs. Essentially, the fear expressed was that if someone removes a template, people would be locked out of documents and email protected by the sensitivity label based on that template. It’s a reasonable concern.

The Publishing License Backstop

As explained in the thread, the publishing license helps to rescue users from the problem of a deleted template. The publishing license (PL) holds details inherited from the template when a document owner applies a sensitivity label to an item. The PL holds the access control list specified in the template (think of a list of email addresses (including the special addresses like anyone in the tenant or any authenticated user) and the rights assigned to each person). For example:

The PL is encrypted so that only the rights management service can access its contents and is signed by the client, meaning that every client can see who applied the template.

When someone attempts to open an item protected by a sensitivity label, they obtain a use license (UL) from the rights management service. Clients that support offline access, like Outlook, can preload use licenses. The UL is an XrML certificate stating the user’s rights to access an item. The UL also holds the encryption key needed to access the item content and has an expiry date (usually 30 days from the time of grant). When the UL expires, it is renewed through user authentication. At this point, any changes to the preassigned rights in the sensitivity label become active. Ad-hoc or user-defined permissions stay in place unless updated on an item.

The combination of UL and a rights account certificate (RAC) allows access to a protected file. The RAC is obtained when someone first uses rights management on a workstation and renewed automatically every 31 days.

Let’s assume that someone goes ahead and deletes the Confidential template, which is used by the Confidential sensitivity labels (these days, most templates are created when sensitivity labels are created, so they have the same name). Many documents assigned the Confidential label are stored in SharePoint Online and OneDrive for Business. When a user with the right to access one of these documents attempts to open the file. At this point, the app (SharePoint Online) requests UL from the rights management service and includes the PL from the file. Because the RMS service cannot find the template, it falls back on the PL and issues a use license based on whatever access rights are noted there. Usually this means that users who expect to have access can continue to access the file, and all is well. However, if administrators have made changes to the access list over time, it could be that the PL from a document does not match the latest access list in the template before its removal. In this case, the users not in the access list cannot open the file.

Don’t Remove Templates

The thread concludes with a strong recommendation not to remove templates. Although the PL backstop exists and works (within reason), it’s not something that you want to depend upon. If you want to stop using a sensitivity label and its template, remove the label from all publishing policies so that users can no longer apply the label to new content. For more information about how MIP uses licenses, read this post (old but still informative).

Initial Confusion from Garbled Message Center Notification

When Microsoft published message center MC261534 on June 11, they confused many people. The text was imprecise and inaccurate, starting off with “With this new feature, when you create a team in Microsoft Teams, a SharePoint team site will automatically get created in tandem.” It required several readings to understand what Microsoft wanted to communicate. Microsoft 365 roadmap 81945 didn’t help, saying “You will see specific updates, including updates to site features, site permissions alignment, site classifications and sensitivity labels, and improvements to the user interface.”

On June 15, clarifying text appeared. It’s still not as clear as I would like. Here’s what I believe will happen when the changes appear in late June to complete rolling out by early August.

Normal Channels

During the provisioning of a new team, the process creates a new SharePoint team site to store documents belonging to the team. Every team has a General channel, so the site also receives a General folder in the site’s document library. When a new channel is added to the team, the action creates a corresponding folder in the document library. Among other data, the channel folders store sub-folders for email sent to the channel. There can be up to 200 channels in a team.

Figure 1 shows a folder in a SharePoint Online document library for a normal Teams channel. In the user interface, we can see important visual elements such as:

• The access type is shown as Private group. In other words, users must be added to the team to gain access. If the team allows anyone to join, it is a Public group.
• The sensitivity label/classification is Guest Access. This value will depend on the labels/classifications defined in the tenant.
• The Settings menu contains Site permissions.
• There is a Go to channel link in the command bar.

SharePoint administrators and team owners (site administrators) can edit settings like the classification/sensitivity label through the Site information link in Settings. They can also amend site permissions through the Site permissions link. It’s rare to edit permissions (membership) of teams-connected sites through SharePoint; the usual approach is to make membership changes through Teams because this updates the team membership roster immediately.

Private Channels

Microsoft introduced private channels in September 2019. A private channel is a collaboration space within a team with access limited to a subset of the team’s membership. The subset of team members become the channel members There can be up to 30 private channels in a team.

Like normal channels, when a private channel is created, Teams creates a folder within a SharePoint document library to store documents shared in the channel. Unlike normal channels, all of which have their channels in the default SharePoint site owned by the team, private channels have their own SharePoint site. This arrangement ensures that Teams can restrict access to the channel members.

The SharePoint sites for private channels inherit their settings from the parent team. You can try to make changes to the site, but a synchronization process will overwrite the changes to restore the team settings.

What’s changing in MC261534? The user interface for the SharePoint document library already has no Site permissions link in the Settings menu and a Private channel indicator is visible. First, sensitivity labels/classifications become read-only so site administrators (channel owners) won’t be able to update this value in Site information. Second, the big Go to channel conversation button visible in Figure 2 is moving to the command bar (as it is in Figure 1).

Microsoft says that the update “improves the template utilized for the channel sites by having the classic SharePoint features off-by-default and will employ the full capabilities of the modern team site.” This refers to the fact that private channel sites use a special SharePoint site template called TeamChannel#0. The special template is adjusted by Microsoft to remove features like Site permissions.

The SharePoint Online admin center does not expose sites used by private channels. This is deliberately done because these sites inherit their settings from the parent team. However, you can find a list of the sites and find out which team a site belongs to with PowerShell:

$Sites = Get-SPOSite -Template "TeamChannel#0" -Limit All
ForEach ($Site in $Sites) {
   $SPOSite = Get-SPOSite -Identity $Site.url -detail
   $Group = Get-UnifiedGroup -Identity $SPOSite.RelatedGroupID.Guid
   Write-Host "Team" $Group.DisplayName "owns private channel site" $Site.URL}

Preparing for Shared Channels

The changes are appropriate and will improve matters. I don’t know if many people try to update sensitivity labels from SharePoint Online, but if they did, those changes would be reversed by synchronization. Even so, it’s better to stop channel owners trying to make changes.

What’s also clear is that Microsoft is preparing for shared channels (aka Teams Connect), due to be available later in 2021. Shared channels also use a separate SharePoint team site to share information among the channel members. There’s a fair chance that shared channels will be more popular than private channels, and if this is true, we’ll see more “special” channels created. Making sure that everything is ready for shared channels makes perfect sense.

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.

Protect Most Confidential SharePoint Online Sites

Adding to their container management capabilities, a feature for sensitivity labels demonstrate how to use authentication contexts with Entra ID conditional access policies to ensure secure access to information in SharePoint Online sites.

An authentication context is a way to tag information which needs special attention. First introduced in March 2021, authentication contexts are additional information required by a service provider before it grants access to a resource. Microsoft positions authentication contexts as a method to “target policies for data and actions within an app.” Put another way, authentication contexts allow organizations to apply more granular control to targeted data.

As implemented for sensitivity labels, authentication contexts link conditional access policies to let applications like SharePoint Online know that users must provide some extra information before they can access information in labelled sites. Let’s work through an example.

Define an Authentication Context

The first thing to do is to define an authentication context. In the Security section of the Entra ID admin center, open the Protection section, select Conditional Access and choose Authentication context. I created a context called Require MFA (Figure 1). The name is what you’ll see in apps like sensitivity labels. The ID for the context shown towards the bottom of the screen (c1 in this case) is an internal value written into the settings of sensitivity labels which use authentication contexts.

The Publish to apps checkbox is set, meaning that this authentication context is visible to apps like sensitivity labels and can be used by conditional access policies.

Create a Conditional Access Policy

The next step is to create a conditional access policy to use the authentication context to force multi-factor authentication. Conditional access policies can range from very simple to very complex. To prove that everything works as expected, I created a simple policy which blocks access to resources tagged with the authentication context unless the user authenticates with MFA. The new thing here is that you select the authentication context instead of apps (Figure 2). The requirement to use MFA is selected in the Grant section (not shown here).

Another easy thing to include in a conditional access policy to protect sensitive data is to include a terms of use (TOU) check to force users to read and acknowledge conditions governing access before they gain access to a site.

Updating the Sensitivity Label

To protect SharePoint Online sites with the conditional access policy, we configure a sensitivity label with the authentication context. Figure 3 shows the UI for sensitivity labels where we’ve selected the authentication context.

Any attempt to access a site with the label causes SharePoint Online to look at the label settings to see if an authentication context is specified. If one is found, SharePoint Online queries Entra ID to find which conditional access policy is associated with the authentication context and invokes the policy. In our example, attempts to access the site succeed if the user authenticates with MFA and fail otherwise.

Using PowerShell to Assign Authentication Contexts to Sites

The value of Sensitivity labels is that they make it easy to assign a set of different controls to containers, including conditional access policy protection to SharePoint Online sites. However, if your tenant doesn’t use sensitivity labels (yet), you can update sites with PowerShell. After you assign a label with an authentication context to a site, SharePoint Online updates two site settings:

• ConditionAccessPolicy: Holds the name of the conditional access policy protecting the site. When using an authentication context, this value is “AuthenticationContext.”
• AuthenticationContextName: Holds the name of the selected authentication context. As per Figure 1, it is “Require MFA.”

Check the values by running the Get-SPOSite cmdlet:

Get-SPOSite -Identity https://office365itpros.sharepoint.com/sites/SuperConfidential | ft con*, aut*

ConditionalAccessPolicy AuthenticationContextName
----------------------- -------------------------
  AuthenticationContext Require MFA

Now we know the properties to update, we can update other sites using the Set-SPOSite cmdlet:

Set-SPOSite -Identity https://office365itpros.sharepoint.com/sites/ProjectAjax -AuthenticationContextName "Require MFA" -ConditionalAccessPolicy "AuthenticationContext"

Testing the Block

To test that everything worked as expected, I used Teams. Many SharePoint sites created today are linked to Teams, so it seemed like a good test scenario. As expected, when I tried to access a site assigned the sensitivity label without using MFA, the Teams Files channel tab failed to connect and displayed an error (Figure 4).

Microsoft says that they are upgrading the Teams Files channel tab to prompt for MFA authentication when necessary. This will make access smoother and avoid users seeing the instant fail in the current experience.

When I tried to open the site using the SharePoint Online browser interface, it opened successfully. This puzzled me for a moment until I realized it was because the account had gone through a self-service password reset (SSPR) challenge and that the credentials gathered through that process satisfied the MFA requirement. This is because Microsoft now uses combined security information for MFA and SSPR (if your organization doesn’t use combined registration, you can enable it using these instructions). When I encountered the SSPR “your organization needs more information” challenge, it didn’t immediately make me think that MFA was involved, but it was!

To confirm that Entra ID enforces the conditional access policy for the site, you can check the Entra ID sign-in logs. Figure 5 shows that Entra ID invoked the policy because a user covered by the policy signed into SharePoint Online. The sign-in record doesn’t capture details of the site, but if only one sensitivity label uses the conditional access policy and you know who signed in, you can put two and two together to know what happened.

Increasing Control

Linking sensitivity labels with conditional access policies increases the granularity of control a label can exercise over SharePoint Online sites and increases the usefulness of sensitivity labels for container management. Multiple conditional access policies can use a context, which opens a bunch of different possibilities about how to control access in different circumstances.

Given the amount of confidential information stored in SharePoint Online, it’s nice to be able control conditional access so easily and a good example of how Microsoft is steadily building up the container management capabilities for sensitivity labels. Make sure that you have the necessary licenses before you use the feature!

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.

Build Organization-Wide Consistency in Sharing Behavior

Updated: February 24, 2022

Sensitivity label container management settings can control the sharing capability of SharePoint Online sites. Separately, the advanced settings of sensitivity labels can control the default sharing link settings for sites and documents. Enforcing consistent sharing capabilities is a good example of how container management through sensitivity labels make it easier to apply organizational standards across sites in a Microsoft 365 tenant.

Controlling Site Sharing

If you create a sensitivity label and configure it to apply a sharing capability of “Only people in your organization,” any site which receives the label automatically enforces that sharing capability. Site owners cannot change the sharing capability of a site without changing the label assigned to the site. Although tenant administrators can’t stop site owners changing a label, this is an auditable action which organizations can track to revert if necessary.

Controlling Default Sharing Link Settings

SharePoint Online creates sharing links when users share content from a site (Figure 1). The sharing link identifies what the person receiving the link can do with the content (read or edit). It also identifies who can use the link (anyone, specific people, tenant accounts).

SharePoint administrators can configure settings for the default sharing link for a site through PowerShell by running the Set-SPOSite cmdlet from the SharePoint Online management module. The relevant parameters are:

• DefaultSharingLinkType: Defines the default sharing link type for the site. For example, if this is “Internal,” the default sharing link type is set to anyone in the organization. The default is None, meaning respect the organization setting (defined with Set-SPOTenant).
• DefaultLinkPermission: Set to View or Edit to define what the link recipient can do. The default is None, meaning respect the organization setting.
• DefaultLinkToExistingAccess: The default is False. If set to True, the default sharing link type is set to People with existing access.

Defining a default sharing link type does not mean that site users are limited to the settings used to create sharing link. Users can update their sharing links to use other settings (for example, change the permission from edit to view), providing they remain within the constraints defined for the site’s external sharing capability.

Updating Sensitivity Labels with Default Sharing Link Settings

Now generally available (February 2022), you can configure the advanced settings of sensitivity labels to control the default sharing links generated for sites. The advantage of this method over configuring settings using Set-SPOSite is that any site assigned a label inherits the settings automatically. You don’t have to configure each site individually.

For now, configuration is by updating the advanced settings for a label with PowerShell. Given past practice, it’s possible that we will see a GUI for advanced label settings sometime in the future.

To update label settings, you connect to the compliance endpoint with PowerShell. Do this by running the Connect-IPPSession cmdlet from the Exchange Online management module. You can then use the Set-Label cmdlet to update the sensitivity labels. The setting names for Set-Label do not correspond exactly with the values used by Set-SPOSite. Here are the values:

• DefaultSharingScope (DefaultSharingLinkType) can be SpecificPeople, Organization, or Anyone.
• DefaultShareLinkPermission (DefaultLinkPermission) can be Edit or View.
• DefaultLinkToExistingAccess is True or False (default False).

You can update link settings separately or together. For example, these commands set the default sharing scope and permission in two steps:

Set-Label -Identity 'Guest Access' -AdvancedSettings @{DefaultSharingScope = "SpecificPeople"}
Set-Label -Identity 'Guest Access' -AdvancedSettings @{DefaultShareLinkPermission = "Edit"}

Or set the two values in one command:

Set-Label -Identity 'Non-Business Use' -AdvancedSettings @{DefaultShareLinkPermission = "Edit"; DefaultSharingScope = "Anyone"}

To check the settings for the label and confirm the configuration, run the Get-Label cmdlet:

Get-Label "Non-Business Use" | Select -ExpandProperty Settings
[contenttype, Site, UnifiedGroup]
[tooltip, Apply this label to a team, group, or site intended to support a non-business use such as a sports club or approved employee society.]
[displayname, Non-business use]
[defaultsharingscope, Anyone]
[defaultsharelinkpermission, Edit]

To set the default sharing link for the site so that it overrides any existing setting and uses people with existing access instead, run:

Set-Label -Identity 'Confidential Access' -AdvancedSettings @{DefaultLinkToExistingAccess  = "True"}

Like any other changes made to sensitivity labels, it can take up to 24 hours before SharePoint Online respects updates to the default sharing link settings.

Update Default Sharing Link Settings for Documents

Being able to control the default sharing link settings for sites by applying sensitivity labels is good. Being able to control default sharing link settings at a document level is even better. Microsoft added this capability between the preview and general availability. The same mechanism is used.

• Update a sensitivity label with default sharing link settings.
• Apply the sensitivity label to documents.
• If users share the labeled documents, SharePoint Online or OneDrive for Business use the settings from the label to generate the sharing link unless the site settings are more restrictive, in which case they take precedence.

The idea here is that you might have some specific documents in a site that you want people to pay attention to if they share the documents. The hope is that users will notice the differences in the sharing link generated by SharePoint Online or OneDrive for Business and recognize that they should be extra careful. The good thing is that people often accept default sharing link settings without question. The bad thing is that people mightn’t notice that a document is more confidential than the rest…

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.

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.

Two Notifications Mark a Special Update

A feature so good that it requires two identical message center notifications must be worthwhile. Such is the case for the ability of sensitivity labels container management to control the external sharing capability of SharePoint Online team sites, as announced in MC244217 and MC244216 on March 12. Both point to Roadmap item 70735.

Information Protection and Container Management

Sensitivity labels can include settings for information protection and container management. Information protection usually means that the assignment of a label to an Office document, Azure Purview data (preview), Power BI objects, or other files will encrypt the target content using Microsoft Information Protection (rights management). Container management means that labels impose settings on a Microsoft 365 group, including the team or SharePoint team site belonging to the group. A single label can include both information protection and container management settings and is therefore applicable to both files and containers, or the scope of the label can be one or the other use. I favor a restricted label scope because I think it makes labels easier to manage.

Container Management Settings

When Microsoft first introduced the ability of sensitivity labels to control container settings, a limited number of controls were available. You can configure a label to:

• Control access to the container to Azure B2B Collaboration guest accounts. Previously, this control over containers could only be set by updating the properties of the group with PowerShell. The options are to allow or block guest access.
• Set the access to be public or private. If a label is not present, the group owner can decide whether the group is public (available to any tenant user) or private (restricted to the group membership).
• Limit access to documents in a SharePoint when using unmanaged devices.

The set of available controls is useful and sensitivity labels are much better than the alternative (like text-based classifications), but Microsoft’s intention always was to expand the number of controls to make sensitivity labels a much more powerful policy-driven management method for containers. Adding control over the sharing capability for SharePoint sites is further evidence of their intent.

Controlling External Access to SharePoint Online Sites

Organizations often store confidential or sensitive documents in SharePoint sites. SharePoint Online supports four values for site sharing capability to control the degree of external sharing permitted for documents in a site:

• Disabled – allow no external sharing outside the organization.
• ExistingExternalUserSharingOnly – allow sharing only with the guest users already in your organization’s directory.
• ExternalUserSharingOnly – allow users to share documents with new external users, who must accept the sharing invitations and go through an authentication process to create a guest account.
• ExternalUserAndGuestSharing – allow sharing with all external users, and by using anonymous access links (Anyone links).

SharePoint Online administrators and site owners can set the sharing capability through:

• The SharePoint Online admin center.
• PowerShell, using the Set-SPOSite cmdlet to update the SharingCapability setting.
• And now, by assigning a sensitivity label which has the external sharing control configured.

Remember that SharePoint Online won’t allow you to assign a less restrictive access to a site than allowed by the tenant sharing setting. In other words, if the tenant explicitly blocks anyone access for all sites, assigning anyone access through a label will have no effect.

Setting External Sharing Capability in a Sensitivity Label

When editing a sensitivity label, administrators can define what sharing capability is set when an owner or administrator assigns the label to a site (Figure 1).

The Site Owner View

Not every site owner knows about admin tools, and a major benefit of controlling sharing capability with sensitivity labels is that it makes it easier for site owners to assign the appropriate level of sharing based on their knowledge of the content within the site. At least, that’s the theory, and a lot depends on the clarity of the names chosen for sensitivity labels. Ideally, the names should convey how sensitive the information stored in the site is (Figure 2).

Applying a sensitivity label to a group or team also applies it to the site and selecting a new sensitivity label for a site also applies it to the associated group and team.

PowerShell Support for Container Management

The PowerShell cmdlets to interact with sensitivity labels are available after connecting a session to the compliance endpoint. The easiest way to do this is to run the Connect-IPPSSession cmdlet from the Exchange Online management module.

Once connected, we can use the Get-Label cmdlet to find details of sensitivity labels and the Set-Label cmdlet to update their settings. For example, not all sensitivity labels are configured for container management, so to find the set of labels scoped for container management, run this code:

Connect-IPPSSession
$Labels = Get-Label
ForEach ($Label in $Labels) {
   If ($Label.ContentType -match "Site, UnifiedGroup") {
   Write-Host "Label" $Label.DisplayName "has container actions" }
}

Label Non-business use has container actions
Label General Access has container actions
Label Guest Access has container actions
Label Limited Access has container actions
Label Confidential Access has container actions

As an example of how to use Set-Label, here are two examples of updating labels to set different sharing capabilities.

Set-Label -Identity Confidential -AdvancedSettings @{sharingcapability="ExistingExternalUserSharingOnly"}
Set-Label -Identity Secret -AdvancedSettings @{sharingcapability="Disabled"}

After applying a label with a sharing capability setting configured to a site, SharePoint updates its sharing capability. You can check that the settings have changed with the Get-SPOSite cmdlet:

Get-SPOSite -Identity "https://office365itpros.sharepoint.com/sites/BlogsAndProjects/" | Select SharingCapability, SensitivityLabel

SharingCapability SensitivityLabel
----------------- ----------------
         Disabled 27451a5b-5823-4853-bcd4-2204d03ab477

Checking that Everything Works

Of course, it’s a good idea to check that the sharing capability set in a sensitivity label works after assigning the label to a site. Let’s assume that you assign a label which disables external sharing. The easy test is to see if sharing works. As Figure 3 shows, it is not allowed and you see one of SharePoint’s famous OSE errors.

Being able to control external sharing for SharePoint sites is just the latest control for sensitivity labels. Microsoft plans more in the future. With this in mind, if you haven’t already started using sensitivity labels, perhaps now is a good time to make a start?

Unlocking Protected SharePoint Documents

In my article about how to decrypt SharePoint Online documents with PowerShell, I explained how to use the Unlock-SPOSensitivityLabelEncryptedFile cmdlet to decrypt protected SharePoint files by removing the sensitivity labels protecting the files. The example script uses cmdlets from the SharePoint PnP module to return a set of files from a folder in a document library for processing, and the unlock cmdlet then removes protection from any file with a sensitivity label.

The script works, but it’s not as flexible as I would like. For instance, because PnP can’t distinguish files with labels, every document in the folder is processed whether it is labelled or not. This does no harm, but it’s not something that you might want to do in the case of something like a tenant-to-tenant migration where thousands of protected documents might need to be processed.

Update May 10, 2021: The latest version of the SharePoint Online PowerShell module contains the Get-FileSensitivityLabelInfo cmdlet. This can be run to return the label status of a file, including if the label assigned to the file encrypts the file. The existence of this cmdlet removes some of the need to use the Graph to find and remove labels from protected files, but the Graph is still the fastest way to get the job done.

Using the Sites Microsoft Graph API

Which brings me to an updated version of the script (available from GitHub), which uses the Sites API from the Microsoft Graph to navigate through SharePoint Online and find labelled documents to process. Apart from being able to search for documents with sensitivity labels, a Graph API is usually the fastest way to deal with large numbers of objects.

Because we’re making Graph calls from PowerShell, we need to create a registered app in Azure AD to use as the entry point to the Graph (the same steps as outlined in this post are used). The app needs to be able to read site data, so I assigned it Sites.Read.All and Sites.ReadWrite.All permissions (Figure 1).

Finding Protected Documents

The script accepts two parameters: the name of the site to search (not the URL) and an optional folder. If multiple matching sites are found, the user is asked to choose which one to search (Figure 2).

Once a target site is confirmed, the script figures out if a folder is specified and if that folder exists in the chosen site. In Graph terms, we’re now dealing with drive objects. The default drive is the root folder of a document library and each folder is a different drive. To find folders, we need to find the child objects in the root, identify the right folder, find its drive identifier, and use that to find the files in the folder. All good, clean Graph fun.

The Drive API returns a maximum of 200 items at a time, so some Nextlink processing is needed to fetch the complete set of files in a folder. Each file is examined to figure out if it has a sensitivity label with protection, and if so, the display name of the label. After processing all the files, we tell the user what we’ve found and ask permission to go ahead and decrypt the files (Figure 3). If the user chooses not to proceed, the script writes details of the protected files out to a CSV file.

Decrypting Files

Files are decrypted by calling the Unlock-SPOSensitivityLabelEncryptedFile cmdlet. There’s no native Graph API call to decrypt SharePoint documents. In any case, we’re running a PowerShell script so it’s easy to call the cmdlet.

An Example to Build On

The script is an example of what’s possible with a combination of PowerShell and Graph API calls. I’m sure that the code and the functionality can be improved (feel free to suggest changes and improvements via GitHub). I’m just happy to demonstrate how things work and how including the Graph enables some extra flexibility.

Read the Office 365 for IT Pros eBook to find much more information about how sensitivity labels work – and many PowerShell examples too!

Possible to Protect Sensitive Meeting Recordings with Some Downsides

Although it’s listed as one of the applications which support sensitivity labels, the only way that Stream uses sensitivity labels is when it creates a new Microsoft 365 group. At that point, you can assign a sensitivity label with container management settings to the new group. Container management is good, but it doesn’t protect the data owned by the group.

This situation creates the question of how best to protect confidential videos. Because sensitivity labels control access to files using fine-grained rights management, they are an attractive choice. Stream “classic” doesn’t support the option to protect files in this manner, but the transition of Stream storage to SharePoint Online and OneDrive for Business creates a potential solution. As we’ll discuss, the basic technology works, but some implementation issues generate more friction than you’d like, possibly because Microsoft hasn’t figured out how the components should work together.

Unified Labeling Client and OneDrive

Microsoft touts the ability of SharePoint and OneDrive to store just about any type of file up to 250 GB, which makes it easy to store recordings of even the longest meeting. However, no user interface exists in the browser interface for SharePoint or OneDrive to assign sensitivity labels to files. Office (online, desktop, and mobile) applications can apply sensitivity labels, including encryption if needed. Exchange Online mail flow rules can also assign sensitivity labels to messages. Outside these implementations, writing some PowerShell or Microsoft Graph code or using Microsoft’s unified labeling client are the only ways to assign sensitivity labels to files.

The unified labeling client runs only on Windows workstations. It integrates with File Explorer to add a Classify and protect option to make it simple to add protection to any file which File Explorer can access. Applying protection to PDF files is a popular use case for the unified labeling client.

The OneDrive sync client can synchronize online folders and files to local copies, so it doesn’t take much lateral thinking to put two and two together and conclude it should be possible to assign sensitivity labels to meeting recordings stored in OneDrive. And as it turns out, it’s true. The only downside is that the unified labeling client requires Azure Information Protection P1 licenses. These licenses are part of the Enterprise Mobility and Security suite, but not bundled in any Office 365 plans.

Protecting Meeting Recordings

Figure 1 shows a set of MP4 video files (and a Word document) in the Recordings folder of my OneDrive for Business account. This is the location where Teams stores its meeting recordings. A label already protects one of the recordings (bottom right), as shown by the Azure Information Protection padlock icon. To protect another file, select it, and choose File Explorer’s Classify and protect option.

The unified labeling client launches to allow the user to select the sensitivity label they wish to apply. Some sensitivity labels apply markings to files without encryption, but as the MP4 format doesn’t support headers, footers, and watermarks like those used in Office documents, the only labels offered for selection in Figure 2 are those which encrypt content.

After selecting the label to apply, click Save to allow the client to encrypt the file. On my i7 Surface Book 2, the client took twelve seconds to process the 358 MB recording (for a meeting lasting 46 minutes). The size of the file is in line with the expected storage consumption for Teams recordings.

Downsides

We now have a protected MP4 file. The downsides are:

• The link posted in Teams for the recording as part of the meeting resources breaks. The recording is still listed as a resource, but the link points to the original MP4 file which no longer exists because it is replaced by the encrypted file (which has a .pfile extension). Protecting the recording also removes the sharing links for the file, so even if you reverse course and remove the label, Teams can’t access the file.
• Because the encryption process creates a new file without sharing links, the owner of the file must share the file with those permitted to view the recording.
• The OneDrive MP4 file viewer can’t open the protected file.
• The only way to view the protected video recording is through the Azure Information Protection viewer (part of the unified labeling client), meaning that those who want to view the recording must install the unified labeling client. Their account also needs an Azure Information Protection license.

In a nutshell, the unified labeling client treats Teams meeting recordings like any other MP4 file it protects. Encryption breaks any special connection between Teams to OneDrive for Business. The result is a protected recording, but the file owner needs to allow access to those to view the recording.

Maybe Not Completely Ready

Just because you can do something doesn’t mean that you should do something. Although you can protect Teams meeting recordings with sensitivity labels, the downsides indicate that the Microsoft engineering teams involved (Teams, SharePoint, Stream, and Microsoft Information Protection) have not yet worked through the issues to come up with a more seamless implementation. To be fair, Stream is in the middle of its switchover from Azure to SharePoint storage, and Microsoft might work through this point as that process unfolds. Service encryption with customer key is one of the work items listed for the migration to the New Stream, but support for sensitivity labels isn’t mentioned.

Until a more seamless integration is available, it’s reasonable to conclude that using sensitivity labels to protect Teams meeting recordings stored in OneDrive is possible with downsides.

Information protection is an important topic covered by the Office 365 for IT Pros eBook. That’s why we think about and test this kind of stuff. Benefit from our work by subscribing to the book. Its monthly updates keep everyone informed about what’s happening inside Office 365.

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.

New Label UI Rolling Out

Update: This capability is now Generally Available. See this post for more information.

Previewed earlier this year, Microsoft has extended the container management settings for sensitivity labels to include control over the external sharing setting for SharePoint Online team sites connected to Microsoft 365 Groups. As per Microsoft 365 roadmap item 68700, the updated user interface to allow tenants to choose the external sharing setting is now rolling out to the Microsoft 365 compliance center.

By default, sensitivity labels do not control external sharing, so if you intend using labels for this purpose, you need to edit the labels used for container management to choose the appropriate setting. To limit the choice available to users and to make label management simpler, my advice is to maintain separate sets of labels: one set for information protection and marking and the other for container management.

Options for External Sharing

SharePoint Online supports organization-level and site-level settings for external sharing. Site-level settings are often used to set a more restrictive level of sharing for sites containing important or confidential information.

The control available in sensitivity labels is over the site-level setting for external sharing. When you assign a sensitivity label to a site (Figure 1), SharePoint Online applies the container management settings to the site, including the external sharing setting.

As shown in Figure 2, the control in a sensitivity label offers the same four external sharing options as can be applied through the SharePoint admin center (see below) or PowerShell (the relevant value used with the Set-SPOSite cmdlet is in parenthesis):

• Anyone (ExternalUserAndGuestSharing): Sharing is allowed with all external users, and documents can be shared using anonymous access links (Anyone links).
• New and existing guests (ExternalUserSharingOnly): Sharing is allowed with new external users, who must accept a sharing invitation and go through an authentication process to create a guest account.
• Existing guests (ExistingExternalUserSharingOnly): Sharing is only allowed with the guest users already in an organization’s directory.
• Only people in your organization (Disabled): No sharing with external users is allowed.

When defined, the external sharing setting is stored in the externalsharingcontroltype value in the label. After connecting a PowerShell session to the compliance center endpoint, we can examine this setting:

$Settings = Get-Label "Confidential Access" | Select -ExpandProperty LabelActions | ConvertFrom-Json
$Settings | ?{$_.Type -eq "protectsite"} | Select -ExpandProperty Settings

Key                        Value
---                        -----
allowfullaccess            false
allowlimitedaccess         false
blockaccess                true
disabled                   false
externalsharingcontroltype Disabled

Label Settings and Tenant Settings

As noted above, the settings available in a sensitivity label match those available for SharePoint Online. Figure 3 shows the values as set in the SharePoint admin center. Remember that the external sharing setting applied to a site cannot be less restrictive than that allowed by the tenant. For instance, if the tenant doesn’t allow Anyone links, you can’t set that external sharing level for a site.

The compliance center GUI doesn’t validate the external sharing capability selected for a label against what’s allowed by the tenant. If a less restrictive external sharing capability is set in a label, SharePoint Online will ignore the setting when it applies container management settings to the site.

The Effect of Caching

SharePoint Online caches sensitivity label data. For this reason, if you update an existing label to add a setting for external sharing, it won’t be available to be applied to sites for 24 hours. On the other hand, if you create a new label with a setting for external sharing, it will be available within 15 minutes.

The Office 365 for IT Pros eBook is the only book covering the technology, deployment, and management of Office 365 apps which is updated monthly. Don’t you think you need to understand what’s going on inside Microsoft’s cloud office service? Subscribe today!

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.

Read Protected PDF with Edge is Useful Feature

In December 2018, Adobe and Microsoft announced support in Adobe Acrobat Reader for PDF files protected with Microsoft Information Protection. An older format for protected PDFs (ppdf) was replaced by one based on V1.7 of the ISO specification for PDF, which allows for rights-management based protection of the kind used by Microsoft Information Protection (MIP) sensitivity labels.

Applying Sensitivity Labels to PDFs

You can’t apply sensitivity labels to PDFs inside an Office 365 app (you can using the paid-for versions of Adobe Acrobat). Instead, you apply labels through the Classify and protect option that’s added to Windows File Explorer when the Unified labeling client is installed on a workstation. Explorer launches the client to apply a label to the PDF (Figure 1).

You can also apply a label with PowerShell using the Set-AIPFileLabel cmdlet, which is installed with the unified labeling client. You can find the GUID for a sensitivity label with the Get-Label cmdlet.

Set-AIPFileLabel -Path "c:\temp\July 9 - Protected.pdf" -LabelId 81955691-b8e8-4a81-b7b4-ab32b130bff5

FileName                        Status Comment
--------                        ------ -------
c:\temp\July 9 - Protected.pdf Success

Finally, you will soon be able to apply sensitivity labels to PDFs by defining a default sensitivity label for SharePoint Online document libraries. This feature already supports Office documents and requires Office 365 E5 or Microsoft 365 E5 compliance licenses.

Reading Protected PDFs

All of this is good, but there’s no point in protecting PDFs if they can’t be read. To read a protected PDF, you need a reader which understands how protection works. Microsoft posts a list of supported readers online, the most common being Adobe Acrobat (Figure 2).

Reading PDFs in Edge Chromium

It’s nice to have a supported reader; it’s even better when the browser supports access to protected PDFs. The latest version of the Chromium-based Edge browser can read protected PDFs (I base this article on Version 83.0.478.61). Reading protected PDFs doesn’t work with private browser sessions, probably because some dependency exists on having a signed-in account.

Browser support for reading protected PDFs means that you can open protected PDFs from the SharePoint Online or OneDrive for Business browser clients or OWA. In this case of SharePoint Online, the protection can stop people taking screen captures. If you try to grab a capture (I tried with Snagit), you end up with a capture that’s all black. As Figure 3 shows, I was forced to take a photo of the screen to illustrate the point.

Some get very worried when applications don’t prevent users copying information from protected content. As demonstrated with SharePoint Online, the application can take the steps necessary to block access, but inventive people will find a way to share the information.

You can’t apply, change, or remove sensitivity labels from PDFs stored in SharePoint Online or OneDrive for Business. Instead, you must download the file and process it with the unified labeling client, and then upload it again.

Reading Protected PDFs with OWA

To test how OWA deals with protected PDFs, I attached the same file to an email and sent it. As you can see in Figure 4, OWA doesn’t stop screen captures even though the same permissions are assigned to the reader. The upside is that you can see the permissions and visual markings used to highlight the protected nature of the content to users.

Reading PDFs in Other Browsers

To show what happens when you try to access a protected PDF with another browser, I opened a SharePoint session with Brave. Figure 5 shows what results when I chose to open the file in the browser. The same is true in Chrome or Internet Explorer. To read the file, I had to download it and open the PDF with Acrobat Reader.

Good Feature to Have as Sensitivity Labels Become More Common

Some might consider building the ability to read protected PDFs into Edge a small and unimportant feature. It might not be the killer feature to convince people to move from Chrome or another browser, but I think the capability will be more appreciated over time, especially as the usage of protected content grows within Office 365 and more protected files are stored in SharePoint Online and Exchange Online.

Need more information about Office 365 sensitivity labels? Look no further than Chapter 24 of the Office 365 for IT Pros eBook. Its 60 pages will inform and delight you about how to use rights management to protect content in Office 365.

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 Labels Spreading Across Office 365

Sensitivity labels are rapidly spreading across Office 365 workloads. They are now supported by:

• Office desktop applications.
• Office online applications.
• Office mobile applications (Outlook mobile can read protected messages but can’t yet apply a sensitivity label to new messages).
• SharePoint Online and OneDrive for Business.
• Container management for Microsoft 365 Groups, Teams, and SharePoint Online sites (the data inside the container isn’t protected, but settings for the containers are).

New features, like the Content Explorer in the Microsoft 365 Compliance Center, help compliance administrators understand the effectiveness of their labeling strategy. Overall, the signs are that the ecosystem surrounding sensitivity labels is gradually building out.

Gaps still exist. You can’t use sensitivity labels to protect Teams messages (the files stored in SharePoint Online and OneDrive for Business for Teams can be). Nor can you use sensitivity labels with Planner, Stream, or Yammer.

Power BI Support for with Sensitivity Labels

An integration announced at Ignite 2019, and now generally available, supports the application of sensitivity labels to Power BI objects. I suspect that this won’t affect many Office 365 users, but it is the closing of another small gap.

Labels are Visual Labels Inside Power BI

Some points to remember about using sensitivity labels with Power BI include:

• The integration must be enabled for the tenant (Figure 1). You can enable support for all users or just selected groups.
• Users must have Power BI Pro licenses to apply sensitivity labels. Power BI Pro is included in Office 365 E5.
• Labels can be applied to reports, dashboards, datasets, and dataflows by editing item settings (Figure 2). They can’t be applied to template apps.
• Power BI doesn’t support sensitivity labels in the government or sovereign clouds.
• The Do Not Forward label isn’t supported nor are labels with user-defined permissions or those depending on HYOK. In other words, your tenant must use a Microsoft-managed key.
• Sensitivity labels are visible in dashboards and when viewing Power BI objects. However, sensitivity labels with encryption do not encrypt Power BI data. Instead, the encryption applies when Power BI objects are exported as Excel, PowerPoint, or PDF files.

In effect, within Power BI, sensitivity labels are used as visual markers of the sensitive nature of some data. The ability of labels to apply encryption and markings to information only occurs when data moves out of Power BI.

Exports Gets Protection

As mentioned above, protection through rights management-based encryption is applied when Power BI exports an object. Figure 3 shows a report exported from Power BI to PowerPoint. The label is present. The big difference is what the user who exported the object from Power BI can do with the document.

Normally, when someone applies a sensitivity label to an Office document, they are the owner and have full access to the document. For instance, they can decide to change the label and apply a more sensitive or less sensitive label depending on the document’s content. When someone exports a file from Power BI, they can still edit the content, but they cannot change the assigned label because they are not regarded as the document’s owner.

The underlying logic is that Power BI manages permissions and access to the information. If a label is applied in Power BI, it should be managed inside Power BI and if the label should be changed, it can be changed there. It’s an example of how the rights management aspects of sensitivity labels adapts to the needs of an application.

So many changes, so many updates, and all happening all the time within Office 365. Which is why you should subscribe to the Office 365 for IT Pros eBook to make sure that you know when things change.

Sensitivity Label Support for SharePoint Online and OneDrive for Business

Updated August 15, 2022

Every Microsoft Purview sensitivity label has a priority order to indicate its level of sensitivity. A sensitivity label mismatch occurs when users upload Office documents or PDFs with sensitivity labels to SharePoint Online sites that have lower priority labels. Mismatches also occur when users update Office documents or PDFs stored in SharePoint Online and change the sensitivity label assigned to the files with one that has a higher priority than the label assigned to the site.

Microsoft recently made support for sensitivity labels in SharePoint Online and OneDrive for Business generally available. This is an important step forward because it allows SharePoint to index content protected by encryption applied by sensitivity labels. The indexed content then becomes available to Data Loss Prevention policies, content searches, and so on.

The integration of sensitivity labels with SharePoint Online is optional and must be enabled for a tenant on an opt-in basis, Afterwards, users can apply, remove, or change sensitivity labels to documents using the SharePoint Online and OneDrive for Business browser interface or through the Office Online apps. Sensitivity labels can be applied by users or by assigning default labels in label publishing policies or as a default sensitivity label assigned to a document library.

Audit Events Captured

Events for these actions are captured by SharePoint Online and ingested along with other SharePoint events into the Office 365 audit log. These events are:

• SensitivityLabelApplied: A label is applied to a SharePoint site.
• FileSensitivityLabelApplied: An Office Online app applies a label to an Office document.
• FileSensitivityLabelChanged: An Office Online app changed a label (upgrade or downgrade).
• FileSensitivityLabelRemoved: An Office Online app removed a label from a file.
• DocumentSensitivityMismatchDetected: A mismatch is detected because the sensitivity label applied to a document is higher than the level of sensitivity applied to the site where the document is stored. For instance, the site is labeled “Confidential” and a user uploads a document assigned the “Super Confidential” label to the site.

Currently, no events are captured when users apply sensitivity labels through other interfaces like Outlook or OWA.

Sensitivity Label Mismatch Email Notifications

When a mismatch occurs, SharePoint Online captures an audit record, and sends an Incompatible sensitivity label detected email notification to the person who uploaded the document. The notification contains details of the document which caused the problem and the label assigned to the document and to the site (Figure 1). It’s up to the person who receives the notification to resolve the issue. Given that they uploaded the document, they should know its true sensitivity. If necessary, they can change the sensitivity label assigned to the document and upload it again.

Handling Confidential Material

Even if it leads to a sensitivity label mismatch, it’s entirely possible that it’s OK to store a highly sensitive document in a site labelled with a lower level of sensitivity. Labels created to protect highly sensitive content usually restrict rights to interact with documents to a limited set of users. It might be desirable to not allow some people with access to the site (like guest accounts) to access a document assigned with a highly sensitive label. However, this should be an exception. It’s good practice to only store documents in sites that are accessible to all members of the site unless good reasons exist to restrict access to some documents to a subset of site members. In these situations, it’s best to store the sensitive material in another site with restricted membership such as a site belonging to a private Teams channel.

Mastering the detail of what happens inside Office 365 is important for tenant administrators. Shouldn’t you subscribe to the Office 365 for IT Pros eBook?

Reduced Confusion as Everyone Waits for Native Support in Office Clients

As is the nature of the Microsoft cloud, the preview version of the Azure Information Protection client (unified labeling edition) has been replaced by the generally available version, now available for download and deployment. Microsoft’s April 16 announcement on the topic was upbeat but I still find considerable confusion in the field about labels, Azure Information Protection, Office, encryption, and rights management. Let’s see if we can clarify the situation.

Rights Management

Rights management is the technology that allows content owners (authors) to protect documents and files by stamping them with a template. The template defines the rights given to recipients to interact with the content such as the ability to edit or print. Rights management is automatically enabled for all Office 365 E3 and E5 tenants.

Azure Information Protection

Azure Information Protection (AIP) is a suite of technology built by Microsoft to control and help secure email, documents, and files. Reflecting their original name of “classification labels,” AIP labels are used to classify material inside or outside Office 365 with different degrees of sensitivity to reflect the confidentiality of the content. Labels are associated with rights management templates but also include other features like content marking. Labels used for the most sensitive information are likely to invoke encryption to protect the information against unauthorized access. AIP labels and templates are managed in the Azure Information Protection blade of the Azure portal. An AIP license is needed to assign AIP labels to files.

Office 365 Sensitivity Labels

Sensitivity Labels are like AIP labels except that they are managed through the Security and Compliance Center. Both sets of labels share a common base in rights management and if a tenant started with AIP labels, they can migrate the set of AIP labels to become sensitivity labels and thereafter continue managing the labels through the Security and Compliance Center.

Sensitivity Labels are designed to protect content like email and documents stored inside Microsoft 365. Office 365 E3 and E5 plans include the licenses to use sensitivity labels, including the ability to encrypt email and documents. Figure 1 shows an Outlook message protected by a sensitivity label. You can also see the protection bar, which shows the current label applied to an item, and the sensitivity button, to expose the set of labels available to the user.

Although Exchange Online, SharePoint Online, and OneDrive for Business support sensitivity labels today, it will take some time before sensitivity label support is picked up in other workloads, like Teams.

AIP Client (s)

Two versions of the AIP clients are available. The standard version reads its policy and label information from the Azure portal. The unified labeling version reads equivalent information from the Security and Compliance Center. Both versions integrate with the Office desktop applications. You should use the AIP unified labeling client with Office 365, making sure to use the latest version whenever possible.

If you see a Protect button in the Office desktop apps, you know you’ve installed the older version of the AIP client. The unified labeling client installs a Sensitivity button (as shown in Figure 1).

Although the unified labeling version of the AIP client is not quite as functional as the older client. Microsoft expects it to reach close to feature parity with its older counterpart by the end of 2019. Microsoft’s blog post also makes the important point that “going forward new features will be included in the Azure Information Protection unified labeling client whereas we’re not planning to add new features to the Azure Information Protection client”. In other words, future development efforts are focused on the unified labeling version, so tenants starting deployment projects today are strongly advised to use this version.

Encryption

One of the big features of rights management templates is the ability to protect content through encryption. The keys used for the encryption can be tenant-provided (BYOK or HYOK) or Microsoft-managed (MMK). In either case, the AIP client is responsible for encrypting content after an AIP or sensitivity label is applied to a message, document, or file. This is why you need to deploy AIP clients to workstations.

Native Support

It’s obviously inconvenient to have to deploy yet another client to user workstations. To make things easier, Microsoft is building native support for sensitivity labels (and encryption) into the Office ProPlus (click-to-run) desktop apps and the Office Online apps. Office mobile apps (Word, PowerPoint, Excel) also support the application of sensitivity labels today. Outlook Mobile can read protected content and will be able to apply sensitivity labels to new messages soon.

When the Office apps include native support for sensitivity labels, you won’t need to deploy the AIP client to get this functionality unless you intend applying labels to content stored outside Office 365, in which case you need an AIP license (available in P1 and P2 plans and as part of the Enterprise Mobility + Security suite or Microsoft 365 Enterprise plans).

Summing Up

Most organizations have a mixture of content that needs to be protected inside and outside Office 365. The unified labeling version of the AIP client delivers this functionality today. In the future, native support in the Office apps will create a more integrated solution for Office content, but you’ll still need to deploy an AIP client to handle content stored in file servers and other non-Office 365 locations.

Still confused abut AIP, labels, encryption, and Office 365? We suggest you read Chapter 24 of the Office 365 for IT Pros eBook where this topic is covered in detail.

More Progress towards Enabling Sensitivity Labels

Along with announcing its intention to include licenses for Information Protection in Office 365 E3 and E5 plans, Microsoft made further progress to encourage widespread use of Office 365 sensitivity labels by upgrading policies to include some auto-label capabilities and shipping an update for the “unified labeling” preview for the Azure Information Protection (AIP) client.

The biggest barrier for adoption for sensitivity labels today is lack of support in Office apps (desktop, mobile, and online) for the labels. To bridge the gap until General Availability (expected later this year), Microsoft released a different version of the Azure Information Protection client. The “unified labeling” version reads label and policy information from Office 365 (sensitivity labels and policies are found in the Security and Compliance Center) instead of Azure. The unified labeling client has just been updated and can be downloaded here.

Some Work Still to do for Sensitivity Labels

The preview of the unified labeling client (V2.0.747.0 ) only works for Windows workstations. When installed, the unified labeling client adds a Sensitivity button to the Office desktop apps. By comparison, the regular version of the AIP client adds a Protect button. Both buttons serve the same function. They display a list of all the labels available to the user (from all applicable policies) to allow them to select which label to apply to a message or file.

Long term, the Office apps will have native (in-built) support sensitivity labels and you won’t need to deploy any other software to apply labels and have them mark and protect (encrypt) content. The idea is that you should be able to apply labels to Exchange Online messages (with OWA and Outlook) and files stored in SharePoint Online and OneDrive for Business.

I also expect Microsoft to overhaul the the limited (and old) support for rights management in SharePoint Online to make it easier for site owners to apply default labels. Some work also needs to be done to update the SharePoint Online and OneDrive for Business web apps to allow users to apply sensitivity labels, probably in much the same way as they can apply retention labels today.

Once sensitivity labels are fully deployed inside Exchange Online and SharePoint Online, it is reasonable to anticipate that Microsoft to enable support for sensitivity labels to other Office 365 apps.

Because Office 365 sensitivity labels and Azure Information Protection labels share common underpinnings, sensitivity labels can also be applied to files outside Office 365, in which case they act like AIP labels.

Auto-Label Settings for Sensitivity Labels

Office 365 administrators are used to the concept of using auto-label policies to assign retention labels to content discovered by background processes to match conditions set in a policy. Sensitivity labels have their own take on auto-labeling. Briefly:

• Auto-label conditions are set for a label instead of by policy.
• Matching is only possible against Office 365 sensitive data types. Auto-label policies for retention labels can also match against keywords.
• Applications that support sensitivity labels action the label settings when they detect matches. For instance, if you create a Word document and include a credit card number, the match is detected when the document is saved and the (AIP) client executes the auto-label action. In the example below, the action is to apply the label.

This form of auto-labeling has been supported by AIP labels for a couple of years, so its appearance inside Office 365 is evidence of the work going on to create functional equivalence between AIP and sensitivity labels.

Note that auto-label is a premium feature that requires Azure Information Protection P2 licenses. In the world of Office 365, it’s likely that access to this functionality will be controlled by the new Information Protection for Office 365 -Premium licenses in Office 365 E5 or the Advanced Protection and Compliance SKU.

Need more information about Sensitivity Labels and Encryption through rights management in Office 365? Head over to the Office 365 for IT Pros eBook and read Chapter 24!

Preparing for Office 365 Sensitivity Labels

Microsoft’s 15 February announcement (MC173614) that they are updating the Office 365 E3, E5, and Advanced Protection and Compliance SKUs to include new Information Protection service plans might have surprised some. After all, Office 365 E3 and E5 tenants are already automatically enabled for rights management and can use the feature to protect email and documents.

What’s happening is that Microsoft is clearing the decks to prepare for the general availability of Office 365 sensitivity labels and the predictable rise in interest about protecting Office 365 content, especially that stored in Exchange Online, SharePoint Online, and OneDrive for Business. It’s also likely that Microsoft will extend the reach of sensitivity labels to other Office 365 apps, including Teams.

Azure Information Protection Licenses

Today, a lacuna exists in licensing terms. Azure Information Protection (AIP) is the technology built on top of rights management. AIP labels can apply protection (encryption) or just mark content (for instance, with a footer). AIP labels can be used to protect content stored inside Office 365, but no integration exists between these labels and Office 365 apps because the predominant use of AIP labels is to mark content stored outside Office 365.

To use AIP labels to protect content, you need an AIP license. The license comes in two forms – standard and premium. The premium license covers automatic labeling, where applications like Word and Excel can apply labels based on content detected in files. Sensitivity labels support automatic labeling (enabled in the latest preview of the AIP client), and I anticipate that this will be a premium feature.

Clarifying Office 365 Licensing

Up to now, it has been assumed that because Office 365 E3 and E5 tenants are automatically enabled for rights management, their existing licenses cover protection applied by sensitivity labels. The new service plans clarify the matter. Although Microsoft’s announcement isn’t clear on the point, it seems logical that Office 365 E3 will include Information Protection for Office 365 – Standard in its list of service plans and Office 365 E5 will include Information Protection for Office 365 – Premium. This approach clarifies the licensing issue and allows for premium features like automatic labeling to be restricted to the higher Office 365 E5 SKU.

Because Information Protection is a separate service plan within a SKU (like Yammer or To-Do), you will be able to selectively enable or disable it for users. For instance, you might not want some people to apply sensitivity labels until they receive training and understand how protection works.

You don’t have to do anything to prepare for the change. The new service plans will turn up in March and once they appear in your tenant, you can enable or disable Information Protection for accounts through the Office 365 Admin Center or PowerShell.

For more information about Information Protection, read Chapter 24 of the Office 365 for IT Pros eBook. There’s lots of stuff there about encryption, rights management, templates, and AIP.

Taping Office 365 Exposed

This week I have been in Palma de Mallorca to attend an event. Fortunately, fellow MVPs Paul Robichaux and Vasil Michev were also in town and we got to record an episode of the Office 365 Exposed podcast. Paul is editing the content and we should have it online soon. Stay tuned.

Exchange 2010 Was The Best

One of the issues we discussed was the impending unsupported status for Exchange 2010, which I also covered in a Petri.com article. I think that Exchange 2010 was the most important release on a technical level because of its impact on Office 365. Others argued for Exchange 5.5 (too old to be considered), Exchange 2000 (the release that embraced Active Directory), and Exchange 2007 (the first to use PowerShell). All in all, I’m happy to stay with my position that the DAG, RBAC, Native Data Protection, and MRS were huge steps forward and make Exchange 2010 the champion of all releases.

Scanning for Sensitive Documents

We also talked about the growing use of encryption in Office 365. Microsoft IT published an interesting case study about their use of the Azure Information Protection scanner to look for and protect sensitive content stored in on-premises repositories like file shares. It’s worth a read. The scanner can be expensive to deploy, but it’s much more effective than human checking of file shares and SharePoint on-premises libraries.

Also in the world of Azure Information Protection (AIP), the latest client (1.41.51.0) protects PDFs using the industry standard. Microsoft updates the AIP client regularly and you need to keep an eye on what’s changed in each release. The development team runs a Yammer group that is open to all. You might like to join it.

Bad Teams

On the Teams front, some reports have come in to say that the Get-Team cmdlet isn’t working as well as it should. The symptom is that some teams don’t show up in PowerShell or the Graph but do in the Teams client, which is confusing. Microsoft is doing some background processing to update the properties of older teams to make them behave as they should. Apparently, the process will be complete soon!

AvePoint’s #ShiftHappens Event

I received an invitation to speak at the first AvePoint #ShiftHappens conference (Washington DC, June 12-13). At this point, I don’t know exactly what I’ll talk about (except that it will be linked to Office 365), but I’m looking forward to visiting DC again. It’s been a while since I worked there on projects like the deployment of ALL-IN-1 at the U.S. Treasury and Exchange at the U.S. Senate. Happy Days…

Outlook Mobile for the Government

I’m sure that the folks working in DC were interested to read that Outlook mobile meets the needs of people with the highest Federal security and compliance requirements. Unfortunately, these folks seem to be limited to S/MIME instead of the rights-management based encryption available to other Office 365 customers. I guess some more work is needed to qualify this kind of encryption for government use.

Outlook mobile can consume rights-management based protection today (in Microsoft terms, it is an “enlightened” client) and the Office 365 roadmap includes the ability for Outlook mobile to apply sensitivity labels in Q2 CY19. See this Petri.com article for more information on sensitivity labels.

Book Update Coming

Stay tuned for an update for the Office 365 for IT Pros eBook next week.
The writing team is working hard to update chapters and if all goes well, we should publish on January 21 and have updates available in EPUB, PDF, and Kindle formats available then.

The advent of sensitivity labels within Office 365 should lead to more use of rights management to protect email and documents. Rights management uses encryption to enforce the permissions assigned to those who receive information. Microsoft automatically enables rights management for Office 365 E3 and E5 tenants and email can be protected without making any further changes using the Encrypt-Only and Do Not Forward templates.

The downside of using rights management to protect documents stored in SharePoint Online and OneDrive for Business libraries is that indexing cannot process encrypted content. The metadata (properties) of encrypted documents are processed and included in the indexes, but the actual content inside the Word, Excel, PowerPoint, or PDF files are not.

Encryption Blocks Some Office 365 Features

The lack of indexing means that any Office 365 feature which depends on the SharePoint indexes don’t work with encrypted documents. You can’t find documents using SharePoint or Delve searches, and you can’t find them with Office 365 content searches. That is, unless the metadata of the encrypted files contains the keyword you use for the search. If this is the case, the search succeeds because the metadata is included in the index.

The situation is different with Exchange email because Exchange is able to decrypt protected messages and include them in the index.

A Search Example

Take the example where we have:

• A protected email sent to one other recipient in the tenant. The search keyword is in the body of the message.
• A protected Word document with the search keyword in the body of the file.
• A protected Word document with the search keyword in the body of the file and in one of the document properties (like the Title or Comments).

When we search, we should find two copies of the message (from the mailboxes of the sender and the recipient) and the second Word document (based on the metadata). The first Word document remains invisible to search because the information we search for is in the encrypted body. The content search shown below illustrates the point. We can see the two messages and single document.

If you do unearth some encrypted content  in a content search, you can decrypt protected email during the export process, but encrypted documents are exported intact. This means that you must decrypt those files to allow investigators to review their content (I describe how in this Petri.com article).  

Microsoft to Improve Situation?

Microsoft is doing a great deal to make encrypted content easier to generate within Office 365. It will take time for tenants to understand and adopt functionality like sensitivity labels, but it will happen. Hopefully, we’ll see an improvement in the discoverability of protected documents in SharePoint and OneDrive. 

For more information about sensitivity labels, see Chapter 24 of the Office 365 for IT Pros eBook. Content searches are covered in Chapter 20, and Delve is in Chapter 9.

Sensitivity Labels are a Game Changer

Today’s Petri.com post discusses the use of Microsoft 365 sensitivity labels through an updated set of Office desktop applications coming soon. A previous post reviewed the migration from Azure Information Protection (AIP) labels. Of course, you can create and deploy sensitivity labels to protect Exchange and SharePoint content without going anywhere near AIP. In the long term, AIP labels are only needed if you want to protect content that isn’t stored inside Office 365.

The important point is that AIP labels and sensitivity labels share a common foundation in the Azure Information Protection service and the set of rights management templates published through that service. Both update the same file metadata and both use the same permissions.

Rights management has been around for a long time. I think the technology got a bad rap because it was deemed complex and unwieldy.  Sensitivity labels change the dynamics because they are easy to create and publish, and easy for users to apply to Office documents stored inside SharePoint and to email sent by Exchange Online. For these reasons, sensitivity labels will make protection through rights management and encryption a daily part of Office 365 life.

Rights and Permissions

Protection means that a user cannot access content unless they have the rights to do so. Furthermore, once a user accesses content, the permissions assigned to them (the rights) dictate what they can do (print, edit, forward, reply, etc.). Protecting documents and email gives authors confidence that they control that content. For instance, adding a new recipient to a reply to protected message is useless from the perspective of that recipient because they don’t get the right to open the content because they’re not in the set assigned to the original message. All in all, protecting Office 365 content is a good thing.

The Downside of Protection

Even good technology can have its downside and protection is no different. Once you protect a document, you lose some functionality. The biggest issue is that Office 365 cannot search the content because it can’t decrypt the content to index it. This means that content searches and eDiscovery must rely on document metadata for its indexes. If users populate the metadata with terms that search can use to find documents, it might not be so much of a problem. But users are humans and humans often don’t do such a good job with metadata.

Of course, if a content search finds some protected content, you then face the further difficulty of what to do with it. Investigators might want to review the content to check whether it’s needed for eDiscovery purposes, but the content is encrypted. The solution is to use super-user privilege to decrypt the content. A technical solution exists, but dealing with encrypted files can be painful.

ISVs and Protection

In addition to the issues thrown up inside Office 365, any ISV who deals with Office 365 content needs to understand if the advent of sensitivity labels and increased use of rights management within Office 365 impacts their product. If a product depends on gaining access to content, it’s going to run into a brick wall when it tries to access protected content.

No Argument Against Protection

You can’t really argue against the goodness of securing access to confidential information. Sensitivity labels give users control over their information, and they should know what’s confidential and needs to be protected. Some user education is needed to ensure that everyone knows how best to use the range of visual markings and protection available through sensitivity labels, but overall, this is a very good feature that’s arriving into Office 365.

To read more about sensitivity labels, rights management, and encryption, go to Chapter 24 of the Office 365 for IT Pros eBook.

Reporting Files with Labels

Let’s assume that your users have applied Azure Information Protection or Office 365 sensitivity labels to a bunch of documents. How can you create a report of files to know which files are labelled and protected?

PowerShell to the Rescue

As it turns out, you can use PowerShell to examine the Azure Information Protection properties of files and extract the necessary information and use that to create our report. As always, an example helps to illustrate the point.

This PowerShell script looks for any Excel and Word documents in a folder (which could be a folder holding files copied by the OneDrive sync client from a SharePoint Online or OneDrive for Business document library). Each file is checked for the presence of an Azure Information Protection (AIP) or Office 365 sensitivity label (the same metadata is used). You need to be a tenant or AADRM administrator to be able to run the code.

$Report = @()
$Files = (Get-ChildItem -Path "c:\temp\" -Include *.docx, *.xlsx -Recurse)
ForEach ($F in $Files) {
$FileName = "C:\Temp\" + $F.Name
$TemplateName = $Null
$Status = (Get-AipFileStatus -Path $FileName)
 If ($Status.IsLabeled -ne $False) {
 If ($Status.RmsTemplateId -ne $Null) {
    $TemplateId = [GUID]($Status.RMSTemplateId)
    $TemplateName = (Get-RMSTemplate -Identity $TemplateId.Guid ErrorAction SilentlyContinue ).Name }
    $ReportLine = [PSCustomObject]@{
         File        = $F.Name
         IsLabeled   = $Status.IsLabeled
         LabelId     = $Status.MainLabelId
         Label       = $Status.MainLabelName
         Date        = $Status.LabelDate
         RMSGuid     = $Status.RMSTemplateId
         RMSTemplate = $TemplateName
         Owner       = $Status.RMSOwner }
 $Report += $ReportLine
}}
$Report | Export-CSV -NoTypeInformation c:\Temp\LabeledFiles.csv

Outputting Details

If a file has a label, we extract details of the label and the underlying rights management template. One interesting thing that I discovered when writing the script is that the Get-RMSTemplate cmdlet fails when passed the GUID of a template used by an Office 365 sensitivity label. The GUIDs are correct, but for some reason the cmdlet fails. The output for an individual file that has a label with protection is:

File        : ABPs and Teams.docx
IsLabeled   : True
LabelId     : 81955691-b8e8-4a81-b7b4-ab32b130bff5
Label       : Secret
Date        : 13 Nov 2018 12:29:42
RMSGuid     : c7fc2174-097c-4123-9cad-15f1a32cb145
RMSTemplate : Secret
Owner       : Tony.Redmond@office365itpros.com

Script Output

The output for the script is a CSV file that can be opened and analyzed with Excel or Power BI.

This script is included in our coverage of protecting Office 365 content in Chapter 24 of the Office 365 for IT Pros ebook. There’s another 44 pages about protection to read there…

Protect but Don’t Block

Office 365 tenants who use Rights Management with Azure Information Protection (and use a cloud key rather than their own key, or HYOK) can now include the special Any Authenticated Users in the permissions configured for protection templates. Previously, you could only define permissions for users within the same tenant or named individuals in other domains *(using their email addresses). Any Authenticated User is a special permission which grants a set of permissions defined in a template to any user who authenticates by signing into:

• An Azure Active Directory account. For example, anyone in another Office 365 tenant.
• A Microsoft Services (MSA) account. For example, anyone who uses Outlook.com.
• A directory service federated with Azure Active Directory (like Google) or where a one-time passcode is used to access protected content. These types of protection are usually involved when sending email to recipients of non-Microsoft email services.

The intention behind the Any Authenticated Users permission is to give tenants a method to encrypt information sent outside the organization so that it is protected in transit and at rest while still supporting granular permissions and access control (such as expiration and offline access). In effect, you’re not worried about who opens the content if they can authenticate, but you still want some control over what they can do with the content.

Like the permissions assigned to individuals or groups, you can grant specific permissions to Any Authenticated User. For instance, you can stop people who use the permission from copying or printing the content. You can also track and revoke access to the content at any time.

Any Authenticated Users and Sensitivity Labels

As you might know, Microsoft is currently in the process of unifying protection labels as defined in the Azure Information Protection portal with Office 365 labels. This doesn’t mean that we will have a single set of labels. Rather, Office 365 will have two sets, both of which are managed through the Classification section of the Security and Compliance Center:

• Sensitivity labels, which apply protection and are shared with Azure Information Protection.
• Retention, which define for how long Office 365 keeps information like documents and email.

The migration of labels from Azure Information Protection to Office 365 is still a work in progress. Here’s what I report in Petri.com on the topic.  You can add the Any Authenticated Users to a template in the Azure portal and it will be synchronized to the Security and Compliance Center. However, you can’t yet add the permission to a label through the Security and Compliance Center.

For more information about rights management, read Chapter 24 of the Office 365 for IT Pros eBook.