Find and Update Apps to Run Teams PowerShell

When message center notification MC1134747 first appeared on 13 August 2025, a slew of poorly-grounded commentary ensued. Microsoft updated the content on 2 September 2025, and hopefully the same kind of overreaction won’t happen again.

The post describes a new authentication requirement for Entra ID apps that use the Teams PowerShell module to run Teams cmdlets without the presence of a signed-in user. For example, a tenant might have an Azure Automation runbook that uses cmdlets from the Teams PowerShell modules to process actions such as reporting team structures (channels, apps, etc.) and membership.

I’m sure that most of the previous fuss and bother was generated because Microsoft labelled this change as an important security and authentication update. In reality, the change is only important if a tenant has apps that call the Teams PowerShell module to interact with Teams.

Authentication is involved because the apps now two additional Graph application permissions. The RoleManagement.Read.Directory permission is used to validate if the app can read information about Entra administrative units, and the GroupMember.Read.All permission is needed to read group membership if the app calls the Group Policy Assignment and Group Policy Package Assignment cmdlets.

Respecting the boundaries of Entra administrative units is important and justifies the statement that this change strengthens security. You don’t want unauthorized apps to read information about teams governed by administrative units.

It doesn’t take much to add these permissions to an Entra ID app and any tenant affected by the update should find that it takes little time to address the problem.

Finding Entra ID Apps that Use the Teams PowerShell Module

The first step is to discover if any Entra ID apps are in the tenant that use the Teams PowerShell module. One way to check is to find which apps have been assigned the Teams service administrator role. Apps don’t need the Teams administrator role unless they’re going to sign into Teams in app-only mode to run Teams cmdlets, so the presence of the role assignment for an app is a good litmus test.

With a good repository of PowerShell scripts for Microsoft 365 to call upon, we can steal some code from the script used in the article describing how to report PIM role assignments and repurpose it as follows:

$TeamsAdminRole = Get-MgDirectoryRoleTemplate | Where-Object {$_.displayName -eq "Teams administrator"} | Select-Object -ExpandProperty Id
[array]$ActiveAssignments = Get-MgBetaRoleManagementDirectoryRoleAssignmentSchedule -Filter "(RoleDefinitionId eq '$($TeamsAdminRole)')" -ExpandProperty RoleDefinition, Principal, DirectoryScope -All

$Report = [System.Collections.Generic.List[Object]]::new()
ForEach ($Member in $ActiveAssignments.Principal.Id) {

  $SP = Get-MgServicePrincipal -ServicePrincipalId $Member -ErrorAction SilentlyContinue -Property Id, displayName, AppId, ServicePrincipalType, Owners
  
  If ($SP) {
      $ReportLine = [PSCustomObject]@{
        SPIdentifier = $SP.Id
        Name         = $SP.DisplayName
        AppId        = $SP.AppId
        Type         = $SP.ServicePrincipalType
      }
      $Report.Add($ReportLine)
      } # End if
}

The output looks like Figure 1. It’s raw, but it’s enough to advise which apps need attention.

Reporting Holders of The Teams Administrator Role

Proving that there’s usually many ways to do something in PowerShell, this code reports all the holders of the Teams administrator role, including users, groups, and service principals (apps or managed identities).

$Report = [System.Collections.Generic.List[Object]]::new()
Get-MgRoleManagementDirectoryRoleAssignment -Filter "roleDefinitionId eq '$($TeamsAdminRole)'" |
ForEach-Object {
     $Principal = Get-MgDirectoryObject -DirectoryObjectId $_.PrincipalId
     Switch ($Principal.AdditionalProperties.'@odata.type') {
       "#microsoft.graph.user" {
         $ObjectType = "User account"
       }
       "#microsoft.graph.group" {
         $ObjectType = "Group"
       }
       "#microsoft.graph.servicePrincipal" {
         $ObjectType = "App or managed identity"
       }
     }

     $ReportLine = [PSCustomObject]@{       
        PrincipalName    = $Principal.AdditionalProperties.displayName
        PrincipalType    = $ObjectType
        Scope            = $_.DirectoryScopeId
        Id               = $_.PrincipalId
        RoleAssignmentId = $_.Id
    }
    $Report.Add($ReportLine)
}

Updating Entra ID Apps with the Permissions Needed to Run Teams Cmdlets

The point is that there’s no problem discovering what apps need to be updated, and if you want to use PowerShell to add the missing permissions, that’s easily done too. First, extract the list of service principal identifiers from the report:

[array]$Apps = $Report | Where-Object {$_.PrincipalType -eq 'App or Managed Identity'} | Select-Object -ExpandProperty Id

Now loop through the identifiers to assign the permissions now required to run Teams PowerShell cmdlets:

[array]$Permissions = "RoleManagement.Read.Directory",  "GroupMember.Read.All"
# Get Graph app details
$GraphApp = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'"

# Loop through each app and assign the permissions to the app
ForEach ($App in $Apps) {
  # Loop through each permission and assign it to the target
  ForEach ($Permission in $Permissions) {
     $Role = $GraphApp.AppRoles | Where-Object {$_.Value -eq $Permission}
     $AppRoleAssignment = @{}
     $AppRoleAssignment.Add("PrincipalId",$App)
     $AppRoleAssignment.Add("ResourceId",$GraphApp.Id)
     $AppRoleAssignment.Add("AppRoleId", $Role.Id)
     # Assign Graph permission
     Try {
       New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $App -BodyParameter $AppRoleAssignment -ErrorAction Stop
     } Catch {
       Write-Host ("Unable to assign {0} permission to service principal {1}" -f $Permission, $App)
     }
  }
}

No bother, no fuss, just some extra permissions assigned to Entra ID apps that need to run cmdlets from the Microsoft Teams PowerShell module.

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

Copilot Memory and Copilot Communication Memory or Live Memory

On August 6, I reported about Copilot Memory, a way for users to personalize how Microsoft 365 Copilot responds to prompts. The article mentions message center notification MC1127234 (1 August 2025). In the text I noted some conflicts between the reported dates in the Technical community post about Copilot Memory and MC1127234.

As it turns out, some confusion existed about what Microsoft described in the message center notification because it doesn’t refer to the Copilot Memory feature. Instead, MC1127234 discusses Copilot “communication memory,” or information derived from a user’s personal communication used by Microsoft 365 Copilot to deliver better results to user prompts.

On August 29, 2025, Microsoft reissued MC1127234 (Microsoft 365 roadmap item 499153) to clarify what they meant, saying that the restatement was due to customer feedback, and because the change requires new processing of user data.

Learning to be More Context-Aware from User Communications

The updated text describes an “extended capability” for how Microsoft 365 Copilot gleans information about what’s important to a user from their chats, emails, and meetings. In other words, Copilot learns about what people do from the information contained in the Microsoft Graph and uses that information (referred to as “memories”) to deliver more personalized and “context-aware” responses to user prompts. “Live memories” (the same as communication memory) for individual users are formed by using AI to analyze and summarize the information held in items accessible to individual user, like transcripts from meetings they attend.

Easy as it is to become confused with so many references to different types of memory, the serious point is that communication memory is “a unified view across communication channels.” In other words, where Copilot integration in Microsoft 365 apps used to focus exclusively on information from a specific app, now Copilot draws in information from multiple sources to create a more rounded picture. For instance, the Facilitator agent in Teams operates on messages posted to a chat. With communication memory, the agent can refer to other sources available through the Graph (like previous emails between the chat participants) to deliver better advice.

People-Related Questions First

Microsoft says that Copilot communication memories will initially be used to improve the quality of Copilot responses to people-related questions. I guess this means that if you include someone’s name in a Copilot prompt, it will automatically query the Graph to find out if any information associated with that name is available to help frame its response. The new mode of processing started on September 1, 2025. However, complete worldwide deployment is not expected to be complete until late October 2025.

Making Microsoft 365 Copilot A Bit Smarter

Anything that helps AI to do a better job is welcome. In this case, it seems like Microsoft is expanding the horizon of what Copilot looks for when it assembles information to answer a question from the limit of a single app to a more-encompassing view of what’s available to a user in the Graph. That’s a good idea.

Of course, the normal caveats over anything to do with AI applies. Copilot communication memory depends on what Copilot can find, and if the information in the Graph is inaccurate, obsolete, or just plain wrong, then the advice informed by memory could be affected. Microsoft notes that citations (source links) are provided for each source mentioned in a response (Figure 1). Quite how often people check out every citation for a Copilot response is quite another matter. Sometimes, any answer will do.

Learn more about how the Microsoft 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.

Monthly Update #123 Available for Download

The Office 365 for IT Pros author team is pleased to announce the release of the September 2025 update for the Office 365 for IT Pros eBook (2026 edition). As always, subscribers can download the latest EPUB and PDF files from Gumroad using the personalized link included in their original purchase receipt. The Automating Microsoft 365 with PowerShell eBook has also been updated (now at version 15.2), and you can download files for that update from the same place. See our FAQ for more information about downloading updates.

As always, the September 2025 update reflects our ongoing commitment to keeping IT professionals informed and equipped with the most current guidance for managing Microsoft 365. The September release includes updates across almost every chapter, covering recent changes in Teams, SharePoint Online, Exchange Online, and Microsoft 365 security and compliance.

The Microsoft Defender for Office 365 Licensing Question

The most popular articles on the Office365itpros.com site in August were the two-part series covering licensing of shared and user mailboxes when Microsoft Defender for Office 365 (MDO) is active in a tenant. In a nutshell, once MDO is in a tenant, Microsoft requires all user mailboxes and all shared mailboxes to have MDO licenses (or rather, the accounts owning these mailboxes).

By comparison, group mailboxes don’t need MDO licenses, even though they receive exactly the same level of protection from MDO. This inconsistency might exist because Microsoft wants tenants to use group mailboxes instead of shared mailboxes, or it could simply be an oversight.

In any case, the articles sparked quite a debate. Some people felt that we should have left sleeping dogs lying and not mentioned the issue at all. Others told me about true-up exercises done by Microsoft when account teams told customers that they’d have to pay for MDO licenses. To their credit, the MDO team took the criticism to heart and internal discussions are happening within Microsoft. We await the results of those talks and hope that Microsoft will do the right thing and restore consistency and fairness (and not by charging all and sundry for MDO licenses).

Hybrid Connectivity

Relatively few active Exchange mailboxes are now on-premises. Most are now online. There’s no formal count from Microsoft to back this hypothesis, but the numbers of Microsoft 365 paid seats (the latest figure is “over 430 million”), most of whom use Exchange tell a story.

Hybrid organizations with mailboxes remaining on-premises need to transition to a dedicated hybrid connectivity app. Microsoft is making noises that the pace of switchover is slower than they’d like. Perhaps this is something that’s on the “must do when I return from vacation” list for tenant administrators. If it is, make sure that the dedicated hybrid connectivity app is in place in good time before Microsoft switches off EWS (for its own apps) in October 2025.

Come to TEC to Meet Office 365 for IT Pros Authors

If you’re looking for an autumn conference to refresh your knowledge about topics like Entra ID and Microsoft 365, why not come to The Experts Conference (TEC) in Minneapolis (Sept 30-Oct 1), where authors Tony Redmond, Paul Robichaux, and Michel de Rooij will present on automation and scripting best practices. You’ll also see a tremendous line-up of Entra ID talent, as noted by the irrepressible Merill Fernado in this LinkedIn post. To make it even easier for you, here’s a code with a nice discount for TEC.

On to Update #124

As Microsoft 365 continues to evolve, staying current is essential. The Office 365 for IT Pros eBook remains the definitive guide for Microsoft 365 tenant administrators navigating this fast-moving landscape. Whether you’re focused on automation, compliance, or hybrid deployments, this update ensures you have the latest insights at your fingertips.

If you haven’t yet upgraded to the 2026 edition, now’s the time—renewing subscribers get a discount, and the pace of change isn’t slowing down.

Hiding Inactive Channels Automatically was a Terrible Idea

One of the oft-repeated tropes about Microsoft is that they need several attempts to get software right. This might certainly be true for the Teams feature designed to help users focus on active work by hiding unused channels. First introduced in Fall 2024 with the aim that: “Teams will automatically detect inactive channels you haven’t interacted with in a while, and automatically hide them for you,” the feature soon ran into problems. Initially, Microsoft said that Teams will automatically detect inactive channels that a user hasn’t interacted with for 45 days. The number was revised upward to 120 days in MC804771 (March 21, 2025). Apart from these statements, Microsoft hasn’t given any further details about the criteria used to determine the level of activity needed to regard a channel as active.

The way that Teams suppressed notifications from hidden channels didn’t help either. Although cleaning up a channel list to highlight active channels might be a good idea, it’s not so good when someone misses an important notification about an event posted in a channel that’s inactive because it’s reserved for discussing critical issues.

Offering Suggestions about Channels to Hide

Microsoft duly reversed course and acknowledged that automatically hiding inactive channels without user oversight was a bad idea. They promised to clean up the mess by announcing in MC804771 that Teams would offer suggestions about inactive channels and leave it to users to decide if the suggestions are valid and should be accepted.

Six months later, MC1141958 (25 August 2025, Microsoft 365 roadmap item 325780) announces that the update to give user control over hiding inactive channels is available in targeted released and will be generally available very soon. You’ll know if the update is available by checking the Settings app to see if the control for hiding inactive channels now mentions “suggestions” (Figure 1).

Opting for Get suggestions now forces Teams to show its current list of inactive channels. When I chose the option, it revealed five channels (Figure 2). The interesting thing is that similarly inactive channels in the same teams are not in the list. This underlines the general lack of information available from Microsoft about how Teams chooses inactive channels.

Automatic Maintenance and Coach Mark Messages

If the setting to hide inactive channels is On, Teams performs a periodic check to find channels that could be hidden. This doesn’t happen when a user has less than or equal to 25 visible channels.

If Teams finds some inactive channels, it notifies the user with a “coach mark message.” I was unfamiliar with this term, but apparently a coach mark is a user interface element intended to educate users about a new feature. Now that I know what these messages are called, I’ll stop referring to them as the annoying pop-up messages that infest Teams (or maybe not, because the overuse of these messages is still annoying especially when there’s no way to turn them off).

In any case, the message will prompt the user with “Looks like you haven’t visited some channels lately. Hide them to help you focus.” If the user opts to be distracted from doing whatever they were busy with before Teams launched its coach mark, they see the same dialog as shown in Figure 2.

There’s no administrative control over the hiding inactive channels feature. Its only control is at user level through the Settings app.

Hurrah for Sanity

The simple fact is that sanity has now been restored to the attempt to unclutter user views by removing inactive channels. Software, even Copilot at its best, has a hard job of understanding why some channels exist and how people use those channels. Given that a single team can support up to 1,000 channels, some inactive channels are likely to be floating around in everyone’s client. Making polite suggestions that some channels can be hidden is a much better approach than automatic clean-up, especially when the criteria used to select inactive channels are so fuzzy.

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

Releasing Features like Summarize Email Thread without Microsoft 365 Copilot Licenses is Just Business

Those who are surprised by Microsoft making Copilot features in Office to users without a Microsoft 365 Copilot license don’t understand that it’s simply a matter of business. If Microsoft doesn’t make basic AI features available within Office, ISVs will fill the vacuum by selling add-ons to integrate ChatGPT or other AI with Outlook. If customers buy ChatGPT integrations, it removes opportunity for Microsoft to sell Microsoft 365 Copilot licenses.

Message center notification MC1124564 (updated 12 August 2025, Microsoft 365 Roadmap item 498320) is a good example. This post announces that the option to summarize email threads will be available in Outlook even for users without a Microsoft 365 Copilot license provided Copilot chat is pinned to the navigation bar. The feature is available in Outlook Classic (subscription version), the new Outlook for Windows, and OWA if they have enabled Copilot chat by pinning the app to the navigation bar. This option is controlled by a setting in the Copilot section of the Microsoft 365 admin center (Figure 1).

Targeted release users should see the feature between late August 2025 and mid-September 2025, with general availability following in between mid-September and mid-November 2025.

Summarizing Email Threads

Generative AI always creates the best results when it has a well-defined set of data to process. Just like users who have Microsoft 365 Copilot licenses, Outlook users without a Copilot license will see a Summarize button in the reading pane. Choosing the option calls Copilot to process the email thread to create a summary by extracting the most important points from the thread. Even in a single-item thread, summarization can be valuable by confirming critical issues raised in a message.

Summarizing an email thread doesn’t include other Copilot features like summarizing attachments for a message.

The Business Question

If Microsoft didn’t offer thread summarization in Outlook, customers can find the same functionality available in ISV offerings such as AI MailMaestro (ChatGPT for Outlook), available in the Microsoft app store, which includes the ability to summarize “any email for immediate thread analysis and key points” at a price point where “Copilot is 2.5x more expensive than MailMaestro.”

This is not the only example of an Outlook add-in for ChatGPT (here’s another picked at random). OpenAI has their own connector for Outlook email (and others for Outlook calendar, Teams, and SharePoint Online). Using add-ins and connectors creates security, app management, and compliance questions for Microsoft 365 tenants, but some organizations are happy with the trade-off to gain AI features at reduced cost.

No doubt Microsoft will emphasize to customers that their version of the OpenAI software is specially tailored to the demands of Microsoft 365 in a way that a general-purpose LLM cannot be. However, price is a powerful influence and ChatGPT is a very popular solution.

From a Microsoft perspective, if customers embrace OpenAI-based third-party solutions and deploy add-ins or connectors to extend the Office apps, Microsoft loses some degree of account control and their potential to sell Microsoft 365 Copilot licenses is reduced. Neither outcome is an attractive prospect, especially in large enterprise accounts.

In the context of wanting to protect the Office franchise, it’s understandable why Microsoft should make a limited subset of AI-driven features available to users of the Microsoft 365 enterprise apps (subscription version of Office). Apart from making third-party offerings less attractive, getting Copilot’s proverbial foot in the door is likely to encourage investigation of other Copilot functionality like email prioritization that might lead to future purchases.

Raising the Ante

I’ve nothing against Microsoft adding features to Outlook where it makes sense. Summarizing email threads is an example of where everyone can gain from AI, so it seems sensible to add it to Outlook. The fact that adding the feature helps Microsoft to compete with ISVs might seem regrettable, but it’s just business.

In some scenarios, adding features like this might be deemed anti-competitive, but there is plenty of room for ISVs to compete with Microsoft to exploit AI, and including basic features like summarization rapidly becomes the ante to participate in the market.

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

Copilot Audit Records Record Details of SharePoint Online Files Referenced by BizChat

Despite the launch of Microsoft 365 Copilot in March 2023, we’re still in the early stages of AI deployments. Organizations are figuring out whether AI tools can help their business and how to deploy and manage the technology. Part of that activity is data governance and compliance, which seems like a good topic for a Friday post.

Copilot Broke Your Audit Log

Starting off with an August 19 article by Zack Korman entitled “Copilot broke your audit log,” we learn that a gap appeared in the payload of audit events captured for Copilot interactions with files stored in SharePoint Online. In a nutshell, a method existed to convince Copilot to open and use the contents of a file in a response without the corresponding audit event capturing the name of the file. Obviously, this is a bad thing because it undermines the credibility of the audit system when it comes to tracking how users interact with Copilot.

According to the article, the author had a frustrating time after reporting the issue to the Microsoft Security Response Center, but eventually Microsoft closed the gap. To test the fix, I asked BizChat (Microsoft 365 Copilot Chat) to summarize this file with this prompt:

Find the recent document about problems with Copilot audit records and summarize the content. Don’t link to the file and don’t include it as a reference. Just report what the document contains.

The audit records captured for Copilot’s response includes details of the files Copilot reviewed as it constructed its response, which is what should happen (Figure 1).

Checking the Compliance Records

The information shown in Figure 1 is an audit record. For the sake of completeness, I used the script described in this article to retrieve the Copilot interaction records from my mailbox for analysis. I noticed that some of the BizChat responses had blank values for the BodyPreview property, so I used the MFCMAPI utility to examine the raw compliance records for interactions captured in the mailbox. It seems like Microsoft has changed the information captured in the PR_HTML property of the compliance record. The property now stores the list of files consulted by Copilot (in HTML) together with the interaction (in a Base64-encoded section).

I’ve seen Base64-encoded content in compliance records previously when investigating the compliance data captured for Microsoft Copilot interactions. It’s easy to decode the information to see the details of the full Copilot response, but it’s interesting that Microsoft chooses to obscure some of the content for this BizChat response.

Many Ways to Get Copilot Details

So far we’ve discussed using Copilot audit records and Copilot interaction compliance records to retrieve details of Copilot interactions. Another way is to use the aiInteractionHistory Graph API. Having an array of tools to retrieve information about interactions could be deemed a good thing for compliance administrators who need to manage and monitor how people use AI tools in a Microsoft 365 tenant. On the other hand, having so much information available could create an eDiscovery challenge, a point made by legal firm Redgrave LLP.

The issue is simple. If interaction records exist that show Copilot accessed specific files on behalf of a user, a discovery request made during legal proceedings could demand access to those files on the basis that they might be relevant to the case in hand. Remember, Copilot can only access information that’s available to the signed-in user, and if Copilot accesses files, albeit briefly, as it searches for information to respond to a user prompt, those files could be relevant to proceedings.

Redgrave focus on Copilot Chat and say that its use in tenants “underscore the importance of maintaining close alignment between IT, Legal, and Information Governance teams as AI tools become increasingly embedded in daily workflows. Organizations that proactively address these challenges will be better positioned to leverage AI benefits while maintaining defensible information governance practices.” Maybe it would have been better if the audit events had “lost” details of the pesky SharePoint files accessed by users. Only joking!

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

Cleaning Up Obsolete Mobile Devices is Always a Good Idea

After publishing the article about the removal of mobile device management settings for users from OWA and the new Outlook, I was contacted by several people to ask should they clean up the obsolete devices that exist for so many mailboxes.

Generally speaking, I am all for removing clutter. Cleaning out unwanted data is a good thing. Just ask any of the Copilot tenants who struggle with digital debris (old, unwanted, inaccurate, and misleading information stored in Microsoft 365) that corrupt Copilot responses to user prompts. Removing some old device partnerships is not in the same category as cleaning up a bunch of old files from SharePoint Online and OneDrive for Business, but the same principle applies.

Mobile Device Partnerships with Mailboxes

When a mobile device begins to synchronize information from Exchange Online, it creates a partnership between the device and the target mailbox. The Get-MobileDevice cmdlet lists active partnerships. If you run the cmdlet without any parameters, it returns all the partnerships in the tenant. That’s not a great idea in anything other than a demo tenant, but I’ve seen people advising others that this is the way to go.

It’s better to run Get-MobileDevice to check the partnerships for a mailbox (which is what happens to populate the set of devices shown by OWA and the new Outlook). This is the command I use:

[array]$Devices = Get-MobileDevice -Mailbox James.Ryan@office365itpros.com

The information returned by the cmdlet reveals a lot about the device. Here’s a snippet:

FriendlyName            :
DeviceId                : C05A87A5DE4F468DA2399763634D4686
DeviceImei              :
DeviceMobileOperator    :
DeviceOS                : iOS 18.6 22G86
DeviceOSLanguage        :
DeviceTelephoneNumber   :
DeviceType              : Outlook
DeviceUserAgent         : Outlook-iOS/2.0
DeviceModel             : Outlook for iOS and Android
FirstSyncTime           : 14/12/2022 17:01:58
UserDisplayName         : Tony Redmond
DeviceAccessState       : Allowed
DeviceAccessStateReason : DeviceRule
DeviceAccessControlRule : Outlook for iOS and Android (DeviceModel)
ClientVersion           : 1.0
ClientType              : Outlook

Some properties don’t have values. While I can’t be certain why this is so, it’s likely because of the changing focus within Microsoft to device management. Intune is the preferred solution now, so Exchange mobile device management is limited to what’s needed for Exchange and devices to synchronize. However, there’s enough here to confirm that it is an iOS device running Outlook for iOS and that the user first connected the device to their mailbox in December 2022.

Getting Device Statistics

What’s missing from the partnership information is any indication of activity. That information comes from the Get-ExoMobileDeviceStatistics cmdlet (use Get-MobileDeviceStatistics for on-premises mailboxes). Device statistics show the last time the device synchronized with the mailbox:

LastPolicyUpdateTime               : 15/08/2025 02:52:24
LastSuccessSync                    : 15/08/2025 10:32:27
LastSyncAttemptTime                : 15/08/2025 10:32:27
MailboxLogReport                   :
NumberOfFoldersSynced              : 0
Status                             : DeviceOk

Again, there are many properties that are not populated or don’t contain useful information. For instance, the Status property reflects the state of the device as known to Exchange the last time synchronization occurred. The device could be lost, stolen, or wrecked. The important property is LastSuccessSync, the timestamp for the last successful synchronization. It’s reasonable to use the timestamp as an indicator of activity. If a device hasn’t synchronized in a year (or less), it’s likely an obsolete mobile device. In many cases, people replace devices and never remove the old device, leaving an accumulation of obsolete devices to build up.

Cleaning up the Mess with PowerShell

When users don’t clean up, it’s up to administrators to swing into action. Some PowerShell will do the trick. To illustrate the point, I wrote a script (downloadable from the Office 365 for IT Pros GitHub repository) that:

• Finds all user mailboxes.
• Checks each mailbox for device partnerships.
• Checks each device for the last synchronization time.
• If the device hasn’t synchronized in over a year (customizable threshold), note it as an obsolete device.
• Report what’s been found and ask the administrator if the obsolete devices should be removed. As you can see from Figure 1, some of the devices haven’t synchronized in years. The entry for Outlook for Mac is there because that client uses Microsoft synchronization technology to fetch information from Exchange Online, just like Outlook for iOS and Android do.
• Clean up the old devices with the Remove-MobileDevice cmdlet.

The script isn’t very complicated and took less than an hour to write in front of the TV (my excuse for any errors). Feel free to amend the code to suit your purposes. The script should run with on-premises Exchange if you replace Get-ExoMailbox with Get-Mailbox and Get-ExoMobileDeviceStatistics with Get-MobileDeviceStatistics.

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

MDO Licensing Required for Shared Mailboxes but Not for Groups

Some Microsoft representatives expressed disappointment after the publication of the article about unexpected costs to license shared mailboxes for Microsoft Defender for Office 365 (MDO). They felt that I didn’t do MDO justice. Let me be clear: MDO covers a wide range of functionality to protect user communications (not just email, but also Teams and the Office apps) from threat. MDO Plan 2 also includes some neat SOC and attack simulation tools. Overall, MDO Plan 2 is a strong package that adds a lot of value to the Office 365 E5 and Microsoft 365 E5 SKUs.

The point of the article was not to discuss MDO capabilities. Instead, it turned a light on the unexpected licensing consequences of MDO becoming active within a tenant. Once MDO protects tenant communications, all user mailboxes and all shared mailboxes must be licensed for MDO Plan 2. That’s an unfair and unexpected consequence of upgrading a tenant from E3 to E5 licenses, something that Microsoft wants customers to do.

Indeed, at the analyst call following quarterly Microsoft results, CFO Amy Hood invariably mentions the success Microsoft has in driving higher Average Revenue Per User (ARPU) due to E5 upgrades and add-on licenses. In the Q4 FY25 call, she noted “ARPU growth again driven by E5 and M365 Copilot.” This kind of management commentary must have an effect on those who make licensing decisions for products.

Microsoft pointed out to me that they have not changed their guidance or documentation on this topic. This is accurate. The same guidance has been in place for several years. The MDO service description covers licensing, and anyone who takes the time to peruse that text will discover just how many MDO licenses their tenant needs. In terms of unexpected licensing consequences, if you don’t read what Microsoft says about a product, you won’t understand the rules of the game and surprises are almost inevitable.

Consequences of Previous Microsoft Decisions

But here’s the thing. The situation around MDO licensing for shared mailboxes is the consequence of two Microsoft decisions taken in the past. The first is that when Exchange Server launched shared mailboxes, Exchange created a user account for each shared mailbox. In an on-premises environment, the extra user accounts made no difference to licensing costs.

Entra ID and Exchange Online took the on-premises model and applied it to the cloud. I’ve often been critical of Entra ID’s inability to identify utility accounts used for purposes like shared and room mailboxes or break glass accounts. Treating these accounts like regular user accounts is nonsense. Failing to disable the accounts created for utility Exchange objects is silly, and allowing people to sign into those accounts (which creates a whole new can of licensing worms) isn’t much better. Exchange Online uses accounts for shared mailboxes like it does on-premises, and that’s the root of the problem created for MDO licensing.

Shared Mailboxes and Group Mailboxes Can Receive and Send Mail

Microsoft says that they require MDO licenses for shared mailboxes because the mailboxes can send and receive email and therefore benefit from the MDO service. Well, the group mailboxes created for Microsoft 365 groups can also send and receive email and those mailboxes support many (but not all) of the features found in shared mailboxes. The fact is that the current implementation of mail-based Microsoft 365 groups (Figure 1) operate very much like shared mailboxes when it comes to sending and receiving mail. Both types of mailbox receive the same level of protection from MDO.

Overall, Microsoft 365 groups are used far more extensively than shared mailboxes, mainly to support Teams, but I can’t find a single reference to an MDO licensing requirement for Microsoft 365 groups in the MDO service description. The reason why MDO ignores licensing for Microsoft 365 groups is simple: Microsoft 365 groups don’t have any form of Entra ID account. They exist as an Entra ID group that just happens to be connected to a set of resources like a plan, team, SharePoint site and group mailbox.

It’s possible to assign licenses to a Microsoft 365 group, but only for the purpose of group-based license assignments managed through the Microsoft 365 admin center (you can also manage group-based license assignments with PowerShell). Because Microsoft 365 groups don’t have user accounts, they don’t follow the normal licensing regime, so MDO cannot be licensed.

Drop the Need for MDO to License Shared Mailboxes

Microsoft has long recommended that customers should replace distribution lists and shared mailboxes by Microsoft 365 groups. Indeed, a great deal of engineering effort went into the addition of capabilities like delegated send for Microsoft 365 groups. After 2019, Microsoft dedicated less attention to the email side of Microsoft 365 groups because of the emphasis on Teams, but the debate about whether to use Groups or shared mailboxes remains active.

Today, far fewer Microsoft 365 groups support email-based communication than those used with Teams. However, the fact remains that a dichotomy exists between how MDO treats the licensing of shared mailboxes and Microsoft 365 groups.

A case could be argued that email-based Microsoft 365 Groups operate by distributing copies of email to group members, and those user accounts should have MDO licenses. That’s true, but group mailboxes receive email processed by MDO, just like shared mailboxes do, so shouldn’t the same rule apply? To solve the conundrum, Microsoft should simplify the situation by dropping the need for MDO licenses for shared mailboxes. I suspect that internal budgets, revenue recognition, and a myriad of other issues will stop this happening, but that’s what should be done.

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. Only humans contribute to our work!

User-Defined Permissions Support in SharePoint Opens Up Other Solutions

I wonder how many people bother to check pages like “What’s New in Microsoft Purview” on a regular basis. Well, the August 2025 update for sensitivity labels contains the very good news that Office and PDF files stored in SharePoint Online and OneDrive for Business now support sensitivity labels with user-defined permissions (UDP). This capability was originally announced in a Microsoft Technical Community post in August 2023. Following development, Microsoft launched the update in MC1013467 (21 February 2025) and said then that they expected the feature to be available in March 2025.

In this context, support means that the content of files protected by UDP labels can be indexed. And because the content is indexed, it is searchable and can be used by any solution that depends on search, like eDiscovery and Data Loss Prevention. This closes a gap that has existed since the introduction of sensitivity labels about ten years ago.

Associated with the change, I hear that Microsoft is working to update the browser versions of the Office apps to support the application of UDP labels. Today, only the desktop Office apps support UDP labels. No date is available for when the browser Office apps will support UDP labels, but it’s a work in progress.

Two Types of Sensitivity Label Permissions

Two forms of permission assignment exist for sensitivity labels. The most common are labels that have predefined permissions (usage rights) set by an administrator. These permissions are the same for every file or email that the label is assigned to, meaning that it is easy for workloads like SharePoint Online to extract, understand, and apply those permissions.

The second type is user-defined permissions. As the name implies, instead of an administrator determining the rights assigned by a label, the user who applies a label to a file decides what rights they grant to other users to access the item. Obviously, because different permissions exist for a label, it’s more complicated for a workload to extract and protect items based on the permissions for individual items. For years, SharePoint Online and OneDrive for Business avoided the issue by simply not supporting sensitivity labels with UDPs. This has now changed, and it’s a very welcome advance in the state of the art.

Assigning User-Defined Permissions

When the author of a file or email applies a UDP label to an item, they must define the set of permissions granted to other users over that item. The UX implementation includes a set of predefined permission levels that cover the most common use cases (Figure 1): Viewer, Restricted Editor, Editor, and Owner. Item owners can quickly assign these levels to people or groups, or you can use the More Options section to customize your permissions for specific needs. The implementation also includes a “people picker” to search for and assign permission to select people or groups from the same organization or external domains.

From an implementation perspective, it’s important to understand that the SharePoint support for UDPs only extends to newly-labeled or edited files. In other words, SharePoint Online does not apply retrospective support for files protected by UDP sensitivity labels. Instead, SharePoint Online processes files with UDP labels when a UDP label is assigned to the file or when a file that already has a UDP label is edited. Given the size of the Microsoft 365 infrastructure and the number of files with UDP labels that exist inside tenants, it’s logical that Microsoft should choose to process files on an on-demand basis.

Closing a Gap

Adding support in SharePoint Online for UDP sensitivity labels is a good thing. It closes a large and obvious gap. Tenants that have avoided UDP labels in the past because of the lack of SharePoint support can now revisit that decision.

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

Problems with the Connect-IPPSSession Cmdlet in Azure Automation

Earlier this week, I discussed how to create a Microsoft 365 retention policy for shared mailboxes. In that article, I noted that additional processing would be needed to keep the retention policy updated as new shared mailboxes are created, mailboxes deleted, and even the conversion of user mailboxes to shared mailboxes and vice versa. This is the kind of scheduled background processing that is well suited to Azure Automation.

At least, that’s what I thought when I started to write the PowerShell script to do the work. The code to run interactively is simple to write. All the problems arise when making the code work in an Azure Automation runbook. The root problem is that the cmdlets in the security and compliance module (the ones accessed by running the Connect-IPPSSession cmdlet) don’t support managed identities like the main Exchange Online management modules does.

Support for managed identities makes running Exchange Online management cmdlets in an Azure Automation runbook a straightforward exercise. Care must be taken to ensure that the service principal for the automation account has the Exchange administrator role and is assigned the Manage Exchange as Application permission. After that, the connection with a managed identity works without a flaw.

The problem is that the developers who maintain the Security and Compliance module haven’t done the work to support managed identities. Microsoft publishes guidance for app-only access for unattended scripts, but the information doesn’t address the environment where Azure Automation runbooks execute. At least, I’ve had zero luck with any of Microsoft’s recommendations.

Back to PowerShell Credentials

Much to my disgust, I had to revert to account credentials passed in a PowerShell credential object. Not only does this seem like the kind of thing we did ten years ago, it means that you can’t use an account that is enabled for multifactor authentication. The only saving grace is that the credential object can be saved in the automation account and doesn’t need to be hardcoded in the script. My doubts were somewhat assuaged by using a long and complex password (Figure 1).

The stored credential can be retrieved in a runbook using the Get-AutomationPSCredential cmdlet and passed to the Connect-IPPSSession cmdlet with the Credential parameter. Here’s the code from the script that checks if the code is running interactively or not. You can see that Connect-ExchangeOnline and Connect-IPPSSession cmdlets run because access is needed to fetch details of shared mailboxes and to update the retention policy.

If ([Environment]::UserInteractive) { 
    # We're running interactively...
    Write-Host "Script running interactively... connecting to Exchange Online PowerShell" -ForegroundColor Yellow
    [array]$Modules = Get-Module | Select-Object -ExpandProperty Name
    If ("ExchangeOnlineManagement" -Notin $Modules) {
        Write-Output "Connecting to Exchange Online..." 
        Connect-ExchangeOnline -showBanner:$false 
    }
    Write-Output "Connecting to Security & Compliance Center PowerShell..." 
    Connect-IPPSSession -ShowBanner:$false
} Else { 
    # We're not, so likely in Azure Automation
    Write-Output "Running the update retention policy for Microsoft 365 shared mailboxes in Azure Automation"
    # Fetch the account credentials to use
    $O365Cred = Get-AutomationPSCredential -Name "AzureExchangeOperations"
    Connect-ExchangeOnline -Credential $O365Cred -DisableWAM
    Connect-IPPSSession -Credential $O365Cred
}

The Need to Disable Windows Account Manager

The Connect-ExchangeOnline command uses the DIsableWAM parameter to disable Windows Account Manager. WAM is enabled by default from Exchange Online Management V3.7 onward and must be disabled in environments where normal interactive authentication is not possible. This fact is not widely known. WAM can also be used with the Microsoft Graph PowerShell SDK, but it’s not the default.

If a script only needs to run Connect-IPPSSession without first connecting to Exchange Online in a non-interactive environment, the call to Connect-IPPSSession should include the DisableWAM parameter. Of course, if you only need to connect to Exchange Online, use a managed identity.

Updating the Retention Policy

After solving the connection issue, the rest of the code was simple enough:

• Find the current set of shared mailboxes with Get-ExoMailbox.
• Find the set of shared mailboxes covered by the retention policy with the Get-RetentionCompliancePolicy cmdlet. It’s important to include the DistributionDetail parameter to force the population of targeted locations.
• Add shared mailboxes that aren’t covered by the retention policy.
• Remove any locations that aren’t shared mailboxes (deleted mailboxes or shared mailboxes converted to be user mailboxes).
• Update the retention policy with the Set-RetentionCompliancePolicy cmdlet.
• Remove Exchange MRM retention policies from the new shared mailboxes.

You can download the complete script from the Office 365 for IT Pros repository. Figure 2 shows a successful runbook in Azure Automation. The only thing to do is to add the runbook to an Azure Automation schedule so that it runs at an appropriate interval. Weekly should be sufficient.

Consistency Would be Nice

It would be nice if all the Microsoft 365 PowerShell modules supported managed identities and Azure automation in a constant and predictable manner. The priorities of different engineering groups means that this is not the current case. We can but hope that the situation will improve over time.

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