No Remote PowerShell Connections for Compliance Endpoint

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

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

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

REST Rather than Remote PowerShell

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

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

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

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

Connect-IPPSSsession -UseRPSSession:$false

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

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

More to Do

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

Good Change

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

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

Export Details of Disposition Review Items

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

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

Disposition Items

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

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

Exporting Disposition Review Items

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

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

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

Connect-IPPSSession

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

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

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

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

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

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

The Lesson of Export

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

---

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

Sensitivity Bar Informs Users About the Labeling Status of Office Documents

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

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

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

Eliminating the Unified Labeling Client

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

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

Hiding the Sensitivity Bar

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

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

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

To check the setting, run:

Get-LabelPolicy | Format-List Name, PolicySettingsBlob

You should see the setting shown like this:

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

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

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

Useful Change for Those Interested in Sensitivity Labels

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

---

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

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

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

Communication Compliance Basics

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

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

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

Teams Report a Concern

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

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

Get-CsTeamsMessagingPolicy | Format-Table Identity, AllowCommunicationComplianceEndUserReporting

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

Reviewing Reported Messages

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

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

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

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

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

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

Keeping Things Clean

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

---

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