Export Details of Disposition Review Items

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

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

Disposition Items

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

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

Exporting Disposition Review Items

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

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

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

Connect-IPPSSession

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

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

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

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

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

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

The Lesson of Export

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

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

Outlook Sensitivity Labels Processed in Different Ways

An observant reader noticed that Outlook clients encrypt messages using sensitivity labels in different ways. If you look at Figure 1, you see three messages sent to the same person using Outlook Mobile, OWA (or Monarch), and Outlook for Windows. The Ultra Confidential sensitivity label protects all messages with encryption, but only the copy sent from Outlook for Windows is protected in the sender’s mailbox. The other copies sent from Outlook Mobile and OWA are protected when they arrive in the recipient mailbox.

The obvious question is why this situation happens. Shouldn’t all Outlook clients produce the same result? Alas, this is not the case. As explained in Microsoft documentation, “When a sensitivity label is configured with encryption, the encryption process depends on the client platform.” In effect, Outlook desktop is the only client that contains the code necessary to encrypt an outbound message.

Other Outlook clients rely on passing messages through the Exchange Online transport service. The transport service has super-user capabilities and can apply the necessary protection. When transport detects that a message has a sensitivity label with encryption that isn’t yet protected, it does the necessary work to protect the message by placing the message and its attachments in a rpmsg “wrapper” before sending the message on to the next hop in its journey.

Client Processing for Protected Messages

The rpmsg wrapper is how Outlook sensitivity labels impose rights management for protected messages. The receiving client must unpack the message from the wrapper and respect the rights assigned to the recipient by the publishing license that’s included in the wrapper. The receiving client sends the publishing license to the information protection service to obtain a use license that allows the client to open the message.

Clients perform the processing to allow users to read protected messages without being prompted for credentials. If the client can’t obtain a use license, it displays information from the rpmsg to direct the user to the Office 365 Message Encryption (OME) Portal. If the user can prove their rights to open the message by signing into the OME portal with an account included in the recipient list, they can view the message contents online.

The reason why two out of the three messages are unencrypted in the Sent Items folder is that these are the messages that clients didn’t protect. Outlook desktop protected the other message before it submitted the item to transport. In

all cases, the sender can be confident that the message was fully protected when it left the transport service for onward routing.

Clients and the MIP SDK

Microsoft could incorporate the code (using the Microsoft Information Protection SDK) to protect messages in OWA and Outlook mobile. However, this approach doesn’t seem to make sense. Apart from the extra complexity introduced into the client code base, OWA can only be used online. Outlook mobile clients could protect files, but they usually work in a connected mode (either Wi-Fi or a cellular network). Outlook desktop has always been able to work offline, so its developers incorporated the code to process protected inbound and outbound messages when working offline.

Growing Use of Outlook Sensitivity Labels

The number of messages protected by Outlook sensitivity labels is steadily increasing. I do not have firm data to back this assertion, just anecdotal evidence from customer interactions. Microsoft continues to pour engineering effort into making sensitivity labels more accessible and useful, so I expect the trend to continue. And when your tenant starts to use sensitivity labels to protect email, you’ll know why some Outlook clients protect messages in a different manner to others.

Learn about using Exchange Online, Outlook clients, 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.

Block Download Policy covered by Syntex-SharePoint Advanced Management License

Microsoft launched the Syntex-SharePoint Advanced Management license into preview in late January 2023. The license is now generally available and cost $3/user/month. Since news about the license emerged, people have been figuring out if the features covered by the license are worth the cost by examining details of the features it enables. Now a new block download file policy is available for Teams meeting recordings.

Blocking Downloads and Teams Meetings

In February, I covered the Block Download Policy for SharePoint Online, a feature in Syntex-SharePoint Advanced Management to limit users to browser access when interacting with content stored in sensitive sites. Blocking downloads for Teams recordings is a similar feature that’s now available in preview. The big difference is that the block download policy applies tenant-wide for all Teams recordings created after the block comes into force in both SharePoint Online sites (for channel meeting recordings) and OneDrive for Business (for personal meeting recordings).

Clearly Microsoft is responding to a customer need to make Teams meeting recording more secure. Blocking downloads removes the worry that someone with access to a recording of a sensitive meeting can download it before the meeting file automatically expires.

Site-Wide Block Download Policy Applied With PowerShell

As noted above, the block is tenant-wide. No GUI is currently available in the SharePoint Online admin center, so management of the block is by running the Set-SPOTenant cmdlet from the SharePoint Online management module.

Make sure that you run an up-to-date version of the module (I used 16.0.23408.12000) as otherwise the Set-SPOTenant won’t support the necessary parameters. Keeping modules like Exchange Online management, Teams, SharePoint Online, and the Microsoft Graph PowerShell SDK up to date is an important task. Ideally, you should check and update modules monthly. As it’s always nice when PowerShell looks after PowerShell, here’s a script to automate the process, including tidying up by removing old module files afterward.

To impose the block, use Set-SPOTenant to set these parameters:

• BlockDownloadFileTypePolicy from $False (the default) to $True.
• BlockDownloadFileTypeIds to “TeamsMeetingRecording.” This is the only value currently supported by the cmdlet.
• ExcludedBlockDownloadGroupIds to the identifiers of security groups whose members you want to exclude from the block download policy. You can’t use Microsoft 365 groups to exclude accounts. This parameter can be left blank if you want the policy to apply to all accounts. If you want to specify multiple security groups, do so in a comma-separated list.

Here’s the command I ran in my tenant to enable the block policy and check its settings afterward:

Set-SPOTenant -BlockDownloadFileTypePolicy $True -BlockDownloadFileTypeIds TeamsMeetingRecording -ExcludedBlockDownloadGroupIds "dc637020-4b0f-4f65-bdf0-3c7dbe8a83e7"

Get-SPOTenant | Format-List BlockDownLoadFile*, ExcludedBlock*

BlockDownloadFileTypePolicy   : True
BlockDownloadFileTypeIds      : {TeamsMeetingRecording}
ExcludedBlockDownloadGroupIds : {dc637020-4b0f-4f65-bdf0-3c7dbe8a83e7}

It can take up to a day before a policy update becomes effective across SharePoint Online. Before it is effective, anyone can download a Teams meeting recording (Figure 1).

When the block download policy is effective, users don’t see the download options for recordings created after the effective date (Figure 2).

It’s important for users to understand that they are only blocked for new recordings. At least, while the feature is in preview. However, when the block download policy is generally available, a background agent will search for older Teams meeting recordings stored in SharePoint Online and OneDrive for Business and mark the files as blocked for download. Although I can see why customers would want this to happen, the fact is that many of the Teams recordings will age out and disappear in a relatively short period unless users take explicit action to retain the files.

Available in Preview Now

SharePoint Online’s block download policy for Teams recordings is available in preview. After Microsoft makes the block download policy generally available, you’ll need to buy some Syntex-SharePoint Advanced Management licenses to continue using the policy or the block download policy will stop working (perhaps much to the relief of some users!).

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

Sensitivity Bar Informs Users About the Labeling Status of Office Documents

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

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

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

Eliminating the Unified Labeling Client

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

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

Hiding the Sensitivity Bar

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

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

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

To check the setting, run:

Get-LabelPolicy | Format-List Name, PolicySettingsBlob

You should see the setting shown like this:

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

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

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

Useful Change for Those Interested in Sensitivity Labels

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

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

Syntex-SharePoint Advanced Management Covers Secure Collaboration for SharePoint Online

Updated 2 March 2022

I know that many Microsoft 365 organizations don’t use sensitivity labels, even if they have the necessary licenses to use labels to protect content. All Office 365 licenses allow users to read protected content, but you need Office 365 E3 or above to apply labels to files, and Office 365 E5 or Microsoft 365 Compliance E5 for auto-label processing. At least, that’s been the case up to now.

Applying a default sensitivity label for a SharePoint Online document library (Figure 1) counts as automatic processing. Apparently, Microsoft considers the fact that new and modified documents in the library pick up the sensitivity label (unless previously labeled) as reason enough. In late January 2023, Microsoft revealed that this feature was one of the set to be licensed through a new Microsoft Syntex-SharePoint Advanced Management license.

Features Enabled by the Microsoft Syntex-SharePoint Advanced Management License

The new license is in preview and includes other elements to improve secure collaboration based on SharePoint Online and OneDrive for Business, including:

• Using sensitivity labels with Azure AD authentication contexts to limit access to SharePoint Online sites. This feature has been in preview since 2021.
• Restricting access to a SharePoint Online site to members of a Microsoft 365 group. This restriction blocks users who have received access to a file in the site.
• Blocking the download of files from SharePoint Online sites or OneDrive for Business accounts without the need to use Azure AD conditional access policies. In other words, users are forced to use a browser to access the site or account and cannot download, print, or synchronize files. The restriction also blocks access to the Office desktop apps because these apps need to download files to work on them locally.

In addition, Syntex-SharePoint Advanced Management includes some management and governance features. The three examples cited appear to be instances where it’s possible for administrators to do the same thing with some effort. Microsoft is making it easier. For example, the ability to limit access to OneDrive for Business to those who are members of a specific security group stops people licensed to use OneDrive but who aren’t members of the security group from using the app. The same effect is possible by simply removing the OneDrive service plan from their assigned licenses.

I haven’t seen what actions are included in the feature to export recent SharePoint site actions, but it might be possible to replicate the functionality by fetching SharePoint management events from the unified audit log.

My assumption is that any user who takes advantage of a feature licensed by Syntex advanced management requires a license. For instance, site members of a site where a document library uses a default sensitivity label all require Syntex-SharePoint Advanced Management licenses.

I can’t find a public announcement by Microsoft about the Syntex-SharePoint Advanced Management license. Cynics will say that this is another example of how Microsoft creates licenses for new functionality to generate additional revenue from its installed base. A more benign view is that the new license allows people with Office 365 E3 licenses to use the security and governance features enabled by Syntex Advanced Management. When I find out more details about licensing, including if some features covered by Syntex Advanced Management are also available through other licenses, I shall share the information.

Viewing Metadata for Protected Files

On an associated topic, I was asked why the metadata of documents protected by sensitivity labels remains visible to people who have no right to access these files. It’s a good question because some get confused when they notice an interesting document in a library but can’t open it because they’re blocked by the rights assigned in the label. For instance, who wouldn’t want to open a document with a title like “Proposed Pay Rises for Staff”?

When you enable SharePoint Online and OneDrive for Business to support sensitivity labels, it allows the workloads to deal with protected (encrypted) content. SharePoint Online stores protected files in an unencrypted format to allow functions like indexing and data loss prevention policies to work. Any access to a document, such as a user opening or downloading a file, causes SharePoint Online to encrypt the document so that the application used to open the file (like Word) can apply the rights assigned to the user. Everything works very nicely and those who have access to files can work with that content and those who don’t cannot.

When browsing items in a document library, site members can see metadata like the titles and authors of protected documents. Attempts to open these documents fail if the user doesn’t have the necessary rights. Because SharePoint Online doesn’t encrypt or obscure the metadata, those users know that documents with potentially very interesting content are available.

How SharePoint Online Stores Documents

The reason why document metadata is visible to all site members is rooted in how SharePoint Online stores documents. SharePoint Online uses Azure SQL as its storage platform. Blob storage holds documents and other files while metadata is in a separate table (list). The Azure SQL data is heavily protected against illegal access. Once a user has access to a document library, the assumption is that SharePoint can show them all the items, which is what they see in the list shown in a browser or the Teams files channel tab. It’s only when a user attempts to access a protected document that SharePoint Online validates their right to open that content.

You can argue that SharePoint Online and OneDrive for Business should hide the existence of protected documents that the user can’t open, but this would require SharePoint Online to check that access before displaying documents in a library. Such a check would incur a huge performance penalty because SharePoint Online cannot assume that the rights assigned in a sensitivity label are the same as the last time it checked.

New Functionality, New Costs

Although the news about the Syntex-SharePoint Advanced Management license will disappoint some, it’s reasonable that Microsoft should charge extra for security and management features that not every Microsoft 365 tenant will want or need. Those that need the functionality will simply have to pay the $3/user monthly cost. Hasn’t that always been the way?

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.

License Stacking Allows Workloads to Manage Multiple Licenses

The Exchange Online blog post of January 20 “Introducing Support for Concurrent Exchange Online License Assignments” caused some furrowed brows because on first glance it doesn’t seem like an important announcement. The impact of the change depends on the size of a Microsoft 365 tenant and the processes used for license management. If your tenant is small and licenses are relatively static, you can safely ignore this topic. But those who run large tenants and use features like group-based license assignments are likely to be much more interested.

License stacking means that an Azure AD user account can hold multiple licenses for the same workload. Some of the licenses might be inherited from products (SKUs) that bundle multiple service plans (a not-for-sale license included in a SKU). Others come from specific products or add-ons. For instance, an account might hold the Teams Exploratory license and also have a license for Teams through the Office 365 E3 or E5 SKUs. When license stacking is in place, the workload is responsible for resolving the capabilities made available through the different licenses and allowing the account access to the feature set available from the best (“most superior”) license. In the example above, Teams would respect the license from Office 365 E3 or E5 because it covers more functionality than the Teams Exploratory license.

Exchange Online Licenses

In the case of Exchange Online, four licenses are available:

• Exchange Online Essentials (BPOS_S_Essentials).
• Exchange Online Kiosk (BPOS_S_Deskless).
• Exchange Online Plan 1 (BPOS_S_Standard).
• Exchange Online Plan 2 (BPOS_S_Enterprise).

BPOS refers to Business Productivity Online Suite, a predecessor to Office 365 based on Exchange 2007.

Microsoft says that they have updated the Get-ExoMailbox (Get-Mailbox) and Get-Recipient cmdlets to give tenants insight into the Exchange capabilities assigned to accounts through the licenses assigned to the accounts. I found that the data isn’t fully populated for all mailboxes (this will happen over time). However, it’s possible to run a command like this to report assignments:

Get-Recipient -RecipientTypeDetails UserMailbox -ResultSize Unlimited | Format-Table DisplayName, RootCapabilities

DisplayName                             RootCapabilities
-----------                             ----------------
Tony Redmond                            BPOS_S_Enterprise
Ben Owens (DCPG)                        None
Andy Ruth (Director)                    BPOS_S_Standard, BPOS_S_Enterprise
James Ryan                              BPOS_S_Enterprise

The Ben Owens account is an example where the assignment information isn’t yet populated. The Andy Ruth account is an example where two licenses are in place that include an Exchange service plan (one for Exchange Online Plan 1, the other for Plan 2). In this case, because Exchange Online Plan 2 enables more functionality than Plan 1, it’s the one that Exchange Online respects.

Concurrent License Assignments for Exchange Online

Traditionally, Exchange Online has not supported license stacking, which means that an Azure AD account can hold a single Exchange Online license. Most of the time this doesn’t matter because the usual situation is for an account to receive an Exchange Online license through a product SKU. For instance, Office 365 E3 and E5 both include the Exchange Online Plan 2 service plan.

However, it’s possible that an account might start out with a Microsoft 365 Business Basic license that includes Exchange Online Plan 1. The account belongs to a user who’s promoted to a management position that the organization requires to come within the scope of a retention policy and have an online archive. These features require Exchange Online Plan 2, so the organization removes the Microsoft 365 Business Basic license and assigns the account an Office 365 E3 license.

Exchange Online mandates that all user mailboxes have licenses. When the organization removes the Exchange Online Plan 1 license from the account, a chance exists that Exchange Online might soft-delete the mailbox and make it unavailable. The mailbox becomes available again when the account gains the Exchange Online Plan 2 license through Office 365 E3, but it’s not a great situation to be in if a user loses access to their mailbox while license administration is in progress.

Why Exchange Online License Stacking is Helpful

Support for license stacking (multiple concurrent licenses) means that the organization can assign the superior license to the account before removing the other license. This might happen through an automated process. For instance, a group-based licensing assignment might occur and assign the license because of the user’s new job means that they join a group. Later, another process might remove the inferior license from the account to return it to the unused license pool. Automated license assignment by reference to a property of Azure AD accounts is very common, both through Azure AD group-based assignment and purpose-built license management tools. Organizations often go down this route because of the complexity that’s sometimes found in understanding the combinations and permutations available in Azure AD licensing.

Group-Based Licensing for All

In August 2021, as part of their announcement about the retirement of the license assignment cmdlets in the Azure AD and MSOL PowerShell cmdlets. Microsoft promised to remove the additional licensing requirement for group-based licensing. That hasn’t happened yet because Microsoft has had to delay the move to the new licensing platform for Microsoft 365.

The current schedule deprecates the licensing cmdlets on March 31, 2023, and perhaps this will mark the point when Microsoft allows everyone to use group-based licensing. If you haven’t already migrated PowerShell scripts that do license management to the Microsoft Graph PowerShell SDK, it’s time to get going.

Good Housekeeping Change

Microsoft is rolling stacked licenses support for Exchange Online in  the commercial clouds. Government clouds are next and will be done by the end of H1 2023. It’s not an exciting change, but it’s a good example of a housekeeping enhancement that will stop users losing access to their mailboxes due to internal license management.