The End of Parent-Child Label Relationships

Message center notification MC1111778 (last updated 24 September 2025, Microsoft 365 roadmap item 386900) announces the modernization of sensitivity label grouping to a “dynamic architecture” consisting of labels and label grouping rather than parent and child labels. The new architecture supports moving sensitivity labels between groups “without losing referential integrity.” In other words, the settings of sensitivity labels remain intact when they are moved from one label group to another.

Removing the Last Vestiges of AIP

When Microsoft launched Azure Information Protection (AIP) labels in 2016, they adopted a two-tier parent-child model for organizing the display of labels. In this model, the parent label functions as a navigation location for child labels and cannot be applied to files. When sensitivity labels took over from AIP labels, the same arrangement was kept. In Figure 1, the Secret label is the parent and the All Company and My Team are child labels.

When details of an assigned label are viewed in client user interfaces, the structure is displayed as Parent\Child (Figure 2).

The problem with the parent-child structure is its strict nature. Once a child label is created and deployed in active use, it becomes very difficult (if not practically impossible) to change the labeling structure to reflect current business requirements. The inflexible nature of the parent-child structure is the main reason why I never recommended its use to customers. It’s difficult enough to construct a workable labeling structure for a tenant without having to deal with inflexible groupings.

Public Preview and Migration

Microsoft is currently deploying the modern label architecture in public preview with the aim of attaining general availability in December 2025. New tenants created after 1 October 2025 must use the new architecture. No administrator action is required before general availability occurs, but it might be a good idea afterwards to review the current label structure to see if sensitivity labels can be presented in more effective manner to end users.

When a tenant is upgraded, any existing parent-child groups are migrated to the new architecture. During the preview, if a tenant has parent-child label groups, they can use the manual migration method invoked from the Information Protection section of the Purview portal (Figure 3). Migration is an irreversible process, so take the time to read up before plunging ahead and migrate a set of sensitivity labels in a test tenant first.

Launching the migration is preceded by notification of what the expected outcome will be (Figure 4). My tenant has used sensitivity labels since their AIP predecessors and has accumulated many different sensitivity labels used for content protection and container management over the years, including two parent-child groups (for testing only).

The migration took just a few seconds and only difference seen afterwards is that the parent labels are now label groups and the child labels are members of those groups. The Secret parent viewed earlier became a label group and also a standalone sensitivity label. The standalone label takes the name, GUID, and settings as the original parent label. Following the migration, I updated the display name of the affected labels and label groups to make their function obvious.

The new architecture exposes options in the Purview portal to move sensitivity labels into and out of groups. This is the big advantage of the change as administrators can now easily construct and change label groups according to business demands. For instance, I created a label group called Email Labels to organize the sensitivity labels most appopriately used for email to give additional guidance to end users. Figure 5 shows how the new label group appears in OWA.

Notice how all the sensitivity labels in the Email Labels group have the same label color. This might affect the carefully-crafted custom colors you might have assigned to sensitivity labels in the past. Another important change is that the standalone labels moved into the label group have priority orders based on the priority assigned to the label group. Label priority is supposed to indicate the degree of confidentiality or sensitivity of files that labels are applied to, so some rearrangement of labels is probably needed here. A change in label priority can lead to an increase in document mismatch notifications, and that’s not a good thing.

Although you can move container management labels into label groups there’s no point in doing so. First, organizations tend to have relatively few container management labels, so there’s no need for grouping. Second, the applications that use container management labels, like Teams and SharePoint Online, display container management labels in a simple list.

PowerShell Changes

A set of cmdlets in the security and compliance module support sensitivity labels. The label settings manipulated by the cmdlets use the same properties to update label group membership as was used to associate a child label with a parent label. For instance, a label group has the isParent and isLabelGroup settings set to true:

$Label = Get-Label -Identity 'Email Labels'

$Label.Settings
[isparent, True]
[islabelgroup, True]

A sensitivity label in a label group has the isParent property set to false and the identifier for the label group in its ParentId property:

$Label = Get-Label -Identity '1b070e6f-4b3c-4534-95c4-08335a5ca610'

$Label.Settings
[contenttype, File, Email]
[isparent, False]
[parentid, 62acd157-1757-4361-9a53-71ea316279ca]

To move a label into a label group, run the Set-Label cmdlet and update the ParentId parameter with the identifier for the label group. Here’s an example of moving a label into the Email Labels group:

Set-Label -Identity 'Employee Confidential' -ParentId (Get-Label -Identity 'Email Labels').ImmutableId

To move a sensitivity label out of a label group, pass $null or the identifier for another label group as the parent identifier.

Heading to a New Architecture

Referring to a new way to manage sensitivity labels for display in applications as a new architecture is a stretch. However, it’s still a good change. It will take time for tenants to figure out how to best use label groups, but that will come in time. In the meantime, the task is to migrate to the new architecture, either manually or by waiting just a few more weeks.

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.

Setting Teams Work Location by Reference to a Wi-Fi Network

I’m amazed at some of the commentary flowing from MC1081568 (last updated 24 October 2025, Microsoft 365 roadmap item 488800) about a new Teams feature to automatically set a work location based on connecting to a Wi-Fi network or known peripherals such as Teams Rooms devices. The way some people described it, you’d think that this is tantamount to Microsoft making a method available for managers to keep an eye on employee work habits. The simple truth is that automation work location detection is not, and anyone who thinks that it is reveals a woeful lack of knowledge about how Teams works.

Setting work location has been a feature in Teams and Outlook for quite a while (Figure 1). The idea is that people can collaborate more effectively with co-workers if everyone knows where everyone is. Knowing where people are is important from a support perspective too, especially when Teams Phone serves as the corporate phone system.

Today, users must set their location manually. I forget to do so as a matter of course, just like I suspect many others do. But Teams knows when people connect to a work network. At least, it can if automatic detection is configured in Microsoft Places. In addition, the tenant must configure a Teams work location detection policy to enable automatic detection because by default, the feature is off.

Managing the Work Location Detection Policy with PowerShell

To configure the policy, connect to Microsoft Teams PowerShell and either run the Set-CsTeamsWorkLocationDetectionPolicy to switch automatic detection on by default for all users or (recommended) run the New-CsTeamsWorkLocationDetectionPolicy cmdlet to create a new work location detection policy and assign that policy to the users who you want the policy to apply to. This command creates a new policy:

New-CsTeamsWorkLocationDetectionPolicy -Identity AutoDetectNetwork -EnableWorkLocationDetection $true

To assign the policy to user accounts, use the Grant-CsTeamsWorkLocationDetectionPolicy cmdlet:

Grant-CsTeamsWorkLocationDetectionPolicy -Identity Lotte.Vetler@office365itpros.com -Policy AutoDetectNetwork

The Get-CsTeamsWorkLocationDetectionPolicy reports which work location detection policies enable automatic detection:

Identity              EnableWorkLocationDetection
--------              ---------------------------
Global                                      False
Tag:NetworkDetectOn                          True
Tag:AutoDetectNetwork                        True

It’s important to remember that Teams clears location information at the end of the working day and does not update locations outside working hours (based on Outlook settings).

Keeping an Eye on User Locations

For those who suspect that managers will monitor their locations to check where people are, my response is that managers can do this today by checking the user profiles for their employees where their location is displayed (Figure 2).

Having been a senior manager in several organizations, my view is that any manager that devotes time to this kind of checking needs to reevaluate how they allocate their time. It is something that might be justified when monitoring a problem employee, but not elsewhere. If people are really worried about management oversight, they can use the Teams browser or mobile clients. Detecting location automatically only works for the Teams desktop clients for Windows and MacOS.

Privacy is Important

People are right to worry about their privacy, and they should understand the potential impact of new functionality on how they work. In this case, I don’t think that there’s much to complain about. There are better tools available if an organization wants to monitor employee productivity. Automation work location detection by Teams to register if someone is in the office is not going to worry the people who build employee monitoring software. It shouldn’t worry you either.

Learn about managing Teams 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

French Security Company Highlights Stealing Teams Access Tokens from the Local State File

On October 23, 2025, a French security company called Randorisec, published an article about stealing Microsoft Teams access tokens in 2025. Over the next few hours, I received several messages asking if the news as reported was serious and required action. My response was “Nope.”

I don’t think that the article surfaces any new information. More importantly, the compromise as described is only possible if attackers first manage to gain control over a workstation running Teams. In that scenario, the problem is more serious than fetching a few access tokens to use to send messages with the Graph API. Let’s discuss what the article reveals and why I’m sanguine about its findings.

The Teams Local State File

The discussion centers on fetching content from the local state file used by Teams, which is found in:

%LocalAppData%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams\EBWebView\Local State

The article explains how to fetch and decrypt cookies protected using the Chromium Data Protection API (DPAPI), which in turn are used to fetch access tokens. I’m not sure that there’s anything new here because I found several articles to explain the process (here’s a good example). Chromium-based browsers use JSON-formatted local state files to store information needed for browser sessions, including encrypted keys used to protect sensitive information like user passwords.

Why Does Teams Use a Local State File?

What people might not understand is why Teams uses a local state file to hold information about the current client configuration, software version, other client settings, and encrypted content (Figure 1). The answer is that the Teams V2 client architecture depends on the WebView2 component. WebView2 uses the Edge rendering engine to display content within apps, including Teams, the new Outlook for Windows, and features shared between Outlook clients like the Room Finder. Microsoft includes the WebView2 component with Office and other products.

Because the Teams clients are deeply integrated with WebView2, it makes sense to adopt other Chromium constructs, like the local state file and DPAPI, and that’s probably why you end up with a Teams-specific local state file that behaves much like the local state file used by Chromium browsers.

Access Tokens for Teams

Eventually, the researchers end up with access tokens that can be used to interact with Teams via the Graph API. Getting to the access tokens requires fetching them from the cookies SQLlite database. This file is found in the %LocalAppData%\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams\EBWebView\WV2Profile_tfw\Network folder and is locked when a Teams client is active.

The assertion that they can use the tokens to send email is erroneous. As pointed out in the article, the tokens are for use with Teams, not Exchange Online, so the permissions granted in the tokens do not permit use of the Mail Send API.

Local State File is Inaccessible Unless a Device is Compromised

Don’t get me wrong. Security researchers do a great job of finding weaknesses in products before attackers figure out how to use those weaknesses to do damage. I applaud the efforts of the Randorisec team, but I just don’t think that there’s anything surprising to become too concerned about. The attempt to hype the problem by Cyber Security News is also regretable. I wonder if either the researchers or reporter actually know anything about how Teams works, but hey, all publicity is good.

I keep on going back to the simple fact that before an attacker can access the Teams local state file and cookies database, they’ve broken into the workstation and therefore have full access to whatever’s on that device. In all probability, they can start the Teams client and can send chats and channel messages without needing to fetch and decrypt information.

The best defence is to stop attackers from compromising user accounts by deploying strong multifactor authentication. If you can do that, you shouldn’t need to worry about the details of Teams, WebView2, and the cookies file.

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.

Reviewing Enterprise Apps is a Good Idea

Over the years, I have advised Microsoft 365 tenants to check and clean up enterprise apps regularly. Initially, the Graph APIs available to report information about enterprise apps weren’t too approachable and lacked some data. However, the situation has improved and it’s now easier to get a solid handle on the enterprise apps present in a tenant, the usage of those apps, and the permissions used by apps to access data.

Given that the original clean-up script dates back to April 2020, I’ve been writing a new script based on the Microsoft Graph PowerShell SDK to demonstrate how to generate review data. (Microsoft released V2.32 of the SDK on October 20, 2025, so far, the new version appears to be solid). In any case, once I’ve finished tweaking the code, I’ll write up details about what the script does and release it via the Office 365 for IT Pros GitHub repository.

The Case of the Newly-Added Enterprise Application

One of the checks performed by the script highlights recently added service principals. After writing the code, I was interested to discover the presence of an enterprise app called GuideAnts, added on 15 October 2025 by my account. I couldn’t remember anything about adding such an app. Advancing age has a nasty habit of eroding immediate recall.

In any case, running an audit log search confirmed that my account had added the service principal (Use the Search-UnifiedAuditLog cmdlet to search the audit log for events with operations = “Add Service Principal.”). Here’s an extract from the audit log:

Actor                         : {@{ID=Tony.Redmond@office365itpros; Type=5}, @{ID=1003BFFD805C87B0; Type=3}, @{ID=Azure ESTS Service; Type=1}, @{ID=00000001-0000-0000-c000-000000000000; Type=2}…}
InterSystemsId                : e5fce0de-688c-4e1e-bf64-22d9246ba0e6
IntraSystemId                 : 00000000-0000-0000-0000-000000000000
SupportTicketId               :
Target                        : {@{ID=ServicePrincipal_d448e5cc-80cc-4c95-8aca-356068dc2972; Type=2},@{ID=d448e5cc-80cc-4c95-8aca-356068dc2972; Type=2}, @{ID=ServicePrincipal; Type=2},@{ID=guideants; Type=1}…}

Having still no memory of doing such a thing, I exported my browser history and loaded the CSV file into PowerShell to check it:

$History = Import-CSV browserhistory.csv
$History | Where-Object {$_.pagetitle -like "*GuideAnts*"} | Format-table DateTime, PageTitle, NavigatedToURL

DateTime                 PageTitle                 NavigatedToUrl
--------                 ---------                 --------------
2025-10-15T20:26:54.855Z GuideAnts Notebooks       https://go.guideants.ai/access
2025-10-15T20:26:30.514Z GuideAnts Notebooks       https://go.guideants.ai/login
2025-10-15T20:26:29.801Z GuideAnts Notebooks       https://go.guideants.ai/

This is the kind of interaction captured when someone goes through the consent process to add an enterprise app (Figure 1) and consents on behalf of the organization. There was no doubt. I was the culprit.

This is an example of bad practice in action. I might have been tired, and I might have wanted to check out the app because I was writing about ISV AI-powered add-ins for Microsoft 365 at the time, but these are not acceptable excuses.

Consent Approval Workflow for Enterprise Apps

I violated my personal standards in three ways. First, I added an enterprise app without much consideration, perhaps because the permissions sought for the app were pretty benign. Second, I added an unverified app. Enterprise apps published by ISVs should go through the Microsoft verification process to give tenants some additional trust that the app comes from a reputable publisher.

Third, I used my administrator account. Had I used my normal account, I wouldn’t have been able to add an enterprise app because the tenant settings would block immediate app creation by users. Instead, a request to add the app would have gone through a consent approval workflow for approval by an administrator (Figure 2). Even if that administrator was me, being forced to go through the approval process might have caused me to think why an enterprise app was needed, or to review the reply URLs used by the app and ask myself why these URLs are required.

We live and learn from our mistakes. I hope that I won’t make the same mistake again!

GuideAnts AI Notebooks

Apart from noting the unverified nature of the enterprise app, none of the above is criticism of the GuideAnts app (an AI-powered notebook). The app’s author is Doug Ware, an ex-MVP, who publishes some interesting AI-related content on Elumenotion.com. The app is currently in preview. You can read more about GuideAnts here and decide if you want its enterprise app to exist in your tenant. Use invite code 22VG6Y if you want to join the preview.

Learn how to exploit the data available to Microsoft 365 tenant administrators through the Office 365 for IT Pros eBook. We love figuring out how things work.

Use SDK Cmdlets to Create or Update Password Protection Policy Settings

A reader asks if the script written for the article about updating the Entra ID banned password list can be used to update other settings in the Entra ID password protection policy. The answer is “of course.” The code is PowerShell, and it can be adapted to update any of the password protection settings found in the Entra admin center (Figure 1).

A few considerations must be remembered when updating the Entra ID password protection policy:

• You don’t need additional licenses to use the default password protection policy. If you create a custom policy by updating settings, user accounts must be licensed with Entra P1 or P2.
• Custom password policy settings are immediately effective across the entire tenant. You can’t assign a custom password policy to specific users or groups.
• In a hybrid environment, password protection can extend to Active Directory.

Creating a Password Protection Policy

The underlying concepts for creating a custom password policy are similar to the management of other Entra ID policies (like the Microsoft 365 groups policy):

Check if a custom policy exists, or rather, a directory setting object created using the directory setting template for password rules. The template always has the identifier 5cf42378-d67d-4f36-ba46-e8b86229381d, so we can check if a custom password protection policy exists follows:

$Policy = (Get-MgBetaDirectorySetting | Where-Object {$_.TemplateId -eq "5cf42378-d67d-4f36-ba46-e8b86229381d"})

A client-side filter is used because the Graph API does not support server-side filtering against template identifiers.

If a password policy object is not available, you can create a new password policy object. The values for the policy settings are in a hash table containing an array of values. Each value (a setting) is a hash table consisting of the setting name and its value. For example, this code creates the hash table to hold the setting for lockout duration:

$Value5 = @{}
$Value5.Add("Name", "LockoutDurationInSeconds")
$Value5.Add("Value", $LockoutDuration -as [int32])

After populating values for all settings (or just the ones that are different from the default), run the New-MgBetaDirectorySetting cmdlet to create the new custom password policy:

$NewBannedListParameters = @{}
$NewBannedListParameters.Add("templateId", "5cf42378-d67d-4f36-ba46-e8b86229381d")
$NewBannedListParameters.Add("values", ($Value1, $Value2, $Value3, $Value4, $Value5, $Value6))
$Policy = New-MgBetaDirectorySetting -BodyParameter $NewBannedListParameters -ErrorAction Stop

Updating the Password Protection Policy

If a custom policy already exists, fetch the policy settings, update the value for the settings that you want to change, and use the Update-MgBetaDirectorySetting cmdlet to update the policy. This example changes the lock out duration time to 120 seconds (the default is 60 seconds):

[array]$PolicyValues = Get-MgBetaDirectorySetting -DirectorySettingId $Policy.Id | Select-Object -ExpandProperty Values
($PolicyValues | Where-Object {$_.Name -eq "LockOutDurationInSeconds"}).Value = 120
Update-MgBetaDirectorySetting -DirectorySettingId $Policy.id -Values $PolicyValues -ErrorAction Stop

The code for these operations is the same as used in the script to update the banned passwords list. Grab what you need from that script and repurpose it to do whatever you need to. For instance, some organizations like to validate that the password policy settings in the tenants that they manage are consistent and up to date. This is easily done on a periodic basis by creating a PowerShell runbook in Azure Automation. I imagine that checking the password policy would only be one of the Entra ID configuration checks that such a runbook would process. At least, that’s how I would do it.

Next Step – Testing Configurations

The Maester utility includes some checks against the password policy and it would be easy to expand test coverage to whatever aspect of the password policy you consider needs to be checked. Once you’ve mastered programmatic manipulation of the Entra ID password protection policy settings, anything is possible.

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!

Passkey Settings Behavior Change After Introduction of New Passkey Profiles

If your focus is on Entra ID or security, you probably agree with the statement that passkeys are the future for authentication. Or at least, the immediate next step. Who knows what might happen after passkeys are fully deployed? After all, it wasn’t so long ago that people congratulated themselves for using SMS messages for multifactor authentication.

In any case, message center notification MC1097225 (first published 17 June 2025, updated 20 October 2025) marks an important point in the evolution of passkey support within Entra ID. Where today Entra ID supports tenant-wide controls for passkeys as an authentication method, from November 2025 (December 2025 for government clouds), the preview Entra ID feature will support up to ten passkey profiles per tenant. The intention behind the change is to allow tenants to exert more granular control over which users can use what passkeys for authentication.

Granular control is usually goodness, and there’s goodness in this change. You’ll be able to create a passkey profile for departments or other groups and dictate what kind of passkeys the users within the scope of the profile can use.

Passkey Authenticator Attestation

A potential downside exists that should be understood before rushing to embrace the change. When a tenant opts in to use the new approach, Entra ID switches to a new schema to describe what passkey policies are. Logically enough, the existing passkey settings become the default passkey policy, and if the setting to enforce attestation is disabled, Entra ID will become less strict about the kind of passkeys it accepts as an authentication method.

Passkeys have an Authenticator Attestation GUID (AAGUID), a 128-bit identifier to identify the make and model. In enterprise environments, it is common practice to decide on a set of passkeys or FIDO2 keys that the tenant wishes to support. This decision is enforced by specifying the AAGUIDs in the passkey settings.

But as part of the change to the new passkey schema, Microsoft says that “if Enforce attestation is disabled (in a policy), we (Entra ID) will start accepting security key or passkey providers using the following attestation statements:

• “none” 
• “tpm” 
• “packed” (AttCA type only) 
• Custom attestation formats ≤ 32 characters 

This will allow a wider range of security keys and passkey providers to be accepted for registration and authentication in Microsoft Entra ID.”

That doesn’t sound too serious, but it does mean that if your current passkey settings do not enforce attestation (Figure 1), anyone covered by the default policy created when the switchover happens will be able to choose whatever passkey type they like.

A Passkey Setting Worth Checking

Some tenants might not care very much about the non-enforcement of attestation. Others will care deeply because of the work they’ve done previously to figure out what kind of passkeys should be used within the tenant. In either case, it’s worthwhile considering the topic and deciding if attestation should be enforced.

Microsoft says that there’s no administrator action necessary for the change. It will be deployed automatically to tenants, and you might not realize that anything has happened if you don’t have the need to review authentication methods.

APIs Not Ready for Change

MC1097225 contains an important note: “If you continue using Graph API or third-party tools to modify the policy, the schema will not change until General Availability.” Remember, what comes in November is a preview and it takes time for APIs to catch up with change. Customers who have built tools to manage authentication methods can continue to use those methods until general availability happens, which will probably be in early to mid-2026 (my guess). When that happens, I guess I’ll revisit my password and authentication methods report script.

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!

Updated PDF and EPUB Files Available for Automating Microsoft 365 with PowerShell eBook

The Office 365 for IT Pros team is happy to announce the availability of version 17 of the Automating Microsoft 365 with PowerShell eBook. Updated PDF and EPUB files are available for download from Gumroad.com by subscribers of the Office 365 for IT Pros eBook and by those who bought the PowerShell book separately. Remember, when you subcribe to these books, you’re entitled to receive any updates we release for the edition.

We’re still working on the November 2025 update of the main Office 365 and anticipate that it will be ready for subscribers to download on November 1, 2025.

Final Retirement of AzureAD and AzureADPreview Modules

This month marks the final retirement of the AzureAD and AzureAD Preview modules. Microsoft made the original announcement about the retirement of these and the MSOL module on August 26, 2021. Fifty months and multiple postponements later, Microsoft has eventually managed to cajole, persuade, and force customers to dump the old modules to embrace the Graph. At least, Microsoft wants customers to replace old code with cmdlets from the Microsoft Graph PowerShell SDK or the Microsoft Entra module. Naturally, Automating Microsoft 365 with PowerShell is absolutely the best text to consult for anyone who needs to upgrade old scripts. The worked-out code examples are of great help when figuring out cmdlet syntax.

The Entra module is based on the Microsoft Graph PowerShell SDK. It features cmdlets to work with Entra objects like users, groups, and devices with aliases to make the cmdlets work like their AzureAD equivalents, if one exists. I don’t recommend using the Entra module because I think it’s better that administrators and developers understand how to use the full Graph.

Paperbacks at TEC

The TEC 2025 conference was at the start of October. During the event (enjoyable as always), I ordered some copies of the paperback version of Automating Microsoft 365 for PowerShell for delivery to the hotel (Figure 1).

After looking at the Word and PDF versions of the book for months, I wanted to see how the content looked after going through Amazon’s print-on-demand process to verify that people who buy the paperback will be happy. I think they will because the quality surpassed my expectation. It’s definitely not in the same class as the production quality seen in books like the Microsoft Press Inside Out series, but the book is perfectly acceptable.

Point Updates

Those who pay close attention (or who have time to spare) might notice that point releases appear for Automating Microsoft 365 with PowerShell. For instance, the current release is version 17.2, two point releases from version 17.0. Last month, we issued 16.0 through 16.4.

We issue point releases when we correct minor errors or add some material that’s important and we want readers to benefit from without waiting for a monthly update. Minor errors include grammatical and spelling errors, like an annoying “Get-MgServicePrincipall” discovered in V17.0. Code errors like an incorrect parameter also justify a point release, as does the inclusion of a new example. There’s no point in using electronic publishing if you can’t take advantage of the mechanism to improve the quality and content of the book on an ongoing basis.

Our release cadence poses problems for the paperback version because we obviously can’t update printed books. The books I had delivered to TEC 2025 were version 16.0 and the text printed on those pages will always remain the same. Such is the downside of committing words to print instead of an electronic medium.

Sharing Knowledge

We continue to add content to Automating Microsoft 365 with PowerShell. It’s become my go-to notebook to capture experiences, hints, and insights acquired by working with different Graph APIs and SDK cmdlets. It’s been quite a journey so far and I anticipate that there’s much more to come. Stay tuned.

Audio-Only Recording to Protect User Privacy During Recording Playback

In 2023, mesh avatars were the focus for helping people who didn’t like to appear with their video turned on in Teams meetings. To some, it seemed utterly cool to be able to hand over their visual online presence to an avatar that they created with care to be broadly similar to their real self. Avatars are dumb (your voice remains your voice), but they can express some visual reactions to what happened during meetings.

Earlier this year, Microsoft released the ability to create a mesh avatar from a photo in an attempt to make the avatars more realistic. Figure 1 shows the avatar I created from my photo. My efforts didn’t create a very realistic digital presence.

The Avatars for Teams service plan is included with many Microsoft 365 and Office 365 products, so most the Teams installed base of 320 million monthly active users can use avatars. According to the Teams Avatar app, 83.8K people installed the app to create or update their avatars in the last month, so interest remains in having a way to attend meetings in a visual sense without projecting our real self, flawed and imperfect as that might be.

Audio-Only Recording for Teams Meetings

Which brings us neatly to the news announced in Microsoft 365 message notification MC1173926 (16 October 2025) that the Teams meeting recording feature will soon be able to create an audio-only recording. Deployment of the feature to make it generally available has started and should be complete in late November 2025.

What’s interesting is that Microsoft says that making an audio-only recording for a meeting offers “a more comfortable and convenient recording experience.” Microsoft goes on to note that audio-only recording “alleviates concerns about facial information exposure when recording is necessary, offering a more privacy-conscious approach to recording meetings.”

I thought avatars were all about making the visual side of meetings more comfortable for users. However, it’s important to remember that using avatars is a personal choice to customize the video feed for people who opt to use avatars. Audio-only recording is a meeting option to suppress the video feed that flows into the meeting recording for all users, no matter whether they use Teams desktop, browser, or mobile clients. Participants can have their cameras turned on during meetings, but only the audio feeds will make it into the .MP4 file created in the meeting organizer’s OneDrive for Business account.

Suppressing the video feed for the recording means that anyone who plays the recording afterwards cannot see how the participants appeared during the meeting, including if any avatars are used. All the playback can deliver is the audio stream. This is what Microsoft means when they refer to a more privacy-conscious approach. It seems reasonable to say that if you’re not in a meeting, privacy of the participants is better respected if you cannot see how people appeared during the meeting.

The ability to generate a meeting transcript depends on the audio feed, so suppressing the video feed has no impact on the transcript.

No Administrative Controls

There doesn’t seem to be any administrative control in the Teams meeting policy for an organization to decide that audio-only recording is the default or only option for Teams meetings. Microsoft says that administrator intervention is unnecessary because audio-only recording “integrates into existing workflows.” In other words, “Audio only” is an option in a drop-down menu for an organizer to decide what to record for a meeting (Figure 2).

See the Microsoft documentation for more information about recordings for Teams meetings.

Little Value in the Video Stream in Recordings

It took me a little while to work out why Microsoft wanted to introduce audio-only recordings for Teams meetings. After thinking things through, I think this is a good idea. Few of us really want our visual appearance to be replayed in recordings, and it’s uncertain if the video stream adds much value to those who listen to recordings after an event. The transcript is a much more valuable artifact, especially if Microsoft 365 Copilot can reason over it to produce a summary and action items.

Learn about managing Teams 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.

Agenda Auto-Draft Available for OWA and the New Outlook

Microsoft is doing its level best to convince Microsoft 365 tenants to invest in Copilot. Given the massive capital investment in datacenters to power AI experiences, it’s unsurprising that engineering groups are busy infusing Copilot features into as many applications as possible. Features like Copilot memory add value and help dissuade tenants from investigating other options, such as the ChatGPT Connector for SharePoint Online and OneDrive for Business.

Of course, a SharePoint connector is limited when compared to the breadth of integration of Copilot across the Microsoft 365 apps. Because Copilot works well for some and not for others, work continues apace to find new ways to integrate AI in daily tasks. This brings me to message center notification MC1171854 (13 Oct 2025), which describes “Intelligent agenda suggestions for calendar events.” The feature is available now, but only to users with Microsoft 365 Copilot licenses.

Agenda Auto-Draft Uses AI to Generate Some Bullet Points

At first glance, I didn’t see much to get excited about. The description says that AI is used “to automatically generate a proposed agenda when users create or edit a calendar event, making it easier to align meeting goals, participants, and discussion topics.” I’ve never had any problems coming up with a few salient points for a draft meeting agenda, and agendas have a nasty habit of changing as soon as meetings start. However, I can see the value of being able to create some bullet points to frame an agenda.

What happens is that Microsoft has updated the calendar scheduling form to add an auto draft an agenda option to the set of prompts available when the Draft with Copilot button is used. When the auto draft option is used, Copilot uses the meeting subject to generate an agenda composed of some introductory text and some bullet points. Copilot has always been good at generating bullet points in document and message summaries!

In Figure 1, the meeting subject is Review Chapter Updates for Office 365 for IT Pros. Copilot’s suggested agenda items seem reasonable, and it looks as if Copilot discovered that Office 365 for IT Pros is an eBook from information found internally or on the web (Bing search).

If the meeting organizer doesn’t like the draft agenda, they can simply instruct Copilot to retry or adjust the text by making the agenda longer or shorter. The changes proposed in further versions are not dramatic, likely due to using the meeting subject as the core input to the AI processing.

Eventually, the suggested text is accepted or rejected. If accepted, it can be further edited before the meeting notice is sent.

Now Available Worldwide

Auto-draft of meeting agendas is now a default feature that is enabled in OWA and the new Outlook. According to Microsoft, the feature was enabled worldwide from October 9, 2025.

There’s no administrative control to enable or disable auto-draft for meeting agendas. Given the dramatic difference between the scheduling interface of Outlook classic, it’s unlikely that auto-draft of agendas will find its way into that client.

New Feature that Won’t Move the Needle

Agenda auto-draft won’t move the needle at all when the time comes for Microsoft 365 tenants to decide whether to embrace Microsoft 365 Copilot. It’s a feature that will please some people (those who scheduled meetings and discover how to use agenda auto-draft). For most, I suspect that this is one of the Copilot features that will pass them by because they never need to create an agenda. But that’s always true for new software features.

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.

Use Secret Management to Store and Manage Secrets Needed by Azure Automation Runbooks

Storing hard-coded account credentials in PowerShell scripts is a big security no-no. Previously, I’ve discussed using Azure Key Vault to store passwords and other credentials that might be needed by PowerShell scripts or Azure Automation runbooks. Another method that I’ve used with runbooks is to store the credentials as an automation account resource, most recently when using the Connect-IPPSSession cmdlet to update a Microsoft 365 retention policy. Unhappily, the security and compliance cmdlets don’t currently support managed identities.

Although storing credential objects is the easiest way to make credentials available to an automation account, I would prefer to avoid duplication by using Azure Key Vault everywhere. This decision this brought me to the Secret Management PowerShell module. Essentially, the module supports an easy-to-use connection to Azure Key Vault (and other repositories) to access secrets stored in the vault, like usernames and passwords.

Installing the Secret Management Module

First, install the Secret Management module from the PowerShell gallery.

Install-Module Microsoft.PowerShell.SecretManagement -Repository PSGallery -Force -Scope AllUsers

Remember to make the module available in any Azure Automation runtime environments where runbooks will use the module to fetch secrets. The module only supports PowerShell core, so I tested runbooks with a custom PowerShell 7.4 runtime environment. I also used V3.9 of the Exchange Online management module and V6.3 of the Az.Accounts module.

Registering Azure Key Vault with Secret Management

Before you can fetch any secrets from a vault, you must register the vault for the current session. The Secret Management module supports access to Azure Key Vault through one of its default extensions, but first a connection is needed an Azure account that’s linked to a subscription. Interactively, you’d do something like this:

Connect-AzAccount -Subscription 25429342-a1a5-4427-9e2d-551840f2ad25

In an Azure automation runbook, you can use a managed identity:

Connect-AzAccount -Identity

In this case, the secrets I need to use are stored in an Azure Key Vault called “Office365ITPros.” To access Azure Key Vault, the signed-in account must have permission to the target vault granted via a legacy access policy or an appropriate Azure RBAC role. This requirement also applies to the automation account used to execute runbooks, where permission is granted to the automation account’s service principal.

With the necessary access, I can use the Register-SecretVault cmdlet to connect to Azure Key Vault for the current session as follows. The call to the Get-SecretVault cmdlet is to confirm that the registration worked.

$parameters = @{
    Name = 'Azure'
    ModuleName = 'Az.KeyVault'
    VaultParameters = @{
        AZKVaultName = ‘Office365ITPros'
        SubscriptionId = (Get-AzContext).Subscription.Id
    }
    DefaultVault = $true
}
Register-SecretVault @parameters

Get-SecretVault
Name  ModuleName  IsDefaultVault
----  ----------  --------------
Azure Az.KeyVault True

Fetching and Using Secrets in an Azure Automation Runbook

Once a vault is properly registered, the Get-Secret cmdlet can fetch secrets from the target vault. We need to combine the secrets holding the username and password for an Exchange Online administrator account into a credentials object. The object can then be used with the Connect-ExchangeOnline and Connect-IPPSSession cmdlets to connect to Exchange Online and the compliance endpoint before running the cmdlets necessary to complete whatever task is required.

This example shows how to list the sensitivity labels defined in the tenant after making all the necessary connections and registrations. The full code is listed below. Figure 1 shows the output from the Azure automation test pane.

Connect-AzAccount -Identity

$parameters = @{
    Name = 'Azure'
    ModuleName = 'Az.KeyVault'
    VaultParameters = @{
        AZKVaultName = 'Office365ITPros'
        SubscriptionId = (Get-AzContext).Subscription.Id
    }
    DefaultVault = $true
}
Register-SecretVault @parameters
Get-SecretVault

$UserName = Get-Secret -Name ExoAccountName -AsPlainText -Vault Azure
$Password = Get-Secret -Name ExoAccountPassword -Vault Azure

$Credentials = New-Object 'Management.Automation.PsCredential' $UserName, $Password

Connect-ExchangeOnline -Credential $Credentials -DisableWAM
Connect-IPPSSession -Credential $Credentials
Get-Label | Format-Table ImmutableId, DisplayName

Secret Management is an Alternative to Credential Resources

There’s no doubt that storing credential objects as Azure Automation resources is the easiest way to manage credentials used with runbooks. However, the credential objects are associated with individual automation accounts and not shared elsewhere. Putting credentials in Azure Key Vault and accessing those credentials using the Secret Management module isn’t much harder, and those credentials are available to any user or service principal that’s allowed access to the key vault. You pay your money and make your choice…

Need help 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.

Making Conditional Access and the My Sign-Ins Portal Work Better

A couple of weeks ago, I attended a keynote at the TEC 2025 conference where Alex Simons, Microsoft Corporate VP for Entra, discussed the investments Entra is making to develop agents to help tenant administrators to work smarter. There’s a cost to these agents in the form of Entra premium licenses and the security compute units required to run the agents. Microsoft’s bet is that they can deliver sufficient value to customers through agents to take the cost question off the table. Time will tell.

The Conditional Access optimization agent is one of the agents Microsoft has available in preview. I think both agents can do more and have said so both in print and in person. At this point, the conditional access agent seems more practical and likely to have an impact simply because it’s so easy to screw up conditional access policies.

Which brings me to a LinkedIn post by David Nündel reporting that Microsoft has exposed several additional first-party applications in the Entra admin center. There’s nothing really surprising here because Microsoft 365 and Entra ID are constructed from many multitenant applications. Instances of these applications exist in customer tenants (or rather, service principals for the applications) that can then be used in different aspects of tenant management.

Applications and the My Sign-Ins Portal

What is surprising and useful is that the newly-exposed applications relate to the My Sign-ins portal where users can perform actions such as changing their password, removing themselves as guest accounts from other Microsoft 365 tenants, and viewing recent sign-in activity (Figure 1).

The point is that the My Sign-ins portal relies on access to several applications to display the information revealed by the various menu options. If access to the applications is blocked by something like a conditional access policy, then the portal cannot function. And as it so happens, the newly revealed applications are those that are needed by the My Sign-Ins portal. Six applications are in the set with the following display names and application identifiers:

• My Signins: 19db86c3-b2b9-44cc-b339-36da233a3be2
• My Profile: 8c59ead7-d703-4a27-9e55-c96a0054c8d2
• Microsoft App Access Panel: 0000000c-0000-0000-c000-000000000000
• AADReporting: 1b912ec3-a9dd-4c4d-a53e-76aa7adb28d7
• Windows Azure Active Directory: 00000002-0000-0000-c000-000000000000
• Azure Credential Configuration Endpoint Service: ea890292-c8c8-4433-b5ea-b09d0668e1a6

Checking Service Principals for the My Sign-Ins Portal Applications

Service principals for most or maybe all of these applications are likely already present in your tenant. When I checked using the Microsoft Graph PowerShell SDK command shown below, only the My SignIns application was missing:

Get-MgServicePrincipal -filter "displayName eq 'Azure Credential Configuration Endpoint Service' or displayName eq 'Windows Azure Active Directory' or displayName eq 'AADReporting' or displayName eq 'Microsoft App Access Panel' or displayName eq 'My Profile' or displayName eq 'My SignIns'" | Format-Table DisplayName, Id, AppId

DisplayName                                     Id                                   AppId
-----------                                     --                                   -----
My Profile                                      1f1f813e-0778-4b5b-a379-a924c97e023f 8c59ead7-d703-4a27-9e55-c96a0054c8d2
AADReporting                                    31bd9b44-bc6b-42df-9be6-3030109b84a5 1b912ec3-a9dd-4c4d-a53e-76aa7adb28d7
Microsoft App Access Panel                      10334c63-ac46-4b2a-a80a-dc9c62e34dd8 0000000c-0000-0000-c000-000000000000
Windows Azure Active Directory                  2be71509-6ab9-44d7-bfd8-eff4e50bfc7c 00000002-0000-0000-c000-000000000000
Azure Credential Configuration Endpoint Service 6d1fdc7c-f64b-4aeb-9133-5246b467035c ea890292-c8c8-4433-b5ea-b09d0668e1a6

The problem was easily fixed by running the New-MgServicePrincipal cmdlet:

New-MgServicePrincipal -AppId 19db86c3-b2b9-44cc-b339-36da233a3be2

DisplayName Id                                   AppId                                SignInAudience      ServicePrincipalType
----------- --                                   -----                                --------------      --------------------
My Signins  a7cda215-2932-4042-8e3e-631ecf7ae23b 19db86c3-b2b9-44cc-b339-36da233a3be2 AzureADMultipleOrgs Application

The command to create a service principal from an application identifier works because the My SignIns application is a multitenant application owned by Microsoft. We can prove this by using the tenant relationship API to check the value of the identifier for the owning tenant. Using the Find-MgTenantRelationshipTenantInformationByTenantId cmdlet requires the Graph CrossTenantInformation.ReadBasic.All permission:

$AppTenantOwner = (Get-MgServicePrincipal -ServicePrincipalId a7cda215-2932-4042-8e3e-631ecf7ae23b).AppOwnerOrganizationId
Find-MgTenantRelationshipTenantInformationByTenantId -TenantId $AppTenantOwner
Write-Host ("The tenant name is {0} and its default domain is {1}" -f $TenantInfo.displayName, $TenantInfo.DefaultDomainName)

The tenant name is Microsoft Services and its default domain is sharepoint.com

No Point in Repeating What’s Already Available

With all the applications in place, you can use them in conditional access policies. I don’t like repeating information that’s already online, and I hate seeing many different descriptions of a new feature published by people who haven’t bothered to add any personal insight or knowledge to help others understand the technology better.

With that point in mind, you can read about how these applications could be used in a description of configuring conditional access for guest users by MVP Kenneth Van Surksum. Kenneth adds a few more applications to the “must exclude from blocking” list, so it’s important that you read the article. Excluding applications in conditional access policies simply allows users to access applications that they need to do their jobs, or to make functionality work, like the exclusion required by Outlook to handle sensitivity labels.

Now all I want to know is whether the Entra conditional access optimization agent is ready to optimize for this condition. I suspect not, because it’s clear that first generation agents solve immediate issues (like stopping people from locking themselves out) rather than delivering great insight into more subtle policy details.

Offline Access Lets Clients Like Outlook Work with Protected Content

The use of Microsoft Purview sensitivity labels to protect confidential files and messages seems to be more widespread. Although Microsoft doesn’t publish data to say how many Microsoft 365 tenants use sensitivity labels or the percentage of files stored in SharePoint Online and OneDrive for Business that are protected by sensitivity labels, my guess is that use has grown steadily over the last few years. Certainly, Microsoft is encouraging the use of sensitivity labels by increasing its use in different places. For example, implementing dynamic watermarking, preventing Microsoft 365 Copilot from using content from documents with specific sensitivity labels in AI-generated responses, and removing the requirement to pay to use the Graph API to assign sensitivity labels programmatically. These are all good signs that the sensitivity label framework is developing and building out nicely.

Offline Access to Protected Content

Protecting files with encryption applied by assigning a sensitivity label is a core piece of functionality. Encryption is managed by the Azure Rights Management service, which controls the interpretation and enforcement of the access rights assigned to users through sensitivity label settings.

When an authenticated user attempts to access a protected item, they obtain a use license from the Azure Rights Management service. The use license is a certificate containing the access rights for the item (like whether the user can print the item), the encryption key used to encrypt the content, and if access expires at any point. Importantly, the validity of the use license is limited.

If access to the item is not date-limited, the service issues a use license with a validity period based on the offline access setting contained in the sensitivity label (by default, 30 days). The validity period controls when the user must next authenticate to continue to have access to the item. In practical terms, during the validity period, the existence of the use license means that the user doesn’t need to prove their right to access the content. This is the basis for offline access to protected content by clients such as Outlook. The use license is available on the workstation and can be used to access the protected item even when a network connection is unavailable.

Once the validity period expires, the user is prompted to reauthenticate. During the reauthentication process, the service checks the label settings and evaluates group membership (if used to grant access rights) to establish precisely what rights the user has to the item before it issues a new use license.

Setting the Access Period for a Sensitivity Label

You can restrict the maximum period for offline access on a per-label or tenant-wide basis. To change the validity period for a label, edit the Allow offline access setting (Figure 1) and select the number of days for offline access. Always means that the label uses the maximum validity period for the tenant. Never means that items protected by the label cannot be accessed offline.

Changing the Maximum Validity Period for a Tenant

A sensitivity label cannot have a longer offline access period than the tenant maximum validity period. While 30 days is a good balance between frequent user reauthorization and maintaining security for offline content, some believe that a shorter period is better because it limits the ability of people who leave the organization to access sensitive information. A use license is bound to the device where access occurred, so to continue to have access to the protected content, the person who left must have access to the device.

In any case, a tenant administrator can change the validity period setting for the tenant with PowerShell using the Set-AipServiceMaxUseLicenseValidityTime cmdlet from the AIPService module. The AIPService module only supports Windows PowerShell (5.1). Don’t bother trying to run it on PowerShell 7. Here’s an example of setting the period to 14 days:

Import-Module AIPService
Connect-AipService
Set-AipServiceMaxUseLicenseValidityTime 14
WARNING: The MaxUseLicenseValidityTime will be updated by this operation.

Confirm
Are you sure you want to perform this action?
Performing the operation "Set-AipServiceMaxUseLicenseValidityTime" on target "current organization".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
The MaxUseLicenseValidityTime for the Azure Information Protection service has been successfully set to 14.

Get-AipServiceMaxUseLicenseValidityTime
14

The adjusted validity period only applies to newly-issued use licenses. The new value can be anything from 0 to 65535 days (which should be enough for anyone).

Test Before Deployment

As always, it’s best to make changes to settings like the maximum validity period in a test tenant to assess if the change breaks anything. I don’t think it will, but it’s always best to test, assess, and then deploy.

Learn about managing sensitivity labels and the rest of Microsoft Purview Information Protection 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.

SharePoint Connector Throws Down the Gauntlet to Microsoft 365 Copilot

An October 8 LinkedIn post announced that OpenAI business customers can “centrally deploy SharePoint for their entire workspace,” The move throws down the gauntlet to Microsoft 365 Copilot by delivering the same kind of ability to reason over files stored in SharePoint Online and OneDrive for Business. While Microsoft 365 Copilot boasts more points of integration with Microsoft 365 apps, including SharePoint agents, the new Knowledge agent (in preview), and the ability to consume SharePoint content in custom agents built with Copilot Studio, I don’t think anyone in Microsoft will be happy to see OpenAI offer customers the opportunity to fully exploit the information stored in SharePoint Online.

Given that Microsoft 365 Copilot uses the OpenAI models, including GPT-5, it’s hard to know why companies opt for OpenAI enterprise, especially if those companies use SharePoint Online (which implies that they use Microsoft 365). List prices for the two offerings is compatible, but Microsoft 365 Copilot delivers more integrated functionality.

OpenAI and SharePoint Online

OpenAI has long offered the ability for individual users to connect to OneDrive for Business accounts and SharePoint Online sites. Access is granted through OAuth authentication against Entra ID and is limited to the information accessible to the user, just like any other app that uses the Graph API to interact with SharePoint Online and OneDrive for Business. Because the OpenAI connector is an app, the app can be blocked to prevent users from being able to upload information to OpenAI.

The description of the ChatGPT SharePoint Connector says “The admin-managed sync connector lets an administrator authenticate once and deploy across the entire organization. Users don’t need to set up anything themselves—it just works. To configure the connector, administrators must be both a SharePoint Online (or tenant) administrator and a ChatGPT administrator. During the configuration, the administrator can choose to synchronize all files or scope the connector to specific sites and folders, with the synchronized copies appearing in ChatGPT as “admin-managed” files. According to OpenAI, new files or updates made to SharePoint files are available to ChatGPT within an hour.

Access to files is governed by “strict email domain matching between SharePoint and ChatGPT. A user’s SharePoint account must match their ChatGPT account email.” I guess this means that user principal names must match the email addresses used to create ChatGPT accounts for ChatGPT to allow access to synchronized files. Of course, Microsoft 365 does not insist that user principal names match a user’s primary SMTP address, so there’s some opportunity for mismatches here.

OpenAI notes that synchronized connectors are only available to customers based in the U.S. that enable data residency or international customers who don’t mind that their data is stored in the U.S. They note that “We don’t yet support in-region storage for non-US data residency configurations.”

The SharePoint Connector

Overall, it seems like the new version of the ChatGPT connector uses application permissions like Sites.Read.All and Files.Read.All to access SharePoint and OneDrive content and synchronize it to ChatGPT, while User.Read.All, Group.Read.All, and GroupMember.Read.All permissions are used for account matching. An example of an app using Graph permissions to read SharePoint is available here.

One thing that’s become painfully obvious since the introduction of Microsoft 365 Copilot is that Microsoft 365 tenants store some complete rubbish in SharePoint Online. Old files and misleading and inaccurate content is stored alongside interesting and useful information, but Copilot can’t tell the difference between the two. Add in some sensitive and confidential information that should never appear in AI-generated output, and you can understand why Microsoft has struggled to make Copilot work for SharePoint in the real world (rather that carefully curated demos). Solutions like Restricted Content Discovery and the DLP Policy for Copilot allow organizations to hide content from Copilot or stop Copilot using information in its responses. It’s taken time for these solutions to arrive, but things are much better now.

OpenAI has the advantage of learning from Microsoft’s toils. It seems like OpenAI uses scoping to restrict what SharePoint content ChatGPT can process, which is kind of like what Restricted Content Discovery does.

Why Use the OpenAI Connector?

Apart from avoiding having to buy Microsoft 365 Copilot licenses, I could never understand why Microsoft 365 tenants let people upload corporate information to ChatGPT for processing. The enterprise SharePoint connector is even worse in my eyes, even if OpenAI guarantees that the information loaded through the connector is never used to train its models.

The notion of synchronizing SharePoint files to ChatGPT so that they people can use that content with ChatGPT seems a little crazy. As far as I can tell, OpenAI offers none of the compliance functionality that Microsoft has developed to protect and secure SharePoint Online. For instance, how does ChatGPT deal with files protected by sensitivity labels?

It seems like once the connector copies SharePoint Online sites to ChatGPT, a Microsoft 365 tenant runs some risk of losing control over information. It’s hard enough to persuade people to store important files in SharePoint Online rather than OneDrive for Business. Adding ChatGPT to the mix makes the task of managing corporate files even harder.

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.

It’s Nice to be GA, but What Can You Do with the Copilot Usage Report API?

MC877369 first appeared in August 2024 to announce the availability of Microsoft 365 Copilot usage data through the Graph usage reports API (Microsoft 365 roadmap item 396562). The most recent update (6 Oct 2025) sets out a new timeline for general availability of the APIs, which is now expected to roll out in late October 2025 for worldwide completion in late November 2025. Microsoft doesn’t say why the latest delay occurred or why it’s taken so long to move the API from preview to GA.

Still at the Beta Endpoint

Although the Copilot usage report API is heading for general availability, it’s still only accessible through the beta endpoint. There’s nothing wrong with that, providing the API works. Normally, Microsoft Graph APIs accessible through the beta endpoint are under active development to solve performance or reliability problems, or to complete the features necessary to move to production (V1.0) status.

Using the Copilot Usage Report API

I first looked at the API in September 2024 and concluded that most value can be derived from the Copilot user activity detail API. Knowing what apps people use Copilot in is valuable information if you want to do things like:

• Knowing what departments Copilot is being used in and those that need a little help to get going. By including user data from Entra ID with Copilot usage data, we can slice and dice the usage data to generate additional insights (Figure 1).

• Look for user accounts with expensive ($360/year) Microsoft 365 Copilot licenses and automatically remove underused licenses so that the licenses can be reallocated to people who might use them more. The folks who lose the Microsoft 365 Copilot licenses might be happy with the no-charge Microsoft Copilot chat capability. Or they might be the folks in the company who are using ChatGPT and other AI tools instead of Copilot.
• A variation on the theme is to integrate Microsoft 365 audit data with Copilot usage report data to drill down into what people are doing with Copilot. The intention once again is to weed out underused Microsoft 365 Copilot licenses so that others might be assigned those licenses.
• I have a script to create a composite picture of user activity across multiple workloads. It would be easy to add the Copilot usage data to the mix.

Example PowerShell scripts are available to demonstrate the principles explored in each scenario. The point is that usage data is interesting in its own right, but it becomes more powerful when combined with other easily-accessible Microsoft 365 data sources about user activity.

Remember to allow full display of usernames and other information for the report data. If you don’t, the usage data will be obfuscated (concealed) and won’t be able to match up with data from other Microsoft 365 sources.

Other Usage Report APIs

Microsoft 365 supports a bunch of other usage reports APIs for different workloads. Not all workloads featured in the Microsoft 365 admin center are available through a Graph API (like Forms, Project, Visio, and Viva Learning). The same is true for some sub-reports (like Copilot agents). However, there’s enough data available to be able to build a good picture of how people use Microsoft 365 across the board.

The issue with reporting SharePoint URLs (first reported in September 2023) persists. Some security issue is apparently cramping Microsoft’s ability to include site URLs in the site activity report (powered by the getSharePointSiteUsageDetail API), which means that the usage data returned for a site looks like this:

Report Refresh Date      : 2025-10-07
Site Id                  : 66bbf297-2f09-43ec-ab94-9333deacf769
Site URL                 :
Owner Display Name       : Project Haycock Owners
Is Deleted               : False
Last Activity Date       : 2025-05-23
File Count               : 375
Active File Count        : 131
Page View Count          : 0
Visited Page Count       : 0
Storage Used (Byte)      : 110786012
Storage Allocated (Byte) : 27487790694400
Root Web Template        : Group
Owner Principal Name     : projecthaycock@office365itpros.com
Report Period            : 180

The Site Id can be used to find the website URL:

(Get-MgSite -SiteId '66bbf297-2f09-43ec-ab94-9333deacf769').WebUrl
https://office365itpros.sharepoint.com/sites/projecthaycock

It’s a mystery why Microsoft won’t or can’t fix this irritating issue. Just one of those cloud mysteries…

October 14 2025 is a Big Day for Exchange Server

On October 14, 2025, Exchange Server 2019 reaches its formal end-of-life. The same is true for Exchange Server 2016 and the only supported version of an Exchange on-premises server is Exchange Server Subscription Edition (SE). No cataclysmic event will happen on October 18, and servers will continue to work as before and not burst into flames spontaneously, but the transition to subscription-based licensing is a big event in the 29-year history of Exchange Server (to date).

To be fair to Microsoft, they have made the technical aspect of the upgrade to Exchange SE very simple. Exchange SE is essentially the same as Exchange 2019 CU15 with some extra tweaks. I’ve only heard of minor difficulties during server upgrades. The biggest issue customers seem to have is understanding exactly what licenses they need to run SE (the same as Exchange 2019), especially in hybrid environments where the organization has Microsoft 365 licenses and there is a very small (but important) presence on-premises.

Moving to Cloud First Identity

Speaking of the on-premises presence, Microsoft released its Guide for Cloud-First Identity Management (guidance for IT architects) to lay out principles for transferring the Source of Authority (SOA) for user and group management from Active Directory to Entra ID in what Microsoft calls a “phased, low-risk migration path” to minimize the use of Active Directory.

There are many threads involved here. Organizations want to improve their security posture and remove a dependency on Active Directory that might be exploited by attackers. Moving as much as possible to Entra ID makes sense from an administration perspective too because better tools and APIs are available for that platform. Microsoft wants customers to move to Entra ID not only to improve security but also to enable a market for its Entra premium licenses and products, like ID Governance. Apps that depend on Active Directory for authentication are the usual blocker because these apps must be upgraded to authenticate with Entra ID, and sometimes there isn’t the knowledge or drive to do this work.

Microsoft can encourage the move to cloud-first identities by helping organizations to move system objects like users and groups to Entra ID. Exchange Server has a big influence over Active Directory. Exchange 2000 was the first enterprise application to exploit Active Directory (based in many ways on the Exchange 5.5 X.500 Directory Store) and the two have stayed in lockstep since. Moving mail-enabled recipients like accounts with mailboxes, contacts, public folders, and groups from on-premises to the cloud enables the removal of the last Exchange Server, unless one is needed to provide SMTP routing for apps and/or devices.

The HVE Conundrum

Speaking of SMTP routing, last year I wrote about Microsoft’s High Volume Email (HVE) and Email Communication Services (ECS) solutions. Both are based on Exchange Online. In an attempt to clarify the roles of the two products, Microsoft removed the limited ability to send email to external recipients from HVE and points customers who want to send large quantities of email outside their tenant to ECS.

HVE is still in preview with general availability now scheduled for March 2026. Microsoft posted the latest update five months ago to say that support for Basic authentication would persist in HVE until September 2028. The move is indicative of the pressure from customers because of the issues involved in upgrading apps and devices to use modern (OAuth 2.0) authentication. I’m not sure that the new date is feasible because I hear that many organizations have multi-function devices that use SMTP to send email via Exchange Online that have zero chance of being upgraded. Will customers cave in and junk these devices or will more pressure go into Microsoft to extend the retirement date for basic authentication even further. We shall see.

Auto-Archiving for Exchange Online

On October 7, Microsoft announced auto-archiving for Exchange Online, due to be rolled out to commercial tenants later this month and into the government cloud in November 2025. Archiving has been around since Exchange 2010 and Exchange retention policies can configure a move to archive action for items after they reach a certain age (still an unsupported action for Microsoft 365 retention policies).

The new feature moves the oldest items from user mailboxes to their archive mailboxes when mailboxes become 90% full. For most Exchange Online mailboxes, that point is reached when mailboxes use 90 GB of the normal 100 GB quota. The idea is that “threshold-based” archiving is more proactive and effective than when the Managed Folder Assistant only moves items based on date. It seems like a good idea and I’m looking forward to seeing it in action (not that my mailbox is close to 90 GB).

Update: After a bunch of adverse comments, Microsoft has paused the introduction of auto-archiving to do some more preparatory work.

Two Types of Contacts

You might not know this, but Exchange Online supports two types of contact object. The MailContact object is a mail-enabled object (for example, every guest account has a matching mail contact object), and the Contact object is not. Microsoft has decided to deprecate the Contact object from December 2025. I don’t think this should cause any disruption because as far as I can tell, Contact objects are vestiges of long-forgotten synchronization with on-premises Exchange.

Don’t use the PowerShell example from the article to check your tenant for Contact objects. Always use server-side filtering, so the right command is:

Get-Contact -RecipientTypeDetails Contact -ResultSize Unlimited

On the other hand, who cares if a single PowerShell command isn’t as fast as it can be? You’ll only run it once.

The Need to Make Teams Chat Section Names into Visual Anchors

Still amazed by the news that Teams reactions to chat and channel conversations support up to 20 emojis (apparently to convey nuanced responses), the news delivered in MC1166877 (6 October 2025, Microsoft 365 roadmap item 503300) that Teams will support emojis in section names for chat and channels quite blew my mind.

Microsoft says that they’re introducing the feature to allow “users to personalize and visually organize their workspace more expressively, aligning with familiar experiences from other collaboration platforms like Slack.” In other words, because Slack plasters emojis around its interface, Teams must follow. In this case, the desktop and browser clients get the feature first followed by mobile clients, with deployment scheduled to targeted release tenants in early November 2025. If all goes well (and what can go wrong with an emoji?), general availability will follow in late November 2025 to all commercial and education tenants. Think of it as a thanksgiving present.

Chat and Channel Sections

Teams introduced sections as part of the new Chat and Channels experience in late 2024. Sections allow users to organize chats and channels into convenient groupings that make sense to the user, For example, I have a section for chats with the individual members of the Office 365 for IT Pros author team. I have another session for chats with people who work at Microsoft, and I use another section for the channels that I think most important in terms of checking for new messages daily, and so on.

Until now, section names are confined to simple text. When the update lands in your tenant, you’ll be able to enliven the section names with emojis. You can create a new section or rename existing sections and insert as many emojis as you like up to the 50-character limit for a section name (Figure 1).

To access the set of available emojis, use the Windows icon and . (period sign) combination. I believe this is the method to insert emojis with MacOS.

Figure 2 shows the kind of “visual anchors” that emojis create for sections. Beauty is in the eye of the beholder, but I’m not sure that the emojis add much to my ability to navigate. Maybe the new section names will grow on me.

Although it will take a little longer for the Teams mobile client to be able to include emojis when creating or editing section names, changes to introduce emojis made in the desktop or web clients show up in the mobile client.

No Custom Emojis

Disappointingly, Teams doesn’t support custom emojis for section names. When I wrote about custom emojis last year, I created several new emojis, including a rather good Mickey Mouse. However, it seems like the set of emojis revealed for picking is limited to emojis supported by the operating system rather than Teams emojis.

No Administrator Control Over Teams Chat Section Names

I know that some tenant administrators will see emojis in section names as a mere frippery, something that Microsoft is wasting time on instead of fixing other problems, so let me note that there’s no control over allowing emojis to be used. Adding emojis to sections is base functionality that cannot be switched off, so the only thing a tenant can do is keep their users in a state of blissful ignorance and hope that no one ever finds out what they can do to create “visual anchors” to navigate through Teams chats and channel conversations.

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.

Make Sure Policy is in Place to Maintain Offline Capability for Chromium 141-Based Browsers

The content of Microsoft 365 message center notifications often seems to assume that the reader understands the basic concepts underlying the news communicated in notifications. That’s not always the case. There’s so much change in the Microsoft 365 environment that few can track everything that happens and understand why a change is important.

MC1150662 is an example. This notification was originally published on 9 September 2025 and revised on 3 October 2025. It contains some important information and an action that tenant administrators should take before Microsoft rolls out an update as part of the deployment of Chromium 141 later this month. At least, I assume a further update is coming because the updates for Edge, Chrome, and Brave today all moved to Chromium version 141 (Figure 1) and the predicted issues have not emerged in any of those browsers.

What Microsoft says will happen is that access to OneDrive for Business, Microsoft Lists, and SharePoint Online document libraries will be prompted to allow access to the local network (Figure 2).

Allowing access via the prompt controls the ability of OneDrive and SharePoint to use offline access to data and to use programs like Microsoft Nucleus, a synchronization engine for data-oriented information like Lists that’s also used by the Microsoft OneDrive Sync Service. Essentially, if access is not allowed, OneDrive synchronization and the intelligent incremental synchronization used by SharePoint Online will stop working.

That’s a pretty serious situation, but I’m not sure that people will realize this from MC1150662. Or maybe people are much smarter than I am, and I should stop worrying.

Updating the OneDrive Client

The easiest item on the must-do list is to make sure that workstations update to at least build 25.164 of the OneDrive sync client. The build number is revealed in the About page of the client settings (Figure 3).

Updating Policies for Workstations

The next item is to deploy the LocalNetworkAccessAllowedForUrls policy to workstations with URL to allow the SharePoint Online and OneDrive for Business URLs to access local network endpoints (the workstation). The registry update file that I used to prepare Edge is:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Edge\LocalNetworkAccessAllowedForUrls]
"1"="https://office365itpros.sharepoint.com"
"2"=https://office365itpros-my.sharepoint.com

Figure 4 shows the update when applied to the system registry.

See the Microsoft documentation for more details about how to apply the LocalNetworkAccessAllowedForUrls policy update for other browsers and for MacOS. One topic that isn’t covered in the documentation is if users with guest accounts need to update the system registry on their workstations to use B2B Sync to download files from SharePoint Online document libraries in host tenants, Without seeing the updated software in action, I assume that the change will require users to add the SharePoint endpoint for the tenants that they want to synchronize with to the registry. For example, if you have a guest account in the Contoso.com domain and want to synchronize files from a SharePoint Online document library that you have access to, you’ll need to include an entry for https://contoso.sharepoint.com.

Microsoft also recommends checking the values for the DisableNucleusSync and DIsableOfflineMode policies to make sure that their settings are as expected to allow users to work in offline mode with synchronized data.

Keep an Eye Out When Chromium 141 Arrives

It took me a while to get my head around the importance and impact of the information contained in MC1150662. The text above is my best interpretation of what Microsoft communicates in the notification. It’s hard to be definite until all the moving parts are available. Feel free to disagree!

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!

Considering the Use of the Get-MgSite and Get-MgAllSite Cmdlets

A reader asked if the the getAllSites Graph API is the best way to retrieve details of SharePoint Online sites with PowerShell. On the surface, the API seems like a good way for apps to fetch details of SharePoint Online sites for processing, especially in multi-geo scenarios, which is why the API exists. The API can also fetch sites for a single-geo tenant. It is implemented as the Get-MgAllSite cmdlet in the Microsoft Graph PowerShell SDK.

The Get Site API also fetches information about sites (implemented as the Get-MgSite cmdlet). The two APIs return sites ordered by creation date, with the most recent sites returned first. Two major differences exist. First, the API only supports the retrieval of sites for single-geo tenants. Second, the Get Site API supports both delegated (for access to the sites is a signed-in member of) and application permissions whereas the getAllSites API only supports application permissions.

The permissions gap means that a SharePoint administrator can sign into an interactive Microsoft Graph PowerShell SDK session and list sites with Get-MgSite, but they cannot use Get-MgAllSite because it doesn’t support delegated permissions.

The problem is easily solved by creating an Entra ID registered app and assigning the Sites.Read.All application permission to the app. You can then use an X.509 certificate (recommended) or app secret (for testing only) to authenticate in app-only mode and use the Get-MgAllSite cmdlet.

In terms of performance, Get-MgAllSite seems to be slightly faster than Get-MgSite. Both cmdlets retrieve the same set of site properties, so there’s no obvious reason why one might be better than the other. In any case, from a practical perspective, there’s nothing to choose in terms of speed when retrieving all sites. Let’s see hopw to find sites with the two cmdlets.

Filtering to Find Sites

To find all sites in a tenant, sign into an app-only session, and run the Get-MgSite cmdlet with the All parameter:

[array]$Sites = Get-MgSite -All

Get-MgAllSite doesn’t have an All parameter and although I have tested it to find > 600 sites without a hitch, I don’t know how it will cope with larger tenants. However, the cmdlet can use filtering to avoid the need to fetch all sites. For example, here’s how to find the set of personal (OneDrive for Business) sites in a tenant. Once again, we’re using app-only mode:

[array]$Sites = Get-MgAllSite -filter "isPersonalSite eq true"

Filtering against a site display name is also supported:

Get-MgAllSite -Filter "displayname eq 'Ultimate Guide to Office 365'"

Another example is using the startsWith operator to find sites:

$Site = Get-MgAllSite -filter "startsWith(displayName,'Ultimate Guide')"

You can also filter to find sites based on the creation date. This example shows how to retrieve sites created in the last month.

$FirstDayOfMonth = (Get-Date -Day 1).ToString('yyyy-MM-ddT00:00:00Z')
Get-MgAllSite -Filter "createdDateTime ge $FirstDayOfMonth"

Get-MgSite can’t filter using the isPersonalSite, DisplayName, or CreationDateTime properties and responds with “Get-MgSite_List: Cannot enumerate sites.”

The closest the Get-MgSite cmdlet gets to filtering is via the Search parameter (which isn’t supported by the Get-MgAllSite cmdlet):

Get-MgSite -Search "Ultimate Guide"

Why Filter Sites with One Cmdlet and Not the Other?

I don’t know why the Get Site API doesn’t support filtering in the same way as the getAllSites API does. Given the apparent similarities between the two APIs in terms of performance and output, there doesn’t appear to be a good reason why the developers chose not to implement filtering for the Get Site API.

Even though the Get-MgSite cmdlet can retrieve all sites, perhaps the reason for the different behavior across the two APIs is because the purpose of the Get Site API is to retrieve details of individual sites. By comparison, the getAllSites API exists to retrieve sets of sites when filtering obviously becomes more important and is therefore implemented. If so, the documentation could clarify the situation better than it does.

Avoid the Top Parameter

Although Get-MgAllSite supports filtering, it currently has a problem when combining filters with the Top parameter. Two issues exist. First, performance (both cmdlet and API request) is much slower when the Top parameter is used. Second, the API ignores the Top parameter and returns all sites that match the filter instead of the number of hits specified in the parameter. For instance, this command returns all the sites created in the last month:

Get-MgAllSite -Filter "createdDateTime ge $FirstDayOfMonth" -Top 1

The problem is reported as issue #3405 for V2.30 of the Microsoft Graph PowerShell SDK.

Mix and Match as the Need Arises

My advice is to use Get-MgSite whenever an app needs to retrieve details of a single site and Get-MgAllSite to fetch details of multiple sites (but only in app-only mode). Both cmdlets include the site identifier in the properties they return, and that’s the critical piece of information for further interaction with sites through Microsoft Graph PowerShell SDK cmdlets or API requests (like this example of accessing site pages or this one of creating a list in a site).

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.

Restore a Conditional Access Policy Only Possible via Graph Requests For Now

Documented but not announced, the beta endpoint for the Microsoft Graph conditionalAccessPolicy resource now supports an API to restore soft-deleted conditional access policies. The restore API is used alongside the API to list soft-deleted objects used with conditional access policies. The APIs are relatively new and have not yet shown up in the Entra admin center, which currently issues a solemn warning if an administrator deletes a conditional access policy (Figure 1).

Finding Soft-deleted Conditional Access Policies

The code to discover if a tenant has any soft-deleted conditional access policies is straightforward. Because the API is relatively new, a cmdlet is not yet available in the Microsoft Graph PowerShell SDK (V2.31). No doubt a cmdlet will appear in a future version.

To discover if any soft-deleted conditional access policies exist, we execute the Invoke-MgGraphRequest cmdlet to run a HTTP request against the API and examine the details of what the API returns. The Policy.Read.ConditionalAccess permission must be available to the interactive session and the signed-in user must hold a suitable Entra role such as Conditional Access administrator or Security administrator.

$Uri = 'https://graph.microsoft.com/beta/identity/conditionalAccess/deletedItems/policies'
$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType PSObject | Select-Object -ExpandProperty Value

If ($Data) {
  Write-Host ""
  Write-Host ("{0} soft-deleted conditional access policies found" -f $Data.count)
  Write-Host ""
  $Data | Format-Table Id, displayName, createdDateTime, deletedDateTime
} Else {
  Write-Host "No soft-deleted conditional access policies found to restore"
}

1 soft-deleted conditional access policies found

id                                   displayName                   createdDateTime     deletedDateTime
--                                   -----------                   ---------------     ---------------
14786eef-facd-41ac-83e6-19b317d3e054 Strong MFA for Hard Deletions 05/02/2025 14:05:07 02/10/2025 17:01:05

The output shows that the API found a soft-deleted conditional access policy. Like other Entra ID soft-deleted objects, conditional access policies remain in the soft-deleted state after deletion. When the retention period expires, Entra removes the policy object permanently and it is no longer recoverable.

Restore a Soft-Deleted Conditional Access Policy

Restoring a soft-deleted conditional access policy requires the Policy.ReadWrite.ConditionalAccess permission. The signed-in user must also hold a suitable RBAC role as described above. This example selects the first item in an array of soft-deleted policies returned using the first example, creates the URL to restore the policy, and executes the request to restore the soft-deleted conditional access policy. A successful restore populates the variable used to accept the output of the Invoke-MgGraphRequest cmdlet, so the code checks the variable to make sure that the restore worked:

$PolicyId = $Data[0].Id
$RestoredPolicy = $null
$Uri = ("https://graph.microsoft.com/beta/identity/conditionalAccess/deletedItems/policies/{0}/restore" -f $PolicyId)
Try {
  $RestoredPolicy = Invoke-MgGraphRequest -Uri $Uri -Method Post -ErrorAction Stop
} Catch {
  Write-Host ("Error restoring conditional access policy {0}" -f $PolicyId)
}
If ($RestoredPolicy) {
  Write-Host ("Successfully restored soft-deleted {0} conditional access policy" -f $RestoredPolicy.displayName)
}

Another way to check that the restore worked is to run the Get-MgIdentityConditionalAccessPolicy cmdlet:

$Check = Get-MgIdentityConditionalAccessPolicy -ConditionalAccessPolicyId $RestoredPolicy.id
If ($Check) {Write-Host "Restore worked!"}

The newly restored policy will be visible in the Entra admin center the next time the Conditional Access Policies page refreshes.

Permanently Remove a Soft-Deleted Conditional Access Policy

If necessary, soft-deleted policies can be removed before the 30-day retention period expires with the delete policyDeleteItem API. Once again, the example uses the first item in an array of soft-deleted policies.

$PolicyId = $Data[0].Id
$Uri = ("https://graph.microsoft.com/beta/identity/conditionalAccess/deletedItems/policies/{0}" -f $PolicyId)
Try {
  Invoke-MgGraphRequest -Uri $Uri -Method Delete -ErrorAction Stop
} Catch {
  Write-Host ("Failed to remove soft-deleted policy {0}" -f $PolicyId)
}

Recovery Options are Always Good

It’s always good to have a get out of jail card that allows the recovery of items deleted in error and the new restore capabilities are a good addition to the PowerShell cmdlets for managing conditional access policies.

I’m not sure how many administrators delete conditional access policies instead of first disabling unwanted policies for a period of a week or so before proceeding to deletion. That’s still the best way of removing conditional access policies from a tenant because everything can be done through the Entra admin center. However, Microsoft has some AI-powered Entra administrative agents in preview. The current set of agents includes the conditional access optimization agent, which is designed to analyze and optimize the conditional access policies found in a tenant, including:

The agent also evaluates all existing enabled policies to propose potential consolidation of similar policies. When the agent identifies a suggestion, you can have the agent update the associated policy with one click-remediation.

If the conditional access optimization agent recommends consolidation into a smaller set of policies, it probably will result in the removal of some policies that are no longer required. Administrators click to action the agent’s recommendations. It’s good to know that if the agent proposes the removal of some policies that should be kept, at least administrators can recover the deleted policies if they go ahead with “one-click remediation.”

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.

Trust Indicators Indicate the Level of Trust in External Users

Unfortunately, social engineering attacks designed to confuse and trick unwary users into doing something that leads to account compromise (and potentially to tenant compromise) continue unabated. According to the last number for monthly active users provided by Microsoft, 320 million people use Teams. That audience represents an attractive target for attackers to go after, and many of the social engineering attacks occur through federated chats from unknown externals users.

The original design for Teams envisaged an open collaborative environment where Teams users from Microsoft 365 domains could connect to Teams users in other domains. Attackers duly signed up trial tenants and used trial Teams licenses to reach out and attempt to connect with targets. Given that the SIP address for most Microsoft 365 users is the same as their primary SMTP address, once an attacker has an email address, they can try to institute a federated chat to that address and hope that the person at the other end responds.

Visual Clues About the Trustability of External Users

Microsoft clamped down on the ability of trial tenants to use federated chat in 2024. But attackers adapt to changed circumstances and keep on trying. This brings us to the announcement of trust indicators for Teams users published in MC1162276 (29 September 2025). Like the external tag applied to email from external sources, a trust indicator is a badge displayed alongside an external user’s name to give tenant users a visual clue about their status.

Public preview for trusted indicators has already started and is expected to be completed in late November. General availability will then roll out the feature to all tenants in all clouds for completion in early January 2026. The documentation for trust indicators describes the different badges used by Teams and where the badges appear, so I won’t go into the details here. However, here are some examples of where you’ll probably see trust indicators in action.

First, Figure 1 shows the participant list for a group chat. I’m a guest user in this chat and the badge and tooltip show that status. A guest user has a high level of trust because they are using an account added to the tenant directory to access Teams. Some might argue that this really doesn’t indicate a high level of trust because guests can be added to the tenant directory without administrative oversight. For example, by sharing a document with an external user.

Figure 2 shows another important point. In this case, we’re viewing the membership of a team and two of the members have no trust indicators. This is because they’re tenant members, so their status makes these members very trustworthy.

Build an Allow List for Teams Communications

Trust indicators are a nice addition to Teams, but I fear that they don’t address an issue that many Microsoft 365 tenants ignore, and that’s the need to control external access for Teams. I accept that it’s nice to be open and collaborative and willing to communicate with anyone in any tenant, but I also consider this to be a dangerous approach to use without question. An open tenant is an invitation to connect, but that allows unwanted visitors to attempt to connect to users.

Tenants can control the tenants that users are allowed to communicate with by establishing an external access allow list. You can build an allow list manually, but it can be difficult to know all the domains that people wish to use. It’s possible to construct the allow list programmatically with PowerShell using sources like the home domains for guest accounts or federated chats with external people. Either source is a good start for an allow list that can then be tweaked to add whatever domains are missing.

The downside of using an allow list to control Teams external access is that anytime someone wants to connect with a user in a domain that’s not in the allow list, they must seek approval for the addition of that domain. That’s regrettable, but it might be better than allowing external connections from any other Microsoft 365 domain, including those controlled by the bad guys.

Small but Important Step

Trust indicators are a small but important step to help Teams users recognize the status of external collaborators. It’s good to have these visual clues, and I hope that the clues help users to be more wary in their external communications. However, maybe it’s even better to close off the holes in Teams external access where undesirable connections can creep in.

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!

Monthly Update #124 for Office 365 for IT Pros Available for Download

The Office 365 for IT Pros team is delighted to announce the availability of the October 2025 update for Office 365 for IT Pros (2026 edition). This is monthly update #124. Current subscribers can download the updated EPUB and PDF files from their Gumroad.com account or by using the View content link in their receipt. See our FAQ for more information about how to download updates.

We’ve also updated the Automating Microsoft 365 with PowerShell eBook, which is now at version 16.4. The updated PowerShell EPUB and PDF files are available at the same location as the Office 365 for IT Pros book files. The paperback version of Automating Microsoft 365 with PowerShell has also been updated and is available on a print-on-demand basis from Amazon.

October Updates and the AI Effect

As usual, a bunch of changes are spread across the book chapters, details of which are in our change log. One thing that’s becoming increasingly notable is the growing percentage of Microsoft 365 message center notifications that relate to AI instead of updates to workloads like Exchange Online, SharePoint Online, and Teams.

It’s easy to understand why this is so. First, many of the Microsoft 365 workloads are very mature and already feature-rich, so less opportunity exists to add new functionality. Second, Microsoft’s development attention is obviously focused on adding as much AI-driven features to applications as possible to encourage customers to buy Microsoft 365 Copilot licenses.

The focus on AI gives us a challenge in deciding how much attention we should pay to Copilot features. We know that many Microsoft 365 tenants don’t use Copilot because the licenses are too expensive, they’ve chosen a different solution (like ChatGPT), or simply don’t see the value of AI in their environment at this point. While adding more Copilot content to the book might delight some tenants, it reduces the value of the book to other tenants.

Our current approach is to include Copilot content where it matters to tenant administration. An example is the configuration of the DLP policy to prevent Copilot Chat including content from sensitive documents in its responses. On the other hand, Copilot features that are user-centric in apps, like the facilitator agent in Teams, are usually not covered in the book. There are many of these features spread across Office and other apps. In addition, the features are in a period of rapid evolution, so documenting their use would occupy lots of time that could otherwise be used to cover topics of more general interest.

As AI becomes more embedded in administration (the initial skills available in Copilot for SharePoint Admin are a poor example of what will increasingly happen), we’ll probably change our guidelines, but that’s our current thinking.

Fixing the PDF Stamping Problem

As many of our subscribers know, Gumroad has struggled to fix a bug in the routine that stamps subscriber email addresses on our PDF files. The symptom is that the PDF is unavailable for download because it is “being prepared.” This doesn’t happen for all PDF downloads, but it happened enough to be a royal pain. Subscribers affected by the problem had to contact us, and the only workaround we had was to reissue the receipt. This action kicked off the PDF stamping routine and most of the time, it was enough to make the PDF available.

The good news is that we think Gumroad has fixed the problem by rewriting the PDF stamping routine. Every month in the recent past we have dealt with several subscribers who hit the problem. We’ll soon know if the Gumroad fix is effective. Fingers and toes are firmly crossed.

On to November 2025

As usual, we have started work on next month’s update (#125). Given that the Ignite conference is in the second half of November, there might be fewer changes to process. Then again, there’s always change in Microsoft 365, so we expect to be busy.

Events from Email Only Extracted When Schema is Correct

The announcement in MC1158908 (24 September 2025) that the Outlook feature that creates events from email is going to insist that event providers must use schema.org templates to format event information from 31 January 2026 is not unexpected. Something had to change because the current implementation doesn’t work in many situations. Some events turn up in calendars, but many do not. Something had to change to restore consistency and dependability to the feature.

The Root of the Problem

Microsoft is not the root of the problem. My personal experience is that providers are radically inconsistent with respect to the information that they include about events like airline reservations and car hire bookings. The problem has become worse recently, possibly because providers treat notification emails as an extension of their corporate branding program and therefore include a bunch of information that makes the emails prettier without making sure that the essential properties for an event are available.

Microsoft says that the current method used to extract event information from email is fragile and often fails. This leads to user dissatisfaction and many support calls. Microsoft believes that their current implementation cannot be enhanced to deal with the many different ways that event providers publish information about events. They want event providers to use a standard method, and that’s where we are heading.

The Outlook Solution for Events from Email

Schema.org is an industry consortium that publishes a reference website for structured information. According to Wikipedia, the main objective of Schema.org is to standardize HTML tags that can be used to create rich results. The solution that Outlook will introduce is to insist that the HTML information about events contained in email generated by providers like airlines, car hire firms, and so on use an appropriate schema template.

For example, the flight reservation schema defines properties like provider (the airline) and reservationId (the six-character reservation identifier assigned by the airline) together with other properties like programMembershipUsed (airline frequent flyer identifier). Populating these properties properly allows Outlook to extract the details of a flight and create a calendar event with that information. Figure 1 shows an event created from details sent by Ryanair in a flight reservation email.

Up to Event Providers to Change

Apart from deciding if they want to configure the settings to instruct Outlook how to extract events from email using either OWA or the new Outlook (but not Outlook classic or Outlook mobile), users don’t have any control over event processing. A background assistant performs the processing to check inbound email and extract event details if present. It is the background assistant that will change from January 31, 2026, and refuse to process events unless the emails containing event information comply with a Schema.org template.

Whether event providers update their email to comply with the change is entirely in their hands. I’m sure that Microsoft will do some outreach with major event providers to ask those companies to support the change and they have an email address (txppro@microsoft.com) for providers who need help to upgrade to support schema.org. However, the nature of this kind of transition is that it might take some time (or even a long time) for a provider to upgrade their systems to generate event notifications in the right format.

Microsoft suggests that customers work with event providers that they use to ask those companies to comply. I guess it might be possible for a customer to ask their major suppliers (like a preferred airline) to support the change, but again, don’t expect a change to happen overnight.

Some Disruption Likely

Given the dependency on event providers to come on board and support the new way to publish event notifications, some disruption is likely to occur, and users might find that events that previously appeared automatically in their calendar no longer show up. That’s regrettable but moving to a consistent approach is a good idea and will benefit everyone in the long run. At least, that’s the plan.

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!

Integrate External Information into Microsoft 365 Copilot Search Results

In July 2025, Microsoft released Microsoft 365 Copilot Search. On its own, Copilot Search is a great way to search SharePoint Online, OneDrive for Business, Teams, and Exchange for information available to the Graph. The more interesting aspect is the ability for tenants with Microsoft 365 Copilot licenses to integrate external sources of information into search. AS Microsoft said at the time:

“Copilot Search leverages Microsoft Graph and Microsoft 365 Copilot connectors to index content across Microsoft 365 and third-party apps. It interprets user context, natural language, behavioral signals, and organizational relationships to deliver highly personalized, context-aware answers to complex queries.”

A Gallery of Microsoft 365 Copilot Connectors

The Copilot section of the Microsoft 365 admin center includes a gallery of off-the-shelf Microsoft 365 Copilot Connectors (previously called Graph connectors). These connectors can be plugged into Copilot search by configuring them to external sources of the relevant type, like the Jira Cloud or ServiceNow (Figure 1). These are called prebuilt connectors (see the online documentation).

If a prebuilt connector isn’t available for your preferred source, you can develop a custom connector. For example, the People platform that Microsoft is building envisages information about people being ingested into the Graph through Microsoft 365 Copilot connectors.

Sometimes it’s hard to get your mind around whether a new feature will be valuable in your environment. If someone in your organization asked, “how can we exploit Microsoft 365 Connectors?”, my guess is that quite a few tenant administrators would struggle to come up with a cogent answer. I’d be in the same position, so decided to take a look at configuring a connector to see what happens.

Configuring the Enterprise Websites Connector

I chose to test the enterprise websites connector, which is designed to ingest material from company or public websites available on the internet. Configuring the enterprise website connector is simple. Essentially, all you need is the https URL for a website. When active, the connector crawls the target website to fetch and index content to include the material into Copilot searches. Given the superb information found in Office365itpros.com and Practical365.com, I decided to configure connectors for both sites. Figure 2 shows the configuration I used to fetch information from the Practical365.com website.

It takes some time for a connector to perform the initial crawl and bring information into Microsoft search. Eventually, the connector status will turn to Ready (Figure 3), and at that point you’ll know that the information retrieved from the website is available for searching.

Searching External Data with Microsoft 365 Copilot Search

Microsoft 365 Copilot Search responds to search requests with information from all the sources available to it. I searched for information about the Microsoft 365 licensing report script that I knew occurs in articles published on Office365itpros.com (here’s one) and was rewarded with an instant hit (Figure 4) with the source that Copilot Search retrieved the information from clearly indicated in the results. Even comments for posts are indexed and available.

Clicking the link brings the user directly to the source page on the website. It’s a very seamless experience.

Even better, if asked to summarize the results, Microsoft 365 Copilot integrates the information from the external websites along with the other Graph-based information available to it. In the summary shown in Figure 5, Copilot cites a source from the Practical365.com site and tags it as “ThirdParty,” meaning that the information comes from a non-standard Graph source.

Easy, Quick, Seamless

Being able to integrate external website content into Microsoft 365 Copilot Search is one of the best features I’ve seen Microsoft launch in the blizzard of AI-related functionality introduced since the Copilot launch in March 2023. Configuring the connector is quick and easy; crawling happens automatically (and a schedule for crawling can be set up); and the results are presented seamlessly alongside items from other Graph sources. It’s a great example of the power of bringing external data into the Graph and can certainly help answer the question of what to do with Microsoft 365 Graph connectors.

Best of all, this is an easy way to integrate information from trusted external web sites into Graph searches. Who wouldn’t want to integrate content from Office365ITPros.com and Practical365.com?

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.

European Union Microsoft 365 Tenants Might Have Highest Level of Concern

On September 24, Microsoft announced an expansion of the AI models used by Microsoft 365 Copilot to include models created and maintained by Anthrophic. Initially, Microsoft says that the Anthrophic Claude Opus 4.1 model can be used with the Copilot Researcher agent, and the Claude Sonnet 4 and Claude Opus 4.1 models can be used to create agents in Copilot Studio. The Anthrophic models are not available in Copilot Chat or other Copilot integrations with Microsoft 365 apps, which continue to use the AI models.

The interesting thing about this change is that it gives Microsoft 365 tenants located in the European Union and elsewhere some issues to consider. Today, Microsoft safeguards the data used in their versions of the OpenAI models to make sure that data does not leave the tenant, compromise the EU data boundary for the Microsoft cloud, or is meets the same standards of privacy and security set down for Copilot.

Although Anthrophic seeks to reassure people about processing information in various locations, no guarantee exist about how using the Anthrophic models with Copilot Researcher or to create Copilot agents maintains the same level of enterprise data protection and integrity that Microsoft has emphasized to date for its AI systems and highlights for the Copilot Researcher agent (Figure 1).

Microsoft Documents the Compliance and Processing Risk

Microsoft’s documentation covering how to connect to the Anthrophic models emphasizes that:

When your organization chooses to use an Anthropic model, your organization is choosing to share your data with Anthropic to power the features. This data is processed outside all Microsoft‑managed environments and audit controls, therefore Microsoft’s customer agreements, including the Product Terms and Data Processing Addendum do not apply. In addition, Microsoft’s data‑residency commitments, audit and compliance requirements, service level agreements, and Customer Copyright Commitment do not apply to your use of Anthropic services. Instead, use of Anthropic’s services is governed by Anthropic’s Commercial Terms of Service and Anthropic’s Data Processing Addendum.

In other words, all bets are off once a tenant goes off the beaten path to explore the glorious uplands of the Anthrophic models. The flat warning given by Microsoft that data will be processed outside the Microsoft environment without any audit controls is stark. It makes other administrative challenges like stopping individual users from uploading files to ChatGPT for processing seem very simple (because uploads are easily blocked).

The loss of all the Microsoft Purview compliance functionality built up around Copilot like the interaction audit records captured by the Microsoft 365 substrate is a big problem. It’s certainly enough to stop all but a few tenants that have a clearly defined and well understood need to use the Anthrophic models from venturing down the path to choose Anthrophic in the Copilot section of the Microsoft 365 admin center (Figure 2).

Where Next?

Choice is always good and Microsoft’s move to expand the pool of available Large Language Models is a worthwhile initiative. Although the targets for the Anthrophic models are currently limited, the guardrails around the use of those models are also limited. Considering the effort expended by Microsoft to develop security and compliance controls for Copilot since the March 2023 launch, it seems that there’s a huge amount of work to be done before third-party models become a serious option for many Microsoft 365 tenants, even in limited circumstances.

The work to bring model choice to Copilot is obviously evolving, and no doubt Microsoft will deliver some of the controls desired by customers over time. Quite how many of the Purview controls can be applied to third-party AI processing remains an open question.

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!

Knowledge Agent to Sort Out SharePoint Metadata

With all the associated hype that’s now the norm for a Microsoft announcement associated with AI, the SharePoint development group launched the preview of the SharePoint Knowledge Agent on September 18, 2025. You think “so what” because SharePoint has supported agents for almost a year. However, those agents reason over the content of files found in a site while the big difference with the Knowledge Agent is that it deals with site metadata and its purpose is to make sites work better rather than to help users find information.

Given Microsoft’s promise that the new agent could help stream content management (aka, sort out the mess that’s in so many sites) to “SharePoint into a dynamic, intelligent knowledge hub that gives your organization a competitive edge,” it seemed like a good thing to test. That is, if you have a Microsoft 365 Copilot license.

Enabling a Microsoft 365 Tenant for the SharePoint Knowledge Agent

With the licensing issue out of the way, the next step is to enable the tenant to support the Knowledge Agent. This can be done for all or selected sites, as described in the documentation. Enabling Knowledge Agent can only be done through PowerShell at this point, and throwing caution to the breeze, I elected for all sites and ran this command after connecting to SharePoint Online:

Set-SPOTenant -KnowledgeAgentScope AllSites

Using the SharePoint Knowledge Agent

There’s no point in testing any software against just a few objects, so I started by testing the Knowledge Agent against a site containing roughly 4,000 files in 10.2 GB of storage. The Knowledge Agent has its own floating action menu, which appears on top of the regular document view (Figure 1).

Given my notorious lack of organization, the Organize this library option seemed like a good place to start. The options (Figure 2) include creating three columns to hold metadata that the agent will generate to make the library easier for Microsoft 365 Copilot to process, creating a rule to do something when an action happens in the library, extract key actions from files to populate an autofill column, and summarize files.

I asked the Knowledge Agent to create some suitable columns. The document library already has some custom columns that I use to organize and search articles that I’ve written. As such, you might think that the library is already well-organized. The agent thought for a bit and then suggested that the library could use columns for the document type, date received, and assigned staff. If you agree, the agent adds the new columns to the existing view or creates a new view that includes the columns.

The important thing is that these are autofill columns. SharePoint auto-fills the properties for new files when they are created, and to backfill the properties for older files, background processes use the Copilot LLMs to generate the necessary information (Figure 3). The backfill process doesn’t happen immediately, and full population of the columns for all items can take some time (many days). The categorization of articles into document type was the most interesting part of the exercise, but nothing was gained from the date received (date the item was uploaded to SharePoint) and assigned staff (always me) columns.

The extract key actions and summarize options also use autofill columns to hold their results. The summaries are like the automatic summaries created by Copilot for Word documents. There’s no indication of if or how often the agent checks files for new or changed text to update the metadata and the autofill status doesn’t provide too much insight into what’s happening. Mostly, the autofill status showed information about processing that occurred over eight hours ago even when it was obvious that the agent had processed files more recently. In Figure 4, the agent updated the summary (for this article) but the autofill activity page lagged way behind.

Obviously, if the agent can’t extract text to summarize, it cannot populate these columns, so expect good results from Office and PDF files and lesser joy elsewhere. The agent experienced some problems with Word documents translated into Japanese by the SharePoint translation service, but on the upside, the agent stripped text nicely out of JPEG files to report what it found there.

Creating a rule calls the standard SharePoint feature, so there’s not much to say about it except that the agent possibly makes it a little easier for people to create rules. However, if they want to make changes to the rule, they’ll still need to go to SharePoint’s Automate menu, select Rules, and then Manage rules.

No Audit Records for Agent Processing

Unlike when humans create SharePoint agents, there’s no trace of Knowledge Agent activity in the audit log. This is perhaps unsurprising because the creation of SharePoint agents is only auditable by checking FileUploaded audit events for .agent files. Other workloads, including Exchange Online, create audit records when background processes perform actions that affect users, so I don’t know why SharePoint Online lags in this respect.

No Real Magic

The Knowledge Agent is a preview and who knows what the final version will deliver. For now, I find little trace of any magic generated by AI in what the Knowledge Agent delivers. But it’s entirely possible that my testing did not cover the kind of scenarios that Microsoft envisages the agent delivering most value, like classifying legal documents, or to help HR organize the resumes for job applicants.

I would have liked to try the agent out on sites with different types of information, but even though the Knowledge Agent is enabled for all sites, its action menu is only available in the first site I chose for testing (the situation persists a week after enabling the Knowledge Agent). There’s got to be something simple that’s going wrong here, but I can’t find an answer to the case of the missing action menu.

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.

Assembly Clashes Happen too Often

In June, I reported a problem with V3.8 of the Exchange Online management PowerShell module when called by Azure Automation runbooks. The problem was caused by the removal of .NET6 support in the Exchange Online module, which meant that runbooks using the PowerShell V7.1 or V7.2 runtime engines couldn’t load. The Microsoft Graph PowerShell SDK did the same thing with the same effect, proving that developers don’t look much outside their own software to discover how problems might occur when software dependencies change.

The Authentication Assembly Dependency

Complex software often has some form of dependency. In the case above, it was the version of .NET that caused problems. New .NET versions appear and have a support schedule, so it’s understandable that software products should move to the latest supported version and want to discard versions that are no longer supported. What’s not understandable is when engineers make changes with no regard to what might happen to customer production scripts.

But an even more irritating problem that continues to happen is Microsoft’s failure to sort out the use of .NET assemblies across important PowerShell modules like the Microsoft Graph PowerShell SDK, Exchange Online management, and Microsoft Teams.

All the modules need to authenticate connections, so they call the Microsoft Authentication Library (MSAL) and load the Microsoft.Identity.Client assembly to allow clients to authenticate. An assembly is a building block for .NET applications. In this instance, the MSAL assembly contains the code necessary to allow an application (like a PowerShell module) to authenticate with Entra ID and obtain the necessary access tokens to work with data.

Connecting with Exchange and then the Graph

Sometimes the Microsoft 365 PowerShell modules fail to use the same version of the assembly, which means that an older version can be loaded into a session and cause a problem for a module loaded afterwards. Take this example using V3.9 of the Exchange Online management module and V2.30 of the Microsoft Graph PowerShell SDK:

PowerShell 7.5.3

Connect-Exchangeonline -showBanner:$false

Connect-MgGraph -NoWelcome

Connect-MgGraph: InteractiveBrowserCredential authentication failed: Method not found: '!0 Microsoft.Identity.Client.BaseAbstractApplicationBuilder`1.WithLogging(Microsoft.IdentityModel.Abstractions.IIdentityLogger, Boolean)'.

Connect-ExchangeOnline runs first and authenticates, so the MSAL assembly it requires is loaded into the session. When Connect-MgGraph runs, it checks for a method that doesn’t exist in the loaded MSAL assembly and barfs. Microsoft’s support guidance for the Microsoft Graph PowerShell SDK recommends using the latest bits, but this problem happened with the latest available release.

The problem goes away if Connect-MgGraph is run before Connect-ExchangeOnline. When this happens, the Graph has the assembly it needs and the Exchange module is happy to use the later version of MSAL.

A Known Problem for Years

Assembly clashing between PowerShell modules has been a known problem for years. A recent issue posted to GitHub notes that Microsoft does not implement assembly loading properly because all assemblies are loaded globally (and so affect all modules loaded into the session) rather than in an application context (just for one module).

The mismatch of MSAL assemblies has been an issue for quite a while (here’s a similar problem report from August 2023). To be fair to Exchange Online, the Azure Accounts module has also experienced assembly clashing with the Microsoft Graph PowerShell SDK.

To be fair to the Microsoft Graph PowerShell SDK, assembly clashing is known between Exchange Online and Microsoft Teams. Figure 1 shows what happens when you attempt to run the Connect-MicrosoftTeams cmdlet (V7.3.1) after running Connect-ExchangeOnline:

It’s kind of weird that Connect-MicrosoftTeams isn’t recognized as a cmdlet. Everything works perfectly when Connect-MicrosoftTeams runs before Connect-ExchangeOnline.

No Change Without Consensus

Assembly clashes will continue until the Microsoft engineering groups coordinate development better to ensure common usage of important .NET assemblies. It doesn’t take much to communicate what version of an assembly a module needs so that everyone can reach consensus on the version modules use. Maybe Copilot could help. In the interim, the only solution is to make sure that the order scripts load modules doesn’t cause a problem, and to repeat that check after each release of important modules.

Change to Beta Graph API Requires Update to User Password and Authentication Report Script

Last year, I wrote about how to exploit the newly-added Graph API to report the per-user MFA state for Entra ID accounts. As with all additions to the Graph, the new API used the beta endpoint, which is where APIs function when Microsoft is happy to expose the API in public while still knowing that some work is needed before the API can advance to the production (V1.0) endpoint.

Recently, a reader posted a comment about the article and said that when they ran the script in their tenant, no data showed up in the “Default MFA method” column in the report. I write scripts to illustrate principals and explore what’s possible rather than attempting to create production-ready code. In addition, it’s impossible for me to see what’s happening in another tenant, unless the tenant administrator gives me the necessary account with permissions, and that shouldn’t happen. My default response is therefore to ask people who report issues to do some basic PowerShell debugging by selecting the code where the problem seems to lie and running the commands to see what happens. Besides, I was on vacation, so I didn’t want to spend any time looking into what the issue might be.

Searching for the Problem

To cut a long story short, the person who reported the problem responded with sufficient data to indicate that an issue was present. After returning from vacation, it was time to open Visual Studio Code (and GitHub Copilot) and try to figure out what was happening.

The code looked good, and nothing seemed out of the ordinary. The script used Graph requests rather than cmdlets from the Microsoft Graph PowerShell SDK, but that’s a normal state with newly-released beta APIs because the AutoRest tool that generates SDK cmdlets from the API metadata hasn’t yet included the cmdlets in an SDK release. To make the code easier to read, I replaced a couple of API requests with SDK cmdlets and then noticed that the output from the Get-MgBetaUserAuthenticationRequirement cmdlet no longer contained details of a user’s default MFA method. This was the cause of the problem.

The Downside of Beta Graph APIs

Using beta APIs (or beta cmdlets) is a double-edged sword. The positive is access to functionality sooner than waiting for Microsoft to upgrade an API to a production release. Some APIs stay in the beta endpoint for years, and you can’t predict when Microsoft might consider an API to be reliable, robust, and performant enough to justify promotion from beta to production.

The downside is that beta features are prone to change based on developer and customer feedback, the need to accommodate changes elsewhere in the underlying workload, or as the side effects of bug fixing or tuning for performance. I have no idea why Microsoft removed the default MFA method output from the data reported by the cmdlet. Maybe it was because the UserPreferredMethodForSecondaryAuthentication property contains similar information.

A New User Password and Authentication Report Script

In any case, my script can only report what’s available, so I updated the code to remove the obsolete column and renamed the UserPreferredMethodForSecondaryAuthentication column to be “Preferred MFA method” (Figure 1). The change seemed to make sense at the time. If you disagree, feel free to create a GitHub push request to update the script. I’m happy to review any and all suggestions.

Don’t Depend on Beta Graph APIs

All of this goes to show that developers who rely on beta Graph APIs need to keep a wary eye out for changes that might impact their code. The change can happen at any time and probably won’t be flagged by Microsoft because it is, after all, a change to a beta API that’s expressly not intended for production use. I should learn my lesson (some day). In the meantime, enjoy the updated user password and authentication report script and all the other examples in the Office365itpros GitHub repository. I’m sure there’s a few more bugs lurking there that I need to attend to.

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.

Version 16 of Automating Microsoft 365 with PowerShell Available for Download

The Office 365 for IT Pros team is proud to announce the October 2025 update for the Automating Microsoft 365 with PowerShell eBook. The book is available separately and as part of the Office 365 for IT Pros eBook bundle. Current subscribers can download the latest files from their Gumroad.com account. See our FAQ for more information about how to download the updated EPUB and PDF files.

The October 2025 update for Office 365 for IT Pros is under development and should be available for download on October 1, 2025. Subscribers can check their account then or wait until they see the update notification posted here.

Current Files are Version 16.2

At the time of writing, the current files are labelled version 16.3 and dated 22 September 2025. I originally created version 16.0 to use as the basis for the paperback version so that I could get some printed copies to take with me to The Experts Conference (TEC) in Minneapolis (September 30-October 1). TEC features a PowerShell script-off where conference participants sign up to compete against others to solve common Microsoft 365 administrative problems, and I wanted printed copies to give to the script-off competitors.

Alas, the best laid plans sometimes come a cropper, and I found changes that I wanted to get into this month’s update not once but twice, which resulted in the 16.1, 16,2, and 16.3 versions. However, the delay involved in print on demand means that the books that will show up at TEC are version 16.0. When you get used to being able to update and publish a book update electronically, reverting to waiting for printing presses to run seems very antiquated, even in a print on demand scenario. Tant pis, or so the French might say.

Exchange SE for Administrators

In other news, Scott Schnoll, who left Microsoft earlier this year, has published The Admin’s Guide to Microsoft Exchange Server Subscription Edition. The book is available from Amazon.com (paperback and Kindle) for a whopping list price of $119.99 (currently available at a discounted $90.07 for the paperback and $99.99 for Kindle) and promises “never before heard details on the development of Exchange Server Subscription Edition.”

There’s no doubt that some confusion exists around Exchange SE, especially in terms of licensing (this FAQ helps), but that’s probably a symptom of the move to subscriptions. To facilitate the changeover, Microsoft made sure that 99.99% of the technical detail for Exchange SE is the same as for Exchange 2019. This position will change as Microsoft adds new functionality to Exchange SE over time.

Whether a new book about existing technology with a high price point will succeed remains to be seen. Amazon takes a large chunk (up to 70%) of the price paid by buyers and that might have dictated the price for a book that targets a declining (but still important) market.

The nice thing about writing about on-premises server products is that authors don’t have to cope with the rapid pace of change experienced in the cloud. However, the details and features of Exchange SE will diverge from Exchange 2019 from this point, so change will come. That change probably won’t be unduly dramatic and Exchange SE will not become like Exchange Online, so the work to keep the book updated shouldn’t be too onerous.

For any self-published book about technology, I recommend using a site like gumroad.com (which we use for Office 365 for IT Pros) or leanpub.com (home of Paul Thurrott’s Windows 11 Field Guide and other great books). Both sites offer authors more revenue for book sales and better control over changes, which is always nice. On the other hand, Amazon offers a decent on-demand paperback printing service that we use for the paperback version of the Automating Microsoft 365 with PowerShell book. You pay your money and make your choice…

On to Version 17

We continue to develop content for Automating Microsoft 365 with PowerShell based on changes and updates to PowerShell modules. I can’t predict what the next month will bring. I can only say that things will happen that will turn up in version 17.

A Logical Progression for Copilot in the Microsoft 365 Apps

The news in message center notification MC1096218 (last updated 17 September 2025) about the rollout of Copilot Chat confirms the worst fears of some that Microsoft is on a one-way path to stuffing Copilot into as many places as it can. Well, that feeling is backed by some truth, but in this case, I think the change is a natural progression of Copilot’s existing presence in apps like Word, where it’s been producing document summaries since last year.

Once Copilot appeared in the Office apps, there was only one way forward, and that wasn’t to see Copilot disappear from Office. Now Copilot Chat is available in Word, Excel, and PowerPoint, just like it has been available in Outlook (new and classic) for a while. Microsoft says that the rollout is expected to complete in the coming weeks, which basically means that it will turn up when the stars align in terms of desktop client Office build and server infrastructure.

Copilot Chat for All

Copilot Chat is available for any user of the Microsoft 365 apps, with or without a Microsoft 365 Copilot license. The difference is that those with Microsoft 365 Copilot licenses can access tenant resources like documents stored in SharePoint Online and OneDrive for Business while those without are restricted to web queries (via Bing search).

Working in Copilot and an Office App

The idea behind the side-by-side implementation is that users can work on a file in the main pane while being able to interact with Copilot in a side pane (Figure 1). It’s a useful feature that makes it easy to take questions from the main file, research them in Copilot, and take the results back into the file.

Apart from anything else, integrating Copilot so tightly into the Office apps makes it less likely that users will seek AI assistance elsewhere and potentially end up uploading documents from SharePoint and OneDrive to services like ChatGPT. It also encourages people to consider upgrading from the free Microsoft Copilot to the full-feature and more expensive Microsoft 365 Copilot.

Word Action Button for Microsoft 365 Copilot Chat

After Outlook, Word is easily the Office app where I spend most time. The announcement in message center notification MC1143298 (last updated 17 September 2025) that an Open in Word action button will soon be available to move text from Copilot to Word is therefore very interesting.

It’s possible to move content from Copilot to Word now using Copilot pages as an interim step. Copilot pages are built from Loop, so the intention is that the content is worked on in Loop after coming from Copilot rather than being exported to a new app. At this point, Word is a more sophisticated word processing tool than Loop is. Given the use cases for the two apps, this is the natural state of affairs. I seldom need to collaborate with others to write articles or book text. Being able to move content from Copilot to Word is an action I shall check out once it becomes available later this month.

Teams Move to the Unified Microsoft 365 Apps Domain

Before closing for the weekend, a little bird tells me that Teams might soon move from its teams.microsoft.com domain to teams.cloud.microsoft as part of the initiative launched by Microsoft to create a unified domain for Microsoft 365 apps.

In March 2024, Microsoft posted a note for developers to tell them that Teams apps needed to be able to use teams.cloud.microsoft. By this point, I’m sure that most ISVs will have updated their apps, but if your tenant has some custom home-grown Teams apps, it’s worthwhile checking with the developers that the apps are ready to accommodate the domain switch. Who wants to be surprised when the switch happens?

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!

Home-Brewed PowerShell or Microsoft Solutions for Guest Account Management

A recent podcast from the genial Merill Fernando featured Microsoft’s Jeremy Conley to talk about “how to really govern guest access.” The tagline “many tenants have 2-4x more guests than employees” captures the focus of the episode (a good listen) and while many organizations might not believe that guest accounts are quite so numerous in their Microsoft 365 tenants, the simple fact is that it’s all too easy to accumulate a vast collection of guests.

Microsoft 365 is responsible for this sad state of affairs. I started talking about the problems of guest accounts “going bad” (aging) soon after the introduction of Azure AD guest accounts for Office 365 groups in 2016 and the situation hasn’t improved much since. Things really took off with the introduction of Teams in 2017 and later, the adoption of guest accounts by SharePoint Online as the basis for sharing. My basic recommendation has always been to review guest accounts annually with the aim of removing unused guests.

Use Entra ID Governance or PowerShell for Guest Account Management

Microsoft has solutions to help, but only if organizations invest in Entra P2 licenses (naturally) to liberate ID governance features like lifecycle management and access reviews. If you can afford the licenses, you should certainly investigate using lifecycle management and access reviews to control guest accounts. But you don’t need to spend any money on additional licenses because controlling guest accounts is a reasonably straightforward task using PowerShell. Let’s discuss some of the tactics that tenants could adopt for guest management.

First, Microsoft doesn’t implement an expiration date for guest accounts, but this is easily done by assigning an expiration date to guest accounts and using that date as the basis for checking if guest accounts are still needed.

For any type of guest account management, it’s a good idea to review guest sign-in activity. If a guest account doesn’t sign into a tenant within a certain period (say, 90 days), it’s probably obsolete and can be removed.

Entra ID supports the concepts of account sponsorship. In other words, one or more sponsor accounts can be associated with member or guest accounts. Sponsors are not assigned by default, but setting a default sponsor is easily done for guest accounts. The problem with default sponsors is that the selected account might not have any insight into how a guest account is used, but a default sponsor is better than none, and the lack of activity should always be the primary reason for considering an account to be inactive and a candidate for removal.

Sponsors are supposed to know why an account exists, so if a guest account is deemed obsolete due to lack of sign-in activity, you can report this fact and use the report data to contact the sponsors to ask if accounts should be removed or kept.

The Need to Nag Sponsors

One thing I haven’t done yet is to send nagging email to account sponsors to say that their sponsored guest accounts will be automatically removed in a week or so if they don’t reply with a justification for keeping the accounts. This is a good example of where a scheduled Azure Automation runbook is a good choice to run the code to check for obsolete guest accounts and email the account sponsors. I must write that script!

No one wants to remove guest accounts that are required for business purposes. Teams is probably the best example of where important guest accounts that appear underused might exist. I’ve documented five practical actions to manage guest accounts used with Teams topic in this article. Enforcing multifactor authentication for guest accounts through a conditional access policy is a critical step.

Act to Make Sure Your Tenant Implements Guest Account Management

Whether you decide to manage guest accounts using your own code or with Microsoft’s solutions really doesn’t matter. The important thing is to manage guest accounts, especially in terms of a regular clean-out of obsolete accounts. Insisting on multifactor authentication removes most of any security risk associated with having some underused guest accounts in Entra ID, but who doesn’t like a clean directory?

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.

Should Microsoft 365 Tenants Disable Keep Me Signed In?

When I wrote about the Entra ID Keep Me Signed In (KMSI) feature in February 2022, I concluded that growing threats might have made the feature less valuable than it once was. Like anything to do with Microsoft 365, the passing of time requires re-evaluation of attitudes and opinions, and this is true for KMSI too. Here’s my best attempt at summarizing the current state of the art.

Recapping How the Keep Me Signed In Feature Works

As a recap, KMSI is the option presented to users after they authenticate to “stay signed in” to reduce the number of times Entra ID forces the user to sign in. If the user chooses to stay signed in by choosing the Yes option (Figure 1), Entra ID creates a persistent authentication cookie that can last for up to 90 days (as opposed to 24 hours, which is the lifetime of a non-persistent cookie). With a persistent autentication cookie available, the user can connect to applications without signing in for the lifetime of the cookie. Because the cookie is persistent, it doesn’t matter if the browser session is restarted.

The Don’t show this again checkbox has nothing to do with the creation of the persistent authentication cookie. The checkbox controls whether Entra displays the prompt on the device for future sign-ins.

Obviously, a persistent authentication cookie is a bad idea if workstations are shared, but when workstations are personal and only used by a single person, keep me signed in is a nice way to reduce the friction of signing in. In fact, the Entra ID sign-in flow contains some logic to detect if a sign-in originates from a shared device and won’t show the stay signed in screen in this case. The same is true if Entra ID considers a sign-on to be high risk.

Clearing browser cookies on a workstation will remove the persistent authentication cookie.

Conditional Policies and Sign-in Frequency

Conditional access policies can interfere with the operation of persistent authentication cookies. If a conditional access policy insists that users reauthenticate based on a certain frequency, the full authentication process is invoked, and users must provide credentials. Some tenants impose unreasonable demands on users (or just guest accounts) and insist on very frequent authentication, so it’s a matter of achieving balance between annoying users and maintaining the desired level of security.

Considering the Question of Enabling Keep Me Signed In

All of which brings me back to the question of whether Microsoft 365 tenants should enable or disable KMSI. Generally speaking, I don’t see anything wrong with KMSI when the following conditions are true:

• People use personal rather than shared workstations. Authentication processing for people who use shared workstations can be controlled by specific conditional access policies.
• Strong multi-factor authentication is in place to ensure that the initial authentication is secure and is unlikely to be compromised by external attackers. In other words, use the Microsoft authenticator app or passkeys.
• Conditional access policies are in place to impose a reasonable sign-in frequency. Monthly seems about right. After using a weekly frequency for the last few years (for one tenant that I access frequently as a guest), I think this interval creates too much friction.

As always, the first order of business is to prevent user accounts being compromised. If an account is not compromised, KMSI is unlikely to cause a problem. The widespread adoption of continuous access evaluation by Microsoft 365 workloads makes closing off compromised account access easier, but that’s no excuse to avoid deploying strong multifactor authentication everywhere to protect every Microsoft 365 account.

Configuring Keep Me Signed In

To configure KMSI for everyone in a tenant, use the checkbox in User settings in the Entra admin center (Figure 2). KMSI is either enabled or disabled. It can’t be enabled for a specific group of users and disabled for everyone else.

KMSI is Fine in the Right Conditions

Microsoft 365 users have enough on their plate to cope with the ongoing and constant change in the apps they use daily. Reducing friction from sign-ins through features like KMSI seems like a good idea, providing it can be done securely and doesn’t compromise the tenant. Deploying strong multifactor authentication and effective conditional access policies go a long way to establishing the right conditions for KMSI. But if your tenant is open to compromise because it still uses single factor authentication (passwords) or lets people use weak multifactor authentication methods, don’t blame KMSI when you are compromised. At that point, persistent authentication cookies are the least of your worries.

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.

SharePoint Skills in Copilot Won’t Impress SharePoint Administrators

Message Center notification MC1147976 (4 September 2025, Microsoft 365 roadmap item 501427) apparently heralds a new era of AI-enhanced administrative assistance for Microsoft 365 workloads. The post describes two skills to assist administrators to perform tasks in the SharePoint Admin Center:

• Step-by-step task guidance: Copilot provides clear instructions to help administrators complete common tasks.
• Multi-variable site search: Copilot enables administrators to search for sites using multiple conditions, such as inactivity, external sharing, and size, and suggests recommended actions.

The change will roll out in general availability worldwide from October 6, 2025. The capability showed up in my targeted release tenant, so I thought that I’d ask Copilot to help me to manage SharePoint Online, especially because of the promise that Copilot will help “both new and experienced admins complete tasks faster.” Alas, the skills exhibited by Copilot didn’t live up to expectations.

SharePoint Skills and the Promise of AI

Largely because of Teams, SharePoint Online administrators have many more sites to manage than in the past. It therefore makes perfect sense to apply artificial intelligence to help administrators detect potential problems that might be lurking or to find sites that need attention.

I started by asking Copilot to find which sites have most files. That seems like a pretty simple question for AI to answer, but it’s not and Copilot couldn’t answer, saying that it was unable to search for that criterion (Figure 1).

Hmmm… Such a response seems at odds with Microsoft’s promise that Copilot will strengthen governance at scale by allowing administrators to “ask complex questions and receive actionable results, making it easier to detect risks and enforce lifecycle policies across large environments.” Knowing which sites store most files seems like a fundamental piece of information from a data lifecycle perspective.

SharePoint Skills Need Data

The root of the problem is likely to be the data available for Copilot to reason over. All the Microsoft 365 admin centers present sets of data relevant to a workload through their UX. The Exchange admin center deals with mailboxes and other mail-enabled objects; the Entra admin center deals with directory objects; the Teams admin center deals with Teams policies and other team-related information, and so on. The information in these data sets is whatever’s accessible through and presented by the admin centers.

In the case of my question, the SharePoint Online admin center doesn’t have the data to respond because there’s nowhere in its UX that surfaces the file count for sites. In fact, although the SharePoint admin center reports the total number of files in the tenant, finding the file count for a site takes some effort unless you use the slightly outdated information that’s available through the site usage Graph API.

On the other hand, when I asked Copilot to “Find sites without a sensitivity label that have more than 1GB of storage,” the AI could respond because the storage used by each site is available in the SharePoint admin center (Figure 2).

Delivering the Promise

Tenant administrators have a lot to do, so any tool that can help is welcome. This is a first-run implementation, so it’s bound to have flaws. Copilot can offer limited help that novice administrators might welcome while not offering much to anyone with some experience. Microsoft is likely to iterate its Copilot assistance for SharePoint administrators to improve, deepen, and enhance what Copilot can offer, but I fear it will take several attempts before the promise of AI is delivered.

What SharePoint Skills Would Help Administrators?

This raises the question of what kind of assistance Microsoft 365 administrators might want AI tools incorporated into the admin centers to deliver? To me, the answer lies in bringing information together from available sources to answer questions faster than a human being can.

For example, SharePoint advanced management includes a change history report. It would be nice if an administrator could ask Copilot to review all changes made to SharePoint over the last month to report changes like sensitivity label updates for any site that generate label mismatches for documents. The information is available in audit logs and SharePoint document libraries, but it takes effort to bring everything together in a concise and understandable format. AI should be capable of answering questions like this instead of simple queries against site properties, which is all that Copilot can do today, and that is hardly a great example of AI in action.

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.

Default Changes to Copilot Enabled Without Transcription

First issued on August 22, 2025, and updated on September 5 to clarify the timeline, message center notification MC1139493 (Microsoft 365 roadmap item 478611) flags an important change in how Microsoft 365 Copilot functions in Teams meetings. Ever since the introduction of Copilot, the way things worked is that transcription is enabled when Copilot is used in meetings. After Microsoft rolls out the change starting in early November 2025, using Copilot in Teams meetings will no longer enable and save transcripts. This change might be disruptive if meeting organizers expect transcripts to be available after meetings conclude, but as always, the devil is in the detail and this change might not affect your tenant.

The change isn’t surprising given that Copilot can answer meeting participant queries without a transcript (this wasn’t originally the case) and that Microsoft has gradually tightened access control to the meeting transcript over time.

Why Change the Generation of Meeting Transcripts

Microsoft isn’t saying why Copilot-enabled Teams meetings will no longer generate a transcript, but it’s probably to safeguard against the possibility that Copilot will regurgitate meeting discussions in its response to user prompts.

Meeting transcripts are stored in the meeting organizer’s OneDrive for Business account and are indexed by Microsoft Search. Because their content is indexed, transcripts are available for Copilot to process just like any other document that isn’t blocked by the DLP policy for Microsoft 365 Copilot. Meeting organizers with Teams Premium licenses can apply a sensitivity label to files shared during a meeting, but the sensitivity label doesn’t apply to the transcript.

Will The Change Affect My Tenant

The simple answer is yes, if your tenant uses the default Teams meeting policy. That’s because Microsoft manages the settings of default Teams policies and can adjust policy settings as needed.

In this instance, Microsoft will change the value of the Copilot setting in the Teams meeting policy from EnabledWithTranscript to Enabled. The first value is in place today and it’s what instructs Teams to generate the transcript with Copilot. The second value allows Copilot to be used in Teams meetings without the generation of a transcript. If you check the documentation for the Set-CsTeamsMeetingPolicy cmdlet, you’ll see that Microsoft refers to a “persisted” and “non-persisted” transcript. A persisted transcript is one that’s saved to OneDrive for Business; a non-persisted transcript is one that Teams generates internally to allow Copilot to reference what people have said during the meeting before deleting all trace of the transcript when the meeting finishes.

New Microsoft 365 tenants will automatically pick up the Teams meeting policy default settings. Existing Microsoft 365 tenants will use the default settings for new meetings.

An exception exists where custom meeting policies are in use. It’s relatively common to customize Teams policies and the meeting policy is often changed to meet organizational needs. When a tenant customizes a default policy, Teams copies the default policy to create a custom copy for the tenant. The tenant controls the settings of custom policies and Microsoft therefore cannot change the default setting for Copilot. In other words, everything happens as before and enabling Copilot for a meeting will generate and save a transcript.

If Microsoft updates meeting policies for a tenant, it’s easy to revert the change to ensure that transcription occurs with Copilot. The change must be made with PowerShell by running the Connect-MicrosoftTeams cmdlet to connect to Teams PowerShell. Then, run this code to find which meeting policies have Copilot enabled without a transcript:

Get-CsTeamsMeetingPolicy | Where-Object {$_.Copilot -eq "Enabled"} | Format-Table Identity 

To update a policy and restore Copilot with transcription, note the policy name and update it like this:

Set-CsTeamsMeetingPolicy -Identity "RestrictedFunctionality"-Copilot "EnabledWithTranscript" -AllowTranscription $true

Copilot Transcription for Individual Meetings

Even if Microsoft updates the default Teams meeting policy, meeting organizers can opt for transcription through meeting options either when scheduling (Figure 1) or during the meeting.

Persistent Conversations in Meetings

In MC1139493, Microsoft also make the point that conversation history has been made persistent within meetings. In other words, participants can switch between different elements of a meeting like chat or viewing the participant list without losing access to Copilot insights, even without a transcript being taken. The point is that when transcription is not enabled, persistence is possible using the internal transcript, which is how it should be.

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.

Why Would You Need to Run Teams PowerShell Cmdlets in an Azure Automation Runbook

The new permissions requirement for Entra ID apps that want to use cmdlets from the Teams PowerShell module creates the question of what conditions could occur to make apps need to use the Teams cmdlets. After all, access to Teams structures and data is available through Graph APIs and the Microsoft Graph PowerShell SDK. The answer lies in the history of the policy-drive management framework used by Teams.

When Microsoft launched Teams in 2017, they borrowed from many existing technologies. Teams took its approach to management from Skype for Business Online and adapted many of the policies used by Skype for Business to control how meetings, messaging, and other aspects of the system worked. This decision made a lot of sense as it became clear that Teams would replace Skype for Business Online, a decision first revealed in September 2017 and eventually completed in July, 2021.

The Teams PowerShell module appeared in late 2017. I didn’t like the module very much at the time, but have become accustomed to it over time as Microsoft removed the rough edges. One such irritation was the Skype for Business connector, the component used to allow PowerShell control over Teams management policies. In February 2021, Microsoft retired the Skype for Business connector and moved its cmdlets into the Teams module. The legacy of the Skype connector cmdlets still exists today with cmdlets like Get-CsOnlineUser and Get-CsTeamsMeetingPolicy.

In general, any cmdlet with a “Team” prefix (like Get-TeamChannel) is Graph-based and an equivalent cmdlet is in the Microsoft Graph PowerShell SDK (Get-MgTeamChannel in this instance). Any cmdlet with a “Cs” prefix (like Get-CsTeamsMessagingPolicy) uses the old Skype for Business framework and doesn’t have a Graph SDK equivalent. It’s therefore a reasonable conclusion that Entra ID apps need to use the Teams PowerShell module only when apps need to interact with Teams policies. The Graph handles Entra ID app access to teams, channels, chats, meetings, and so on.

Running Teams PowerShell in Azure Automation

Running PowerShell in Azure Automation runbooks is like running PowerShell through Entra ID apps. Both need to be authentication before cmdlets run, and both need some permissions to access data. Permissions can be granted explicitly or via membership of a management role.

Unless the need exists to do widespread and extensive policy reassignment to accounts, I’m not sure that many runbooks use Teams PowerShell. The exception might be where a tenant develops a script based on Teams PowerShell and wants to run the script on a scheduled basis, or the script takes so long to run that interactive execution becomes a pain. In these cases, Azure Automation is a good answer, especially because the Connect-MicrosoftTeams cmdlet supports managed identities for authentication.

The caveat is that some of the cmdlets in the Teams PowerShell module are unsupported when application-based authentication is used. New-Team is the most notable cmdlet in this category, but that gap is easily worked around by creating a new team through Microsoft Graph PowerShell SDK cmdlets.

Configuring Azure Automation for Teams PowerShell

Temas uses much of the setup used to run other Microsoft 365 PowerShell modules with Azure Automation. An automation account must be available that’s connected to an Azure subscription. Ideally, the automation account should support managed identities. The module must be loaded as a resource into the runtime environment. Teams PowerShell supports the PowerShell V7.4 runtime engine, so a custom runtime environment can be used.

Before attempting to authenticate, the service principal for the automation account must be assigned:

• The Teams administrator role. This is what allows the automation account to run the cmdlets in the module as a Teams administrator. The role can be assigned with PowerShell or via the Entra admin center (Figure 1).
• Any Graph API application permissions needed to access the Teams data processed by runbooks. For instance, because Teams management might be gated by administrative units, the RoleManagement.Read.Directory and GroupMember.Read.All permissions are needed to read details about administrative units and the members of those units. Other Graph permissions like Chat.Read.All might be needed to read information stored in teams.

With these preprequisites in place, you should be able to create and execute runbooks using the Teams PowerShell module. Figure 2 shows the output from a very simple runbook that connects to Teams with a managed identity before listing the teams in a tenant.

Not the Normal Option

My normal course of action is to use the Microsoft Graph PowerShell SDK or Graph API requests to interact with Teams (like reporting details about Teams online meetings or analyzing chat messages with external users to figure out an allow list for external access) and I seldom use the Teams PowerShell module with Azure Automation. However, the option is there if needed, and that’s good to know.

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.

Use the SharePoint Site Content Report to Highlight Issues – If You Can Find Any

As quickly as they can and in as many ways as possible, Microsoft is attempting to address the problem of digital rot in SharePoint Online. Having old, obsolete, inaccurate, and just plain wrong information in SharePoint Online and OneDrive for Business doesn’t matter so much until the eagle eye of AI tools are deployed. At that point, all manner of misleading responses can appear because the AI is grounded on misleading or incorrect information.

To some extent, customers cannot be blamed for the digital debris that they accrue in SharePoint Online. For years, Microsoft has encouraged cloud storage (the latest tactic is a policy setting to block users from saving to non-cloud locations), so it’s natural that some rot accumulates along with valuable material. As I’ve said before, many of the problems customers have encountered with Microsoft 365 Copilot deployments are the legacy of previous Microsoft collaboration strategies. Not everyone goes through the process of auditing the files stored in SharePoint Online to remove dross (here’s how to create a report of files in a document library, and here’s how to do the same for a OneDrive for Business account).

The Site Content and Policy Comparison Report

All of which brings me to the “SharePoint AI-powered site content and policy comparison report” announced in MC1143287 (27 August 2025). The report is available to tenants with Microsoft 365 Copilot or SharePoint Advanced Management (SAM) licenses. It’s one of the SAM features made available to Copilot customers without the need for SAM licenses. The site content and policy comparison report is rolling out in general availability now with completion worldwide due in late December 2025.

According to Microsoft, the idea is that a tenant selects a reference site that they regard as a good example of a site with “up-to-date and relevant policies” to use as a benchmark to compare up to 10,000 other sites against (Figure 1). In addition to policies that apply to the site (like data lifecycle policies), the reference site should contain more than 10 files of the same kind of material that’s found in the target sites. This is because the comparison uses the 10 most recently used files from each site.

The report uses AI to examine the target sites. The target sites can be chosen by uploading a CSV containing their URLs or selected using several site properties, ranging from the simplest (examine everything as shown in Figure 2) to identifying sites based on the container management sensitivity label assigned to sites, the site type, creation date (for example, sites created within the last 30 days), sites with no owners, and sites where external sharing is disabled.

Nothing in My Reports

Behind the scenes, AI compares the target sites against the reference site to highlight inconsistent application of policies based on the similarity between the reference site and target sites (here’s the documentation). After pondering on any anomalies that it finds (a process that Microsoft warns could take up to 48 hours), the AI generates a report for administrators to consider and potentially act upon.

And that’s where my story ends because despite multiple attempts to select a good reference site to compare against the other sites in my tenant, the AI always came up with an empty report. I even purposely populated a site with content that I knew is similar to other sites and edited ten of the files added to the site to make sure that fresh material was available for the comparison. The site had the same sensitivity label and settings as the reference site, but the report still ignored it.

Maybe my SharePoint Deployment Has No Problems

I could take a positive view and conclude that the AI discovered no irregularities. For instance, all my team sites have container management labels and have assigned retention policies. It could also be the case that the selected reference sites are very dissimilar to the other sites in the organization, so much so that none of the other sites came close enough to be of interest.

However, I suspect that the AI comparison just doesn’t work well for tenants where many similar sites exist but only a few of those sites are actively used. I also wonder why Microsoft insists on comparing the last ten most recently used files because if the intention is to help organizations prepare for Copilot, then perhaps sites that hold many files without having sufficient recently modified files should be highlighted? After all, in the eyes of AI tools, a file is a file, and the information contained in a file that hasn’t been modified in years could end up being cited in a Copilot response. Using old material often leads to poor responses.

Don’t assume that just because it didn’t work for me, the site content and policy comparison report is rubbish. It might work well in your tenant and highlight many areas that you should investigate to improve the tenant readiness for AI.

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.

Build Out of a Complete Person Platform within Microsoft 365

After publishing the article about customizing the Microsoft 365 profile card through the Microsoft 365 admin center, I started to think about the work Microsoft is doing on the “people platform,” an effort to unify the different strands of people-related data that exist inside Microsoft 365, such as Entra ID, mailbox properties, skills defined for SharePoint Online users (now the people skills solution), people settings like name pronunciation and personal pronouns, and so on. Drawing together disparate sources of information to create a unified view of a person (tenant user, guest, or contact) seems like a good idea, especially if AI tools like Copilot use people information to enhance responses to user prompts.

Exploiting the Graph to Discover More About the People Platform

I’ve often argued that acquiring a knowledge of how the Microsoft Graph works and how to interact with Graph APIs is a good way to gain an insight into how Microsoft 365 works. In this case, the profile resource type is very revealing. A lot of the work in this area is still in beta and is therefore prone to change, but you can see where Microsoft is heading in the description of the Microsoft 365 person experience (described for a multi-geo tenant, but still valid):

“The Microsoft 365 Person encompasses the complete set of properties, attributes and associated people contacts that are representative of a user in the Microsoft 365 tenant.”

The sources used to build the complete picture of a person include:

• Basic administrative information about people stored in Entra ID, including information synchronized from on-premises Active Directory. This information includes the display name, employee identification number, employee type, physical location, and so on. It also includes the person’s photo.
• Data to build out the one-dimensional picture of a user as found in Entra ID by populating information about the person’s jobs (work positions or roles), skills, languages, education (including certifications), and so on. This information can be added programmatically through the Graph APIs or imported from an external system using a Copilot connector for people data.

Adding a Work Position

To demonstrate what kind of information the people platform uses to build out a complete picture about a user, I spent a little time playing with the Microsoft Graph PowerShell SDK cmdlets that add work position information to the people platform. A work position is a job or role undertaken by a person within a business. The role might be in the past or current, so a complete work history within an organization can be constructed from the work position data. Like the rest of the platform, these cmdlets are based on beta code, so some stuff doesn’t work. Nevertheless, the information defined for a work position is a good example of what Microsoft is doing.

This code adds a new work position, marking the role as current (isCurrent is true). The allowedAudiences property is set to organization, meaning that the information is available within the organization (it could also be set to “me,” meaning that it’s personal to the user). After building the properties to describe the role, running the New-MgBetaUserProfilePosition cmdlet adds the work position record to the people platform. This is equivalent to posting a request to the https://graph.microsoft.com/beta/users/{userId}/profile/positions endpoint.

$AddDate = ([datetime]::UtcNow.ToString("s")) + "Z"

[string]$AddDate = '2025-09-04T22:18:03.8608268Z'
[string]$endDate = '2039-09-04T22:18:03.8608268Z'

$Parameters = @{}

$RoleDetail = @{}

$RoleDetail.Add("jobTitle", "Senior Technical Manager")
$RoleDetail.Add("role", "Technology Consulting")
$RoleDetail.Add("employeeId", "150847")
$RoleDetail.Add("employeeType", "Permanent")
$RoleDetail.Add("description", "Responsible for the management of a small team of technical consultants covering the NYC area")
$RoleDetail.Add("level", "MGR-02")
$RoleDetail.Add("startMonthYear",$AddDate)
$RoleDetail.Add("endMonthYear", $EndDate)

$Company = @{}

$Company.Add("displayName", "Office 365 for IT Pros")
$Company.Add("department", "Consulting")
$Company.Add("officeLocation", "New York City")
$Company.Add("costCenter", "100014")
$Company.Add("division", "Professional Services")
$Company.Add("webUrl", "https://office365itpros.com/")

$Address = @{}
$Address.add("type", "business")
$Address.add("street", "170 Avenue of the Americas")
$Address.add("city", "New York City, New York")
$Address.add("countryOrRegion", "United States")
$Address.add("postalCode", "10036")

$Company.Add("address", $address)

$RoleDetail.Add("company", $Company)
$Parameters.Add("detail", $RoleDetail)
$Parameters.Add("isCurrent", "true")
$Parameters.Add("allowedAudiences","organization")
$Parameters.Add("createdBy", "Tony Redmond")

New-MgBetaUserProfilePosition -UserId $User.Id -BodyParameter $Parameters

After positions are added, the Get-MgBetaUserProfilePosition cmdlet can retrieve an array of all the work positions known for the user:

[array]$Positions = Get-MgBetaUserProfilePosition -UserId $User.Id

The information written by New-MgBetaUserProfilePosition is available in several composite properties, like Detail (Figure 1). It’s easy to see how this information might surface on a form of the current profile card.

You’ll always find a position registered for a user because the people platform synchronizes details from Entra ID to create a default position from information like a user’s job title held in the directory.

A Complex Undertaking

It’s obvious that building the people platform is a complex undertaking. Anything to do with personal information is sensitive. Personal privacy must be protected. I am sure that employee unions and worker councils will take a keen interest in how Microsoft 365 tenants decide to populate the Graph with people information and then, more importantly, how that data surfaces in places like the Microsoft 365 profile card.

It’s often said that we live in interesting times. Things might just get more interesting as the people platform develops. It’s certainly something that anyone involved in identities and user management should keep an eye on.

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

New Policy Setting to Force Office to Save to Cloud Locations

Announced in Microsoft 365 message notification MC1137593 on 18 August 2025, Microsoft is introducing a new policy setting to force the creation (saving) of Office files in cloud locations. The setting only applies to Word, Excel, and PowerPoint files saved using the Microsoft 365 enterprise apps (subscription version of Office). No other Office version is affected.

Cloud locations means SharePoint Online, OneDrive for Business, and third-party cloud storage services like Dropbox or ShareFile (if the feature is enabled for the Microsoft 365 tenant).

The new policy enablecloudonlysaveasmode setting can be deployed to clients using Group policies or registry updates. The setting is available in the Administrative Template files for Microsoft Office (version 5516.1000 or newer) and applies to the Windows versions of the Microsoft 365 enterprise apps version 2506 (build 19029.2000) or later. I checked the feature using version 2508 (build 19127.20192) (Current Channel Preview).

MC1137593 says that public preview started to roll out in late August 2025 and is scheduled to complete by mid-September 2025. General availability for all clouds will start in mid-September 2025 and should be available everywhere by the end of September 2025. If you don’t take steps to apply the policy setting, nothing changes.

Higher Cloud Usage

Microsoft says that the new policy is “part of a new set of tools for IT Administrators to move their organizations towards higher Cloud usage and Increase security and compliance.” Increasing cloud usage adds stickiness to the Microsoft cloud because the more data that users store in SharePoint Online and OneDrive for Business, the harder it is to move to any other platform.

The point about increasing security and compliance is justified by the fact that SharePoint Online and OneDrive for Business are subject to the tenant’s security and compliance policies. It’s true that cloud files are more resilient than files stored on a local drive and it is very convenient to be able to move from PC to PC while keeping files available. However, everything depends on the network and if the network’s not available or you don’t want to use a potentially insecure network like free wi-fi, losing the ability to save files to the local drive can be a real pain. I often save copies of Offices files as PDFs to share with other people, and I don’t really want those PDFs cluttering up OneDrive.

Microsoft sometimes goes overboard in its enthusiasm to save files in OneDrive, like PowerShell modules. Some might consider this step to be in that category.

What Users See

The default situation is shown in Figure 1. No policy is configured, and the user can save to SharePoint Online, OneDrive for Business, the local hard drive, and other cloud services (configured through Add a Place).

With the policy setting enabled, Office applications are limited to cloud locations to save new files or save existing files as a new file (Figure 2). Note that the “This PC” and “Browse” (for folder) options are missing.

Updating Office with the Microsoft 365 Apps Policy

Microsoft 365 tenants can apply the setting to restrict saving to the cloud via a cloud policy configured in the Microsoft 365 Apps center. Search for the Restrict saving on non-cloud locations setting and change the value from not configured to enabled (Figure 3).

After saving the policy, its settings are applied by the click to run service and the new setting should be active within a day.

Like most Office settings, the change can be made manually by updating the system registry on a PC. In this case, it seems like the setting is controlled by two settings. The first enables the cloud only save mode by creating a new DWORD value called EnableCloudOnlySaveAsMode at HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\FileIO. The second apparently removes the UI options for non-cloud locations through another DWORD value called PreferCloudSaveLocations at HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\General. Both values are set to 1 to enable or 0 to disable. When I tested, the settings worked on one PC and not on another. It took too long to figure out that the PC where things worked ran Current Channel (Preview) while the one where the feature didn’t work ran Current Channel.

A Change That Might Annoy Some

Some will hate this change and ask what’s the point of having a local drive if it’s inaccessible. Others might not notice that all files are stored in the cloud because they do that as the norm. And some will only notice the change when they go to save a file locally. I save most of what I do with Word, Excel, and PowerPoint in the cloud, so I guess that I’m in the last category.

If I was forced to live with storing all Office files in the cloud, I could adapt my workflow without much difficulty. Until a network outage occurs…

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!

Hard to Find Logic for Copilot License Check in Exchange Connectivity Tool

Unless you’re a keen reader of the Microsoft blogs posted to the Microsoft Technical community, you might have missed the August 25 article about a new diagnostic tool for a “Copilot License Details Check.” According to the text, it’s “a powerful tool designed to streamline and validate your license readiness by confirming whether Copilot for Microsoft 365 licenses are properly assigned to users.” In reality, it’s some Graph API requests cobbled together to report details of a Microsoft 365 Copilot license assignment to a user account that’s been bolted onto the side of the Exchange Remote Connectivity Analyzer (ExRCA).

As I explain in another article, ExRCA started as a troubleshooting tool to help Exchange on-premises administrators debug connectivity problems with protocols like Autodiscover and ActiveSync (check out the YouTube video from that time). Later, Microsoft upgraded ExRCA to support Exchange Online and Teams. At this point, it’s fair to say that ExRCA is an invaluable tool for Microsoft 365 tenant administrators.

However, having a valuable support tool is no reason to bolt on a license checker. I’m sure Microsoft will point to the inclusion of the message header analyzer tool in ExRCA as evidence that ExRCA has become a toolbox, but that’s missing the point that the message header tool is at least associated with a messaging protocol (SMTP) whereas the Copilot license check is a barefaced attempt to help people use more Copilot features.

Running a Copilot License Check

Running a Copilot license check is very simple. Input the user principal name or primary SMTP address of a user account, sign in as an administrator with permissions to access user account details, and the code runs to verify that the account has a Microsoft 365 Copilot license with all its service plans intact (Figure 1).

A Simple Check

Stripping everything away, the license check is very simple and the results that it generates are equally simple (no expensive CPU cycles for AI analysis are burned here). Figure 2 shows that the user being checked is good to go. I’m sure that this is deemed to be a successful test.

But some issues exist. First, the test doesn’t distinguish between direct-assigned licenses and group-assigned licenses, which is valuable information for an administrator to know if they want to address a problem highlighted by the test. Second, the test only considers a “full” Microsoft 365 Copilot license to be valid. Trial licenses are not considered valid. Third, disabling some Copilot features is a perfectly reasonable thing to do. Not everyone needs to create new agents through Copilot Studio, for example.

PowerShell Code for the Copilot License Check

To show what the ExRCA Copilot check does, I recreated the check using the Microsoft Graph PowerShell SDK. The code is simple and took about an hour to write (including testing):

• Sign into the Graph with Connect-MgGraph using an administrator account.
• Prompt for a user account and validate that the account exists.
• Check that the account has a valid Microsoft 365 Copilot license (including trial licenses). License and service plan information is available online.
• Run the Get-MgUserLicenseDetail cmdlet to retrieve service plan information for the Copilot SKU.
• Check each of the service plans defined in the license to report if it is enabled or disabled.

Figure 3 shows some sample output.

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

No Reason to Use ExRCA to Check License Details

I don’t know how many Microsoft 365 tenant administrators will seek out ExRCA to answer questions like “I wonder if the Copilot license assigned to John Doe is good to go?” It seems like an unnatural reaction to consider ExRCA in that light when it’s straightforward to build your own tools to measure user readiness for Copilot or analyze and report licenses assigned to user accounts (including disabled service plans).

The idea might be a good one, but I fear it’s implemented in the wrong place and is too limited to deliver much value.

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.

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 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.

Customize the Microsoft 365 Profile Card Through the Admin Center

A July 3 LinkedIn post by Microsoft’s Wictor Wilén revealed that the Settings section of the Microsoft 365 admin center now has a People Settings section where tenant administrators and people administrators can customize the properties that appear on the Microsoft 365 people card. Figure 1 shows the properties available for inclusion in the profile card.

No Custom Properties

The thing about the set of properties shown by the Microsoft 365 admin center is that they don’t include any custom properties (the Exchange custom properties referred to by Entra ID as the on-premises extension properties) added to the profile card through the Microsoft Graph. To keep focus, properties ingested from another source, like Copilot connectors for people data, are out of scope for this discussion.

For example, the profile card for my tenant features three custom properties for Employee Id, Employee Type, and Cost Center (see this article about how to customize the Microsoft 365 user profile card with PowerShell). Similar properties are in the list shown in Figure 1, but these are Entra ID properties rather than the custom properties I used.

Two of the properties (EmployeeId and EmployeeType) have been available in Entra ID for several years, but never featured in the set surfaced in the profile card (which is why I used custom attributes)

The CostCenter property is part of the CompanyDetail Graph resource type that’s currently in beta. Looking at the other optional properties listed in Figure 1, we find that the Division property is also part of the CompanyDetail resource, while the Role property is part of the PositionDetail resource, another beta resource.

Because these properties are in beta, you cannot update them for user accounts through the Entra admin center or Microsoft 365 admin center. Instead, you’ll need to use cmdlets like New-MgBetaUserProfilePosition (which updates the Role property), or the Update-MgUser cmdlet to update the CostCenter and Division properties. As shown below, after updating the properties for a user account, the Get-MgUser cmdlet can retrieve the updated values:

$Parameters = @{
  employeeOrgData = @{
   "costCenter" = "881-22993"
   "division" = "CEO Office"
  }
}

Update-MgUser -UserId Tony.Redmond@office365itpros.com -BodyParameter $Parameters

Get-MgUser -Userid Tony.Redmond@office365itpros.com -Property id, displayName, userPrincipalName, employeeOrgData | Select-Object -ExpandProperty employeeOrgData

CostCenter Division
---------- --------
881-22993  CEO Office

Microsoft 365 Profile Card In a State of Transition

The Microsoft 365 profile card is in a state of transition. Some properties come from Entra ID, and some come from SharePoint Online, which can end up in a messy profile card with apparent duplications. Add in some custom properties derived from Exchange custom attributes, and it’s a recipe for confusion.

The good news is that Microsoft is attempting to solve the problem by defining the properties required by Microsoft 365 tenants in Graph resources. If Graph resources include rich descriptions of about people and their roles, then there’ll be no need to use custom properties.

Tenants use custom properties today because it has been the only way to present customized information about people on the profile card. A migration to move values from custom to standard properties will have to occur in the future. For example, my tenant needs to extract values from the custom properties used by the profile card today and transfer the values to the default Graph properties. The transition will be completed by updating the set of properties shown on the user profile card to use the default rather than custom properties. You can download a script from the Office365itpros GitHub repository that demonstrates the general principle.

More Settings for the Microsoft 365 Profile Card to Come

The big expansion of the People Settings section in the Microsoft 365 admin center needs to be filled with more than the single option to customize the people card. I expect that Microsoft will use the page to present all the settings that affect the profile card, including the display of personal pronouns and name pronunciation recordings. It just takes time to roll these changes out, but I wouldn’t be surprised to see the other settings appear in the Microsoft 365 admin center before the end of the year.

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.

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.

Rationalization of Microsoft Graph Developer Tools

On August 29, 2025, Microsoft announced the deprecation of the Microsoft Graph command line interface (CLI) and the Microsoft Graph Toolkit. Full retirement of these components is planned for August 28, 2026. It seems like both decisions are part of an effort to rationalize the portfolio of Microsoft Graph developer tools.

Microsoft suggests that the replacement for the Microsoft Graph CLI is the Microsoft Graph PowerShell SDK. This makes sense to me. Although the Graph PowerShell SDK has its foibles and has experienced some terrible quality problems over recent releases, a new development group recently took over responsibility for the SDK. Hopefully, they will be able to restore the necessary quality and robustness. The most recent release (V2.30) appears to be reasonably stable, including when used with PowerShell V7.4 in a custom Azure Automation runtime environment.

Software Development Bets Often Fail

Development of software tools is a matter of luck. Some take and are wildly successful. Others fail, perhaps slowly, but eventually as interest peters out or users take their interest elsewhere. Microsoft cannot be criticized for implementing different ways to exploit the Graph, but it can be criticized for not seeking consistency and coverage across the Microsoft 365 ecosystem. I’m not unhappy about the deprecation of the Graph CLI or Graph Toolkit. However, it would be nice to see the effort previously expended on these tools devoted to addressing the issues raised in a recent feedback portal request.

The Complaint Against Microsoft

The feedback portal request is simple: inconsistency is rife across Microsoft 365 administrative interfaces. Fourteen years after the launch of Office 365, it’s inconceivable that so many gaps exist in the API coverage for workloads. Microsoft positions the Graph as the great unifying force, but the facts on the ground are that many operations implemented in administrative portals like the Microsoft 365 admin center or the Entra admin center are accomplished using undocumented private APIs.

Tools like the Graph X-Ray and network traces throw some light onto what happens when administrators take actions in portals, but unless an API is documented, developers outside Microsoft take a risk if they attempt to use knowledge gleaned through unofficial sources to automate processes, or even worse, build products to close gaps left by Microsoft in their API coverage.

The complaint is endorsed by many Microsoft MVPs. Its requests are straightforward:

• Surface all administrative portal functionality through the Microsoft Graph. Although I appreciate that it takes time to achieve full production status. It is reasonable to ask for access through a beta endpoint to start.
• Support application permissions for access to data. This request makes eminent sense. There is no good reason for demanding that access tokens have the global administrator role to change a setting.
• Publish a roadmap and timeline when gaps in administrative coverage will be closed. Again, this is reasonable.
• Move endpoints out of beta status in a reasonable timeframe. Many organizations do not trust beta anything. It would be good if Microsoft committed to moving APIs to the V1.0 (production) endpoint in a reasonable time, say within one year after introducing new functionality in a beta version.

You can help by signing into the feedback portal and voting for the proposal. Nothing described above is radical. The requests made in the proposal make perfect sense. I would add the need to ensure consistency across Microsoft 365 for PowerShell modules. It’s unacceptable when major PowerShell modules like Exchange Online and the Microsoft Graph PowerShell SDK clash over assemblies. It’s also unacceptable when modules like the SharePoint management module stay fixed in PowerShell V5.1.

Moving Towards an Ideal Situation

Even in the ever-changing world of the cloud, customers like predictability and reliability. The ideal situation would be to have a release of all Microsoft 365 developer components on a predictable cadence, say every two months. Each release should make progress towards the goal of achieving full coverage of all Microsoft 365 administrative interfaces and include all the major modules (Exchange, SharePoint, Teams, Microsoft Graph PowerShell SDK, Entra ID) in a manner that all modules released on a certain date are guaranteed to work together.

Such an approach is sensible, but it won’t happen because of Microsoft organizational politics. Unless of course sufficient customers protest the current state by upvoting the request in the feedback portal. Two minutes of your time might be enough to help remediate the problem. Is that too much to ask?

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.

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.

Use a Custom Runtime Environment for PowerShell V7.4 with the Microsoft Graph PowerShell SDK

The recent introduction of custom runtime environments for Azure Automation is an important step toward creating a better operational platform. The idea is simple. Microsoft defines a set of system-generated runtime environments and tenants can create their own runtime environments to match their needs.

Until now, Azure Automation has essentially offered just the system-generated runtime environments to cover languages like PowerShell and Python, and tenants have had to deal with whatever limitations existed in those environments. For example, the current version of PowerShell Core is V7.5.2, but Azure Automation only supports V5.1, V7.1, and V7.2. When the Microsoft Graph PowerShell SDK developers decided to remove support for .NET6 in their V2.26.1 release, any runbooks configured to use PowerShell V7.1 or V7.2 promptly broke because of their dependency on .NET6.

At the time, Microsoft’s solution was to advise customers to use PowerShell V5.1 with current versions of the Microsoft Graph PowerShell SDK or to stay with V2.25 of the SDK until Azure Automation delivered support for PowerShell V7.4, which is built on .NET8 and is the long-term support (LTS) version of PowerShell (an important aspect for many customers).

Component of Custom Runtime Environments

Support for PowerShell V7.4 has been available since late June 2025 in the form of a custom runtime environment. I don’t know why PowerShell V7.4 is not in the set of system-generated runtime environments. In any case, it is easy to create a custom runtime environment and execute runbooks created using the latest versions of the Microsoft Graph PowerShell SDK.

Before you can use custom runtime environments, you must select the Try runtime environment “experience” toggle for an automation account (Figure 1). Selecting the toggle exposes the option to access runtime environments under Runbooks in the Process Automation menu section.

A runtime environment is composed of:

• A language (PowerShell in this case, but also Python).
• A runtime version (V7.4).
• Packages (DLLs, Assemblies, and PowerShell modules) required to execute runbooks.

I created a custom runbook environment called PSR74. Figure 2 shows the environment settings and that I have looked four Microsoft Graph PowerShell SDK modules into the environment. In the past, you loaded modules as resources for an automation account. Now, the modules are resources for a specific runtime environment.

You can have as many custom runtime environments (within reason) as you like. It’s conceivable, but not practical, that each runbook would have its own runtime environment. More likely, you’ll end up creating a set of runtime environments to match the kind of work done by runbooks. For instance, I have a runtime environment for Microsoft Graph PowerShell SDK runbooks and another for Exchange Online runbooks.

Moving Runbooks to a Custom Runtime Environment

Existing runbooks are tied to a system-generated runtime environment. For instancem the CheckUtilityAccountSignIns runbook shown in Figure 3 is currently tied to the PowerShell V5.1 environment. To move the runbook, select it from the list and us the Update Runtime Environment option to choose a target runtime environment. You can then opt for any system-generated or custom runtime environment defined for the automation account.

When you move a runbook, remember to check the set of modules loaded into the target environment to ensure that all the components needed by the runbook are present. In this example, because the runbook processes Entra ID sign-in audit records, I had to load the Microsoft.Graph.Identity.SignIns and Microsoft.Graph.Reports modules into the target environment before the runbook executed successfully.

Some limitations exist and you should read the documentation before commiting to the new runtime environment. One noteable problem is that some commonly used modules for Microsoft 365 automation, like the Exchange Online management module, aren’t available for PowerShell V7.4 yet. You can attempt to load these modules into a V7.4 runtime environment, but nothing happens. It might take some time before all your favorite (and required) modules support PowerShell V7.4, so you might have to remain with V5.1 for a while yet. In the meantime, it’s easy to switch between the old and new runtime experience, and to switch runbooks between environments.

Nice Change to Deliver Flexibility

Being able to configure a runtime environment precisely the way that you want is an attractive feature. Some extra overhead is incurred to make sure that all the required modules are present, but that’s a small price to pay for the flexibility delivered by runtime environments.

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.

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.

Update 15 Available for Download

The Office 365 for IT Pros eBook team is happy to announce the availability of the September update for the Automating Microsoft 365 with PowerShell eBook.The ebook is available as part of the Office 365 for IT Pros eBook bundle or as a separate subscription. Those with current subscriptions for either the bundle or separate book can download the updated PDF and EPUB files now.

For those who like printed text, a paperback version is available through Amazon.com print on demand. The version number for the update is 15.1.

Microsoft Graph PowerShell SDK V2.30

Microsoft released V2.30 of the Microsoft Graph PowerShell SDK on August 19. I’ve been using the new version, and it hasn’t thrown up any problems, including running in Azure Automation. In truth, there’s nothing very different in V2.30 apart from some fixed bugs and support for recently released Graph APIs.

Following several disastrous releases, stability and reliability are the two most important attributes the Microsoft Graph PowerShell SDK can exhibit. Engineering responsibility for the SDK has moved to a new group, and the hope is that the new team will deliver a series of high-quality releases. Time will tell.

Microsoft also released V1.0.11 of the Entra PowerShell module on August 22. The Entra module is based on the Microsoft Graph PowerShell SDK but only deals with Entra objects and configurations. I must admit to paying little attention to the Entra module because I prefer working with the full SDK, but I can see how those who are accustomed to working with the old AzureAD module will find the Entra module easier to get up to speed with.

Microsoft Teams V7.31

This month saw Microsoft release V7.30 of the Teams PowerShell module on August 11, 2025 followed ten days later with V7.31. Apparently, a bug was found in education tenants that affected the New-Team cmdlet. Being able to create new teams programmatically is kind of important, so Microsoft rushed out V7.31.

Going back to the Microsoft Graph PowerShell SDK, the New-MgTeam cmdlet is an alternative way to create a new team. Microsoft Graph coverage for Teams includes most administrative operations involving teams, channels, messages, chats, calls, apps, and members. Where Graph coverage exists, there’s a matching Microsoft Graph PowerShell SDK cmdlet. What missing in the Graph is coverage for Teams policies, like meeting policies. Many of these policies came from the old Skype for Business Online connector (absorbed into the Teams PowerShell module in 2021).

While understandable that the initial need was to integrate the old Skype for Business Online policies into the Teams PowerShell module, it’s curious that Microsoft hasn’t progressed to deliver full Graph coverage for all aspects of the Teams ecosystem.

A Bad Decision for Connect-IPPSSession

I cannot understand the logic behind the announcement in MC1131771 (updated 15 August 2025) that the Connect-IPPSSession cmdlet will require the EnableSearchOnlySession parameter to run eDiscovery cmdlets like New-ComplianceSearchAction. Our technical editor, Vasil Michev, published a nice behind-the-scenes analysis of the change on his blog.

The change is due to come into effect on August 31, 2025, and tenants must use V3.9 or later of the Exchange Online management module (released on 12 August 2025). I think the change is required by the changeover to the new eDiscovery framework and the retirement of the older Purview eDiscovery (premium) offering.

The cmdlet documentation says that the switch enables “certain eDiscovery and related cmdlets that connect to other Microsoft 365 services.” Changes like this have a nasty habit of breaking production scripts. I am sure that Microsoft could have done the work to detect when a connection to other services is necessary and do whatever is necessary without imposing the need to change on customers. In other words, make sure that customers see magic and never expose the dirty pipework that makes everything work.

On to TEC 2025

I’m looking forward to speaking about why Azure Automation works great with Microsoft 365 PowerShell at The Experts Conference (TEC) event in Minneapolis (September 30-October 1). TEC is a relatively small event, so great interaction happens between speakers and attendees. Even the heckling is of high quality. The PowerShell script-off competition, where participants are challenged to come up with scripted solutions to real-life questions, is going ahead again and it’s always good fun (the beer consumed by the audience might add to the general air of hilarity).

Fellow Office 365 for IT Pros authors Paul Robichaux and Michel de Rooij will also speak at TEC. If you’d like to attend, here’s a code with a nice discount. Come along and tell us what you like (and don’t) about Office 365 for IT Pros. And if you have a printed copy of Automating Microsoft 365 with PowerShell, we’ll be happy to sign it for you.

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.

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.

Severe Limitations to be Applied to Outbound Email from MOERA Domains

On August 20, 2025, Microsoft announced their latest step to limit misuse of Exchange Online by spammers by limiting the ability of mailboxes with primary SMTP addresses based on a MOERA (Microsoft Online Exchange Routing Address) to send email to external recipients. For years, spammers have created Microsoft 365 tenants and promptly used the tenant to send email. New tenants come with a default sub-domain in the onmicrosoft.com domain, like spamforus.onmicrosoft.com (a MOERA domain).

New mailboxes created in the domain receive primary SMTP addresses based on the MOERA domain, like John.Smith@spamforus.onmicrosoft.com. All of this is deliberate and intended to allow new tenants to be able to send email. However, spammers take advantage of Microsoft’s email routing infrastructure to share their content with anyone they can reach. The consequence is that onmicrosoft.com domains have poor reputations, so much so that many tenants block all email from onmicrosoft.com domains to reduce the amount of spam that reaches user mailboxes.

Microsoft has acted elsewhere in Microsoft 365 to limit the communication horizon for trial tenants by blocking federated Teams chat. Receiving an unwanted chat from some unknown external sender is the rough equivalent of receiving email spam. It’s a distraction and interrupts real work, so actions to limit unwanted communications is always welcome.

In this case, Microsoft will introduce a new throttling restriction to limit tenants that use MOERA domains to 100 external recipients per 24-hour rolling window. That’s very restrictive because the limit applies to email sent across an entire organization. Once the threshold is reached, the Exchange transport system refuses to accept more outgoing email and responds to the sender with a non-delivery notification with a 550 5.7.236 code.

Throttling Starts in October 2025

As is normal when Microsoft introduces a new email send threshold for Exchange Online, the new limit will roll out from October 15, 2025, starting with trial tenants and slowly progressing through small and medium tenants until the final step on June 1, 2026, when the limit applies to tenants with more than 10,000 accounts with paid Exchange licenses (“paid seats”).

The solution to avoid throttling is to acquire a regular domain and add it as an accepted domain for Exchange Online in the Microsoft 365 admin center (Figure 1). Sometimes these domains are referred to as “vanity” domains because they become part of an organization’s branding strategy, much like we use the office365itpros.com for email and this site.

I can’t imagine running a Microsoft 365 tenant with more than 10,000 accounts that doesn’t use a regular domain. It’s not as if acquiring a domain is expensive. Many cost less than $50/year from a domain registrar like Godaddy.com or WordPress.com.

Finding MOERA Senders

Microsoft recommends using the message trace facility to find e mail sent using a tenant’s MOERA domain. That’s certainly one way to approach the problem, but it won’t reveal all the problem mailboxes. A better idea is to use the Get-ExoMailbox cmdlet to search for mailboxes whose primary SMTP address uses the MOERA domain. This code shows how to look for user, shared, and group mailboxes that need to have their primary SMTP address updated to a regular domain. The code excludes mailboxes created for accounts in other tenants in a multi-tenant organization.

Get-EXOMailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox, SharedMailbox, GroupMailbox | Where-Object {$_.PrimarySmtpAddress -like "*.onmicrosoft.com*" -and $_.PrimarySMTPAddress -notLike "*#EXT*"} | Sort-Object DisplayName | Format-Table DisplayName, PrimarySmtpAddress, RecipientTypeDetails -AutoSize

DisplayName               PrimarySmtpAddress                         RecipientTypeDetails
-----------               ------------------                          --------------------
"Popeye" Doyle            Popeye.Doyle@o365maestros.onmicrosoft.com   UserMailbox
Adele Vance               AdeleV@o365maestros.onmicrosoft.com         UserMailbox
Alain Charnier            Alain.Charnier@o365maestros.onmicrosoft.com UserMailbox
Break Glass               Break.Glass@o365maestros.onmicrosoft.com    UserMailbox
Buddy Russo               Buddy.Russo@o365maestros.onmicrosoft.com    UserMailbox

Later, the code can be used to find the affected mailboxes before updating their primary SMTP address with a new address belonging to the regular domain. For example, if the new domain is Beachdums.com, the command to update a mailbox is something like this:

Set-Mailbox -Identity Buddy.Russo@o365maestros.onmicrosoft.com -WindowsEmailAddress Buddy.Russo@beachdums.com

To ensure that messages addressed to the previous address can be delivered, Exchange Online keeps the address in the EmailAddresses property of the mailbox.

The Microsoft article contains other points that need to be attended to after switching domains. None of these are difficult tasks, but detail is important.

Good Change

The battle against spam is longstanding and permanent. Microsoft is closing as many holes as possible to make Exchange Online a poor host for spammers to target. Closing off the MOERA hole is a good step forward that shouldn’t cause too much pain for legitimate tenants. That is, if you don’t use MOERA domain addresses for outbound email.

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.

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.

New Summary Methods for Entra ID Authentication Methods

Three new Entra ID Graph resources are available in the authentication methods usage reports API to help track adoption of authentication methods, especially the progress towards usage of strong authentication methods for multifactor authentication. It’s easy enough to create a report detailing the authentication methods in use with PowerShell. These resources deliver summary information in a very accessible manner, providing that you have the necessary Entra P1 or P2 licenses needed to access report data via the Graph.

Microsoft doesn’t add to the Graph without good reason. In this case, it’s likely that these resources and methods will be used for reporting in the Entra admin center. Microsoft Graph PowerShell SDK cmdlets aren’t available for the APIs yet, so the examples below use the Invoke-MgGraphRequest cmdlet to run requests. Like all Entra ID sign-in data, information is available for the last 30 days. To run the requests, the Graph SDK session needs the AuditLog.Read.All permission and the signed-in user must hold one of the roles specified in the documentation like Reports Reader or Security Administrator.

User Events Summary

The userEventsSummary resource provides a list of events associated with user activities to register an authentication method or reset using SSPR. The method supports several different filters to allow events to be found based on user principal name, display name, success or failure, and authentication method. Here’s an example which looks for every matching event that’s available. Only one event is available in my tenant, where a user set up SMS as a secondary authentication method. This isn’t a strong authentication method and the user deserves to be nagged to use a stronger method, like the Microsoft authenticator app.

$Uri = 'https://graph.microsoft.com/beta/reports/authenticationMethods/userEventsSummary'
[array]$Data = Invoke-MgGraphRequest -Uri $Uri -Method GET -OutputType PSObject | Select-Object -ExpandProperty Value

$Data

id                : d93bdb0a-8cb7-4303-a8ef-48c488997c38
feature           : registration
userPrincipalName : John.Jameson@office365itpros.com
userDisplayName   : John Jameson
isSuccess         : True
authMethod        : sms
failureReason     :
eventDateTime     : 01/08/2025 12:35:30

User Registration Method Summary

The userRegistrationMethodSummary resource is a summary of the number of users registered for each authentication method. To access the summary, run the request as follows:

$Uri = "https://graph.microsoft.com/beta/reports/authenticationMethods/usersRegisteredByMethod(includedUserTypes='all',includedUserRoles='all')"
[array]$data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType PSObject | Select-Object -ExpandProperty userRegistrationMethodCounts

$Data

authenticationMethod               userCount
--------------------               ---------
password                                   0
email                                     11
mobilePhone                              126
alternateMobilePhone                       0
officePhone                                0
microsoftAuthenticatorPush               115
softwareOneTimePasscode                   15
hardwareOneTimePasscode                    0
microsoftAuthenticatorPasswordless         2
windowsHelloForBusiness                    1
fido2SecurityKey                           0
temporaryAccessPass                        0
securityQuestion                           0
macOsSecureEnclaveKey                      0
passKeyDeviceBound                         1
passKeyDeviceBoundAuthenticator            1
passKeyDeviceBoundWindowsHello             0
externalAuthMethod                         0

User MFA Sign-In Summary

The userMfaSignInSummary list method is the one that interested me the most. Essentially, the report gives a daily sign-in report for 30 days detailing the total sign-ins and the number for MFA and single-factor sign-ins. A record looks like this:

id                  : f7c6b675-e664-44dc-9523-947501b0fac6
createdDateTime     : 15/07/2025 00:00:00
totalSignIns        : 59
singleFactorSignIns : 17
multiFactorSignIns  : 42

I used the report to interrogate the sign-in audit log for days when single-factor sign-ins occurred to discover which accounts and apps are involved. The command used to find single-factor sign-ins for a day looks like this (the beta cmdlet is used because the V1.0 cmdlet doesn’t currently return the authentication requirement):

[array]$SignInRecords = Get-MgBetaAuditLogSignIn -Filter "createdDateTime gt $StartDate and createdDateTime lt $EndDate and AuthenticationRequirement eq 'singleFactorAuthentication' and status/errorCode eq 0" -Sort "createdDateTime DESC"

Figure 1 shows the report output. The idea is that administrators can use this information to figure out why single-factor authentications still happen. Most of the accounts highlighted by the report are guest accounts that don’t use MFA because I disabled the conditional access policy to enforce MFA for guest accounts.

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

Looking for Usage

Any API is only useful if it has a purpose. Hopefully, these notes spark some ideas for how to use the report data in campaigns to improve multifactor adoption within Microsoft 365 tenants. At least, that’s the general idea…

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.

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.

Unverified Sender Visual Marker to Warn of Potential Problems

It’s easy to forget details of the reports about new features that appear in the Microsoft 365 message center, especially when a delay occurs between the expected availability date and when the feature appears in plain sight. This is the case with MC1112452 (10 July 2025, Microsoft 365 roadmap item 491471), which reports the arrival of a new visual indicator in Outlook mobile to highlight messages from unverified senders. The indicator doesn’t mean that the message contains spam or malware; just that its properties are unexpected in a way that might be problematic.

I knew about the feature and had read that mid-July 2025 was the scheduled rollout date. Alas, after that I forgot about unverified visual indicators until a bunch of messages were tagged on August 18 (Figure 1).

MC1112452 says that the new visual warning “aligns with existing functionality in Outlook for desktop and web, bringing a consistent experience across platforms.” Later, the text adds “This feature is available by default when the unverified signal is received by the service.” The support documentation notes “If the message is suspicious but isn’t deemed malicious, the sender will be marked as unverified to notify the receiver that the sender may not be who they appear to be.”

No administrative controls exist to enable or disable the marking of unverified senders. This seems like a pity because external mail tagging, which is another marking applied to inbound messages by Exchange Online, can be turned off or on. The same is true for the first contact safety tip, which can be disabled through the anti-phishing policy actions in the Microsoft Defender portal.

Message Headers and Visual Markers

After examining the headers of several unverified messages, it seems like if the Exchange Online transport service determines that an inbound message can’t be fully verified in terms of the normal tests it applies like SPF, DKIM, and DMARC, the service marks the message as unverified, and users see the warning alongside the message in the message list.

For example, Figure 2 (generated by the Message Header Analyzer) shows that Exchange was unable to check the DKIM status for a message, perhaps because DKIM configuration error in DNS or the email is routed through a third-party mail hygiene system like Mimecast that must be configured in a certain manner for DKIM to work properly.

Same Warnings in other Outlook Clients

As noted above, the functionality now implemented in Outlook mobile matches what users see in Outlook classic, OWA, and the new Outlook for Windows (adjusted to match the UX of the client).

The interesting thing is that Outlook only displays the unverified sender warning in the message list for the first message in a thread. If you reply to an unverified sender, the warning is still present, but only for that message. Any subsequent messages received from that sender are not highlighted, even if the same issues persist with DKIM etc. Perhaps the logic here is that if you engage in an email conversation with a sender, that person is verified by your action and Outlook no longer considers them to be unverified. It’s the best theory that I have to explain what I see happen.

Most Unverified Senders are OK, and Then There’s a Bad One

Marking email coming from unverified senders is a good idea. In many cases, a perfectly simple reason exists for why the verification checks fail and the sending system can quickly adjust their configuration to address the problem. In others, a user could receive a message that’s an attempt to impersonate someone else. Hopefully, messages from attackers will be intercepted by Exchange Online Protection, Microsoft Defender for Office 365, or whatever anti-malware service is deployed, but it’s nice to have another check. Just in case.

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.

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!

Microsoft to Remove Mobile Device Management Options

Message Center Notification MC1130607 (7 Aug 2025) announces that Microsoft plans to remove the Mobile Devices section (Figure 1) from the Settings options available in OWA and New Outlook for Windows. Removal will commence starting on September 9, 2025, and is due to be complete in all tenants by October 9, 2025.

According to Microsoft, the change “simplifies device management and aligns with modern tools that offer more robust controls for administrators and end users.” From a user perspective, the biggest impact is that they will no longer be able to remove mobile devices linked to their account. I don’t think many users are very good at cleaning up old devices, so this aspect might not be noticed.

I’m in the category of people who don’t clean up old devices. Part of the problem is that the information presented in OWA settings isn’t very helpful because it simply lists “Outlook” as the device name. Including the device O/S, which is available for a device (Figure 2), would make it easier to identify unused devices.

In any case, this doesn’t matter any more because the options to manage mobile devices will disappear from OWA and the New Outlook soon. What people might miss more is the ability to wipe lost or stolen devices.

Other Options for Users to Disable or Wipe Mobile Devices

Microsoft points out that devices can still be managed through the device list available in the My Account portal (Figure 3). The portal lists all devices that are registered to the user and only allows users to disable a mobile device. This means that the device is blocked from accessing any tenant resources. It is not a device wipe and any sensitive information present on the device remains accessible if someone can get past whatever security methods are used to sign into the device.

Microsoft also points out that administrators can initiate a remote wipe for a registered device through Intune Endpoint Manager. The issue here is that someone who’s lost a device that contains sensitive data often wants an immediate wipe instead of waiting for an administrator to act.

Options also exist for a device owner to use vendor tools to remote wipe a device (iOS or Android).

Mobile Device Management in EAC

Microsoft doesn’t say anything about the mobile device management options in the Exchange admin center (EAC) or the PowerShell cmdlets that underpin mobile device management in both EAC and OWA (here’s an example of using the cmdlets to create a report of registered devices).

EAC has a mobile devices section, but that only deals with access and mailbox policies. Management of devices for a specific user is done by selecting the mailbox and choosing the manage mobile device link from mailbox properties (Figure 4). Care must be taken to select the correct target device before performing a remote wipe as it’s all too easy to select an old or inactive device.

A Justified Change

I’m unconvinced that this change simplifies device management, but I’m sure that Microsoft telemetry probably tells a tale of poor usage of mobile device management by users through OWA and the new Outlook. If that is the case, it’s reasonable for Microsoft to reduce their engineering and support costs by removing these options from the clients and push the responsibility for remote wipes to administrators. The fact that O/S vendors have options to disable and wipe devices gives additional justification for the change.

What’s clear is that tenants should give users clear and precise instructions about what they should do to secure sensitive information should a mobile device be lost or stolen. If you have this kind of advice, it’s time to update it to reflect the new reality.

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.

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.

Priority Cleanup Can Remove Items Under Hold

Update August 15, 2025: Microsoft has decided not to proceed “with this change at this time.” This decision extends to both Priority Cleanup for Exchange Online (in preview since earlier this year) and is a delay to that feature reaching GA. No reason is given for the decision. It does not affect Priority Cleanup for SharePoint and OneDrive, which is currently scheduled for preview in mid-September and GA in mid-November 2025.

Message Center notification MC1115304 (14 July 2025, Microsoft 365 roadmap item 496151) trumpets the “Introduction of secure workflow to bypass retention/legal holds on OneDrive and SharePoint.” It is the logical follow-on for the original preview of Purview Priority Cleanup that was launched earlier this year that was limited to removing mailbox items. Microsoft says that the public preview of the new capability will rollout between mid- and end-August 2025 with general availability due at the end of September 2025. Priority Cleanup is a premium solution, so E5 licenses are required.

Interestingly, Microsoft emphasizes that tenants can use priority cleanup to remove Copilot-related artifacts such as Teams recordings and transcripts independently of other content stored in users’ OneDrive for Business accounts. It’s always been possible to create an auto-label retention policy to target Teams recordings to make sure that these files don’t hang around too long. The difference is that a priority cleanup permanently removes the files even when a retention policy is in place to retain them for a set period.

Cleanups Aren’t Fast

When I reviewed Priority Cleanup in March 2025, I reported how Microsoft built the solution from several existing components and, while this approach is effective, it means that a priority cleanup can be quite slow to find, process, approve, and finally remove items. Don’t expect a cleanup to be a speedy operation, especially in large tenants, especially when hundreds or thousands of items are identified for checking.

The big selling point for Priority Cleanup is its ability to ignore retention holds. Let’s say that a tenant decides to remove all items associated with a specific project. The scope for the search might be a set of SharePoint Online sites and the OneDrive for Business accounts and mailboxes belonging to project members. A general retention policy of five years might apply to email and seven years to SharePoint and OneDrive. Priority Cleanup searches the target locations to find matching items, presents them for approval by a different administrator to the person who created the cleanup policy, and actions the decisions of that approver. If the decision is to remove items, Purview permanently erases the items from their host locations, ignoring retention policies, retention labels (including those that apply preservation lock), and eDiscovery or litigation holds. The documentation covers other details, including how items in eDiscovery review sets are processed and when a separate approval by a retention administrator is needed.

Who Needs to Ignore Retention?

The question is who needs to ignore the holds imposed by Purview Lifecycle management, Exchange MRM, or eDiscovery? It’s often true that email needs to be removed from mailboxes because some malware got through or someone posted something that they shouldn’t have. The latter case can be handled by Exchange’s much-improved message recall facility, at least within the tenant boundary. All bets are off when email escapes from the tenant. Removing malware is more problematic since the demise of the Search-Mailbox cmdlet. A compliance search purge action or eDiscovery purge will move the offending messages out of sight from user eyes, but the messages remain in mailboxes until any retention holds expire. Quite how much extra value is gained from removing the items before retention expires is debatable.

Things are different for SharePoint Online and OneDrive for Business. Purge actions don’t work for files and there’s never been an equivalent of a Search-Mailbox cmdlet for these locations. The two-phase recycle bin arrangement followed by retention (if needed) in the preservation hold library is more complex, especially when multiple versions of files are retained. Given the additional factors, it’s unsurprising that Microsoft has taken longer to create priority cleanup for SharePoint and OneDrive. However, the same question arises: who needs this feature?

Some Tenants Need to Remove Material

Answering myself, Microsoft must have a body of evidence from customers attesting to the need for priority cleanup. And I guess that if the process is managed properly with due regard to the need to keep business records and whatever other material is mandated by law, then priority cleanup has its place. It will be interesting to hear how tenants use this capability.

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.

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.

If a Tenant Has Microsoft Defender for Office 365, Its Shared Mailboxes Need Licenses

When discussing the need to license Exchange Online shared mailboxes, the usual answer is that Exchange Online Plan 2 licenses are needed when shared mailboxes have an extended quota (100 GB instead of 50 GB), an archive mailbox, or are on litigation hold. In other areas of functionality, like Microsoft 365 retention policies, Microsoft makes it clear that no licenses are needed unless premium features like auto-label policies or adaptive scopes are used.

The usual line taken by Microsoft for licensing shared mailboxes is anchored on the features available in Exchange Server. For example, basic retention processing doesn’t require licenses because Exchange Server includes similar retention policies. But Exchange Server doesn’t support adaptive scopes, so use of that feature creates the need for licenses.

Microsoft Defender for Office 365 Plan 1 and Plan 2

This brings me neatly to the question of licensing shared mailboxes for Microsoft 365 Defender for Office 365 (MDO), an advanced version of Exchange Online Protection (EOP) that offers significantly better protection against threats communicated in email. MDO is available in two plans: MDO Plan 1 for small to medium businesses and included in SKUs like Microsoft 365 Business Premium, and MDO Plan 2, which is targeted at enterprises but can be bought and deployed by SME tenants.

From an enterprise perspective, the thing to remember is that MDO Plan 2 is only included in E5 SKUs like Microsoft 365 E5 (see this chart for more information). Figure 1 shows the Threat Analytics feature licensed by MDO Plan 2.

The MDO service description says that shared mailboxes in MDO Plan 1 tenants must have licenses if the mailboxes “benefit from Defender for Office 365 protections.” No further guidance is given to define how shared mailboxes benefit from MDO but given that MDO includes features like Safe Attachments and Safe Links, you could say that any shared mailbox that receives email from external senders benefits from malware scanning and threat protection performed by MDO. And because any shared mailbox can send and receive email, Microsoft considers that all shared mailboxes need MDO licenses.

The situation is simpler for enterprise tenants because the guidance here is that MDO licenses are required for “All shared mailboxes on the tenant.” In effect, this means that any Microsoft 365 tenant that implements the features licensed by Microsoft Defender for Office 365 Plan 2 (see the service description) because they have acquired some E5 licenses must license all shared mailboxes for MDO. In fact, the text of the Microsoft Defender for Office 365 service description goes on to say that user accounts that don’t have E5 licenses must also be licensed for MDO. The text says that licenses must be acquired for “All Exchange Online users on the tenant. This is because Plan 2 features and capabilities protect all users in the tenant.”

The Sudden Realization that Shared Licenses Need MDO Licenses

I’m not sure that many tenants with MDO understand the need to license shared mailboxes. The MDO Plan 2 license costs $5/month with a 12-month commitment, or $60 per shared mailbox annually. Some organizations make heavy use of shared mailboxes, including as a method to preserve mailboxes for ex-employees (inactive mailboxes are the recommended approach). A thousand shared mailboxes will therefore rack up an unexpected $60,000 bill, and that amount doesn’t include any additional licenses that might be needed to bring non-E5 mailboxes into compliance.

I haven’t heard of any Microsoft campaign to make tenants aware of how MDO licensing works for shared mailboxes, nor is there a code check in Outlook to detect and advise when MDO licenses are necessary. The Exchange Admin Center (EAC) includes an option to switch a user mailbox to a shared mailbox, and that option doesn’t warn administrators about potential licensing requirements.

To be honest, I was unaware of the need until I read the service description after being asked if shared mailboxes needed MDO licenses because a customer had been unexpectedly told that the licenses were required. I suspect that many others are in the same state of blissful licensing ignorance.

Unexpected Painful Costs

Any unexpected cost is bad news. Suddenly discovering that a tenant has a batch of unlicensed shared mailboxes is firmly in that category. Discovering that some user accounts that don’t have E5 licenses might need MDO licenses is also painful. There’s nothing good to report here.

Not a Trace of SQL in the New Teams Search Box

In June 2020, Microsoft introduced support for basic Keyword Query Language (KeyQL) searches against Teams chat and channel messages. I’m not sure how many people dedicated much time to constructing queries, but the facility existed for those who cared. Five years later, Microsoft is revisiting KeyQL search for Teams, and this time it’s done in a more comprehensive manner because Teams now supports KeyQL searches across more than messages.

The news comes in MC1130388 (6 August 2025, Microsoft 365 roadmap item 496590), which announces that “Teams is introducing SQL-like structured search queries (e.g., from:, in:, is:) to filter messages, files, and conversations more precisely.” The reference to SQL-like search queries excited many commentators, but the allusion to SQL is misleading. What the Teams search bar supports is a modified version of KeyQL to build queries tailored for the Teams environment. It’s like the way that KeyQL supports different kinds of queries for Exchange Online (email items) and SharePoint Online/OneDrive for Business (files). There isn’t a sniff of SQL in the vicinity.

The new search box is rolling out to targeted release tenants and is available for desktop and browser clients. The new search isn’t available for mobile clients. Microsoft expects KeyQL-powered searches to be generally available worldwide by mid-August 2025. User documentation is available online.

Target Audience for the Teams Search Box

Microsoft is more accurate that the new feature “is especially useful for developers and power users who prefer to express specific search intent to narrow down search results.” If users put the effort into learning how to use search effectively, they will find it easier to find what they’re looking for. This is especially so in large organizations that have used Teams for several years when people attempt to find something in a mass of chats and channels can be difficult.

Funnily enough, an organization like Microsoft is exactly the type that is likely to benefit most from the new search box. A large population of technical folks who have been using Teams since its 2017 debut and might have participated in hundreds of chats in that time. Despite the best effort of Teams to hide inactive channels from view, those users probably interact with too many channels for their own sanity, and finding material from more than a few months ago is challenging. The new search box should help these people find items faster.

Using the New Search Box

Figure 1 shows an example of using a KeyQL query to find messages. The query includes a keyword followed by three filters to focus on who sent the messages (from:), when they sent the message (sent:), and the is:Messages filter to specify that the query should only return messages rather than any other type of content like a file. The from: filter accepts either a user’s display name or primary SMTP address. In this example, “Office 365” is in quotes to force Teams to look for an exact match. Without the quotes, Teams find messages with Office or 365.

Other useful search options include:

• In:Channel or group chat name. For example: “in:Microsoft 365 News” searches the Microsoft 365 News channel in any team the user has access to that has a channel of this name.
• Subject:Keyword from a channel message with a subject line. For example, subject:Copilot finds messages with Copilot in the subject.
• Is:Meetings searches calendar items for the keyword text. For example, “Teams is:Meetings” returns any calendar items that have Teams in the meeting subject or message body.
• With:username finds messages involving a user. For example, this query finds any message containing the “production” keyword involving Paul Robichaux on 5-May-2024: “production is:Messages with:Paul Robichaux sent:5-May-2024.”
• Use an asterisk (*) for partial matches. For example, “Microsoft 3*” is:Messages finds messages containing “Microsoft 365.”
• Unsupported or badly formed queries force Teams to default to standard search results.

When typing into the search box, you’ll find that Teams attempts to auto-correct or auto-match terms (like people or channel names). Like other auto-correct scenarios, this can sometimes get in the way. If you pick a category, like messages or files, Teams shows a list of recently-accessed objects of that type.

After running the query, the search box has additional built-in refiners to filter the set further. For instance, the date refiner supports setting a date range (it would be nice if the query supported a date range, but it does not seem to), while the More refiner includes options to find messages that @mention the user or have attachments.

Overcoming Muscle Memory

The thing about computer searches is that people tend to accrue muscle memory and search like they have for years. You see people interrogating Teams like they search Google or Bing. I’m unsure how many users, even power users, will embrace the ability of Teams to search more intelligently than before, but it’s nice to have the option.

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.

Dedicated Hybrid Connectivity App Fails to Gain Traction

In April 2025, Microsoft announced a dedicated Entra ID app for hybrid connectivity as part of its campaign to dump Exchange Web Services (EWS) from Exchange Online tenants in October 2026. Microsoft has a separate goal to remove EWS from its own apps by October 2025, a move that affects popular apps like Outlook (classic) and Teams.

The dedicated hybrid connectivity app is not an enterprise app created and controlled by Microsoft. Instead, each tenant that runs a hybrid Exchange environment must create a separate tenant-specific version of the app using a Microsoft-provided script.

Once created, the app’s service principal holds the necessary permissions for Exchange Online to use Graph APIs to enable “rich coexistence,” which is code for allowing Exchange Online to act as a broker to fetch data stored in user mailboxes for use by apps, such as the Teams calendar app (in passing, MC1129730 (5 August 2025), says that Microsoft will remove the toggle to allow users to switch between the old and new versions of the Teams calendar app in September 2025).

Power Outages Coming

Unhappily, great plans have a nasty habit of running into problems, which is what has happened here. Tenants are not complying with Microsoft’s wish to create the dedicated hybrid connectivity app, which led to an August 6 EHLO post saying: “the number of customers who have created the dedicated app remains very low.”

To encourage customers to make the switch, Microsoft says that they will “introduce short-term EWS traffic blocks” during the following dates:

Crucially, these interruptions in service do not affect tenants that have created the dedicated hybrid connectivity app. Like a flickering alarm light, the time-outs are intended to prompt customers to act. Of course, this depends on tenant administrators or users noticing the effect of an EWS outage and figuring out what happened. You’ve got to assume that even the least attentive administrator will notice a three-day loss of service…

Microsoft says that tenants won’t get exemptions from the time outs and the dedicated hybrid connectivity app needs to be in place before October 31, 2025, before EWS connectivity via the old app is permanently removed.

The New HCW

The good news is that a revamped version of the Hybrid Configuration Wizard (HCW) can configure the dedicated hybrid connectivity app for a tenant. A setting override is still needed to complete the switchover, but all the steps to configure the app with the permissions (EWS for now, Graph API after a future update) and certificates is done.

Security Advisory for EWS Weakness

Microsoft also points out that changing to the new configuration will improve tenant security. EWS is not very secure, and evidence exists that attackers have exploited the protocol in the past in tenant compromises. Indeed, Microsoft cites MSRC advisory CVE-2025-53786 describing an elevation of permission when “an attacker who first gains administrative access to an on-premises Exchange server could potentially escalate privileges within the organization’s connected cloud environment without leaving easily detectable and auditable trace. This risk arises because Exchange Server and Exchange Online share the same service principal in hybrid configurations.”

Moving to the dedicated hybrid connectivity app addresses the weakness reported in CVE-2025-53786.

Path Forward is Clear

The call to action is clear. Any Microsoft 365 tenant with a hybrid Exchange configuration needs to get with the program and create the dedicated hybrid connectivity app. Failure to do so will only lead to disruption and pain. Don’t put this off: make your tenant more secure and take a positive step to jettison EWS. You know it’s the sensible thing to do.

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

Personalize Copilot to Make it Better for You

A July 14 Microsoft Technical Community post introduces “Copilot Memory,” a new feature that Microsoft claims makes Copilot smarter and “more in tune with how you work” by remembering key facts about how a user likes to work. In other words, the feature allows people to personalize Copilot so that they don’t need to repeat instructions about how Copilot should respond to their prompts.

Copilot memory is also covered in message center notification MC1127234 (1 August 2025), which says that general availability should be in September 2025. That conflicts with the original post, which says that “Memory in Copilot will be generally available in July 2025” and notes that the feature is enabled by default.

Adding to Copilot Memory

Fortune favors the brave, so I fired up Copilot Chat (BizChat) and used the suggested method to capture a memory. Copilot responded with “memory updated” (Figure 1).

Selecting the settings option in Copilot’s […] menu duly revealed a personalization section featuring Copilot memory. I added a couple more observations to build out some instructions for Copilot (Figure 2). Interestingly, Copilot combined some of my instructions to make them more concise.

This screen is also where a user can disable Copilot memory or delete individual or all memories.

The work profile tab showed that Copilot had taken note of my job title and location, both sourced from my Entra ID account properties.

Using Copilot Memory

With some memories in place, I created a very simple prompt for Copilot to respond to by asking it to create a list of Entra ID users with PowerShell. In Figure 3, you can see that Copilot included the Microsoft Graph PowerShell SDK in its response because it’s covered by one of the memories that I captured.

Graph Option to Manage Copilot Memory for a Tenant

In their July 14 post, Microsoft promised user and tenant options to manage Copilot memory. Individual user control is mentioned above. Tenant-level control is enabled using the Enhanced Personalization Graph resource type. Interacting with the resource requires the PeopleSettings.ReadWrite.All permission and the signed-in user must hold at least the People administrator role. The default setting is revealed as follows after running the Connect-MgGraph cmdlet to connect to the Graph:

$Uri = "https://graph.microsoft.com/beta/copilot/settings/people/enhancedpersonalization"
Invoke-MgGraphRequest -Method Get -Uri $Uri

Name                           Value
----                           -----
isEnabledInOrganization        True
disabledForGroup

These settings tell us that Copilot memory is enabled for the organization, and no restrictions apply. To update the settings to disable Copilot memory for everyone, you patch the resource with a payload containing the new settings:

$Settings = @"
{
  "isEnabledInOrganization": false,
}
"@
Invoke-MgGraphRequest -Method Patch -Uri $Uri -Body $Settings

Name                           Value
----                           -----
isEnabledInOrganization        False
disabledForGroup

After a short period, Copilot memory is disabled for user accounts (Figure 4).

But let’s assume that you want some people to be able to use Copilot memory and not others. In this case, create an Entra ID (security) group and pass its details in the payload. This example reenables Copilot memory for the tenant and adds a group of restricted users:

$GroupId = (Get-MgGroup -Filter "displayName eq 'Users disabled for Copilot Memory'").Id
$Settings = @"
{
  "isEnabledInOrganization": true,
  "disabledForGroup": "$GroupId"}
"@

Invoke-MgGraphRequest -Method Patch -Uri $Uri -Body $Settings

More Personalization Makes Copilot Better

Microsoft obviously hopes that personalization will make Copilot more attractive to users. Another example of this strategy in action is the Prioritize My Inbox option to give Copilot instructions about how to filter email. I’m a big fan of removing the need to repeat myself, which is essentially what these options do, so I think they add value. Whether others agree and choose to use Copilot instead of ChatGPT or another competitor remains to be seen.

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! Not even Copilot can help us figure out some of the intricacies of Microsoft 365.

No Need for Licenses to Include Shared Mailboxes in Retention Policies

After writing about how to replace Exchange litigation holds with Microsoft 365 retention policies, I received a question whether retention policies cover mailboxes that don’t have an Exchange Online Plan 2 service plan, like shared mailboxes. Exchange Online Plan 2 is included in many Office 365 and Microsoft 365 licenses and can be bought and assigned as a separate license. For instance, you can assign an Exchange Online Plan 2 license to a shared mailbox to allow that mailbox to use an archive mailbox, increase its storage quota from 50 GB to 100 GB, or be placed on litigation hold (here’s how to check shared mailboxes against licensing requirements).

The answer is that retention policies with static locations cover shared and other resource mailboxes without requiring a license. The relevant text says: “For many [data lifecycle management] features, a shared or resource mailbox does not need a license assigned.” Shared mailboxes do need licenses when use is made of data lifecycle management features that require user mailboxes to have E5 or Microsoft 365 Compliance or Microsoft 365 Information Protection and Governance licenses. Retention policies based on adaptive scopes are an example.

Adding a Shared Mailbox to a Retention Policy

When a new shared mailbox is created, it receives a default mailbox retention policy. The retention policy is defined in the mailbox plan applied by Exchange Online when it creates the mailbox. In many cases, the Exchange retention policy (called a legacy retention policy by Microsoft) is sufficient to clear out old messages from the mailbox on a regular basis (or move items to an archive mailbox). If a tenant has a Microsoft 365 retention policy covering all Exchange Online mailboxes, shared mailboxes are covered by that policy.

You can also add the shared mailbox to a specific Microsoft 365 retention policy by editing the policy and selecting the shared mailbox, just like any other mailbox (Figure 1).

Mixing the two types of retention policy doesn’t matter because the Exchange managed folder assistant (MFA) combines the settings from all the policies that apply when it processes a mailbox to remove expired items. After the shared mailbox is added to a Microsoft 365 retention policy, you should see the hold applied by the policy in the set of in-place holds noted for the mailbox. For example:

Get-Mailbox Customer.Services@office365itpros.com| Format-List InPlaceholds
InPlaceHolds : {UniHcac6fa1f-ce89-43ef-9e56-839a0e164662}

Creating a Special Microsoft 365 Retention Policy for Shared Mailboxes

Although Exchange retention policies are usually all that’s needed for shared mailboxes, you might feel that it’s best to use Microsoft 365 retention policies for all retention processing and create a Microsoft 365 retention policy for shared mailboxes. The advantage of using a targeted retention policy for shared mailboxes is the ability to apply different retention settings to those used for user mailboxes.

Remember the two downsides of this approach:

• Folder-specific processing isn’t possible with Microsoft 365 retention. All folders have the same retention setting.
• Microsoft 365 retention policies can’t move items to archive mailboxes. This feature requires shared mailboxes to have an Exchange Online Plan 2 license.

To illustrate the point, I wrote a PowerShell script to create a Microsoft 365 retention policy especially for shared mailboxes. The script does the following:

• Connect to Exchange Online and Compliance PowerShell endpoints.
• Find all shared mailboxes.
• Create a new Microsoft 365 retention policy.
• Add the shared mailboxes to the retention policy. Up to 1,000 individual mailboxes can be added to a single retention policy. If a tenant has more than 1,000 shared mailboxes, you’ll need to split the mailboxes across multiple policies. In this scenario, I would write the name of the policy used for a mailbox into one of the 15 custom attributes available for mailboxes.
• Create a retention rule to keep items for two years (730 days). Obviously, you can choose a different retention period.
• Remove the Exchange retention policy from the shared mailboxes.

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

Another step to consider is to exclude shared mailboxes from any Microsoft 365 retention policy that processes “All Exchange mailboxes.” This simplifies the retention processing for shared mailboxes to make sure that retention periods and actions from other policies don’t interfere with settings in the retention policy for shared mailboxes.

Some More Work

The retention policy created by the script processes shared mailboxes which exist at that time. More work is needed to maintain the retention policy by adding new shared mailboxes (deleted shared mailboxes are automatically removed from policies). That task is easily done with another script, which I’ll cover in a different post.

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!

Automatic Management of Access Tokens

Some years ago, I wrote about the access (bearer) tokens used by Entra ID. At the time, I focused on the access tokens obtained by apps from https://login.microsoftonline.com rather than those used by the Microsoft Graph PowerShell SDK.

One of the big advantages of using the Microsoft Graph PowerShell SDK is that developers don’t need to manage token renewal. When a script or app runs the Connect-MgGraph cmdlet to authenticate, an access token is obtained to allow cmdlets to run. When that access token approaches its expiration time, the Graph SDK requests a new token automatically.

Unless you knew that automatic renewal happens, you probably won’t realize how the Graph PowerShell SDK acquires and manages access tokens because details of the access token aren’t surfaced by a cmdlet like Get-MgContext. Although Get-MgContext reveals details of the current authentication context such as whether delegated or app-only authentication was used and the scopes (permissions) available to the session, there’s no trace of the access token.

Finding the Access Token Used by a Microsoft Graph PowerShell SDK Interactive Session

Some might be surprised that it’s not easier to find what access token is being used during a Graph PowerShell SDK session. However, automatic token management means that knowing what an access token is and when the token will expire is not information that’s necessary for a session to function, so it’s reasonable to keep the data hidden behind the scenes.

To find the access token, it’s necessary to make a special form of request to any Graph API. The request can be made in an interactive session or an app-only session. This example uses a request against the drives endpoint to retrieve retention label information for a file, but any request will work:

$Uri = ("https://graph.microsoft.com/v1.0/drives/{0}/items/{1}/retentionLabel" -f $OneDriveInfo.Id, $File.Id)
$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get -OutputType HttpResponseMessage

The key point here is that the Invoke-MgGraphRequest cmdlet specifies that it should receive a HTTP response rather than data. The request specified in the URI is simply a way to ask the Graph for the HTTP response. The response contains several interesting components:

Version             : 2.0
Content             : System.Net.Http.DecompressionHandler+GZipDecompressedContent
StatusCode          : OK
ReasonPhrase        : OK
Headers             : {[Cache-Control, System.String[]], [Vary, System.String[]], [Strict-Transport-Security, System.String[]], [request-id, System.String[]]…}
TrailingHeaders     : {}
RequestMessage      : Method: GET, RequestUri: 'https://graph.microsoft.com/v1.0/drives/b!_xwZzApnQEeEWOYGdTfHR_FlEFWmBHl                      JixksigwWMZ_hpEW05Pd_R7OzPT4YdqXq/items/01R343MZ43HNLCSCCT3ZBLLUIJGB3GJ5B3/retentionLabel',
                      Version: 2.0, Content: <null>, Headers:
                      {
                        User-Agent: Mozilla/5.0
                        User-Agent: (Windows NT 10.0; Microsoft Windows 10.0.26100; en-IE)
                        User-Agent: PowerShell/7.5.2
                        User-Agent: Invoke-MgGraphRequest
                        FeatureFlag: 00000003
                        Cache-Control: no-store, no-cache
                        Authorization: Bearer eyJ0eXAiOiJKV1QiLCJub25jZSI6IlZrTmh0QjdFajZpSUhRVkRwdmZYeVVldUEyeFFBbFhyR1M

The access token is at the bottom of the output and can be retrieved with:

$Data.RequestMessage.Headers.Authorization.Parameter

Decrypting an Access Token

Isolating the access token makes it easier to copy and input into the jwt.io token decoder. Figure 1 shows the raw JSON output; selecting the claims table tab presents the information in a more easily understood fashion (this reference page also helps).

The decoded token reveals details like the app in use (Microsoft Graph Command Line Tools), its identifier, the user, and the available permissions

"app_displayname": "Microsoft Graph Command Line Tools",
  "appid": "14d82eec-204b-4c2f-b7e8-296a70dab67e",
  "family_name": "Redmond",
  "given_name": "Tony",
  "idtyp": "user",
  "ipaddr": "109.78.233.203",
  "name": "Tony Redmond",
  "oid": "eff4cd58-1bb8-4899-94de-795f656b4a18",
  "scp": "AccessReview.Read.All Agreement.Read.All Analytics.Read APIConnectors.Read.All Application.Read.All Application.ReadWrite.All AppRoleAssignment.ReadWrite.All AuditLog.Read.All AuditLogsQuery.Read.All
...

The token also contain timestamps in UNIX epoch format for when the token was issued and when it will expire. The claims table output shows the date in local time. You can also convert these dates with PowerShell:

$UnixEpochValue = 1752763429
$Date = [DateTimeOffset]::FromUnixTimeSeconds($UnixEpochValue).ToLocalTime().DateTime
Write-Host "UNIX epoch $UnixEpochValue is" $(Get-Date $Date -format 'dd-MMM-yyyy HH:mm')
UNIX epoch 1752763429 is  17-Jul-2025 15:43

Down further in the token you’ll find the wids array, which holds the identifiers for the Entra ID roles held by the user. Remember, during an interactive Graph SDK session the available permissions are the intersection between delegated permissions and administrative roles. In other words, if access to data isn’t available through a permission, it might be through a role.

Reusing a Graph Access Token

You can take the access token used by the Graph interactive session and use it to retrieve information without using a Graph SDK cmdlet. In this code snippet, we prepare a hash table containing the access token formatted in the way that Graph requests expect the data to be presented and use the token with the Invoke-RestMethod cmdlet to find the details of the signed-in user.

$Headers = @{}
$Headers.Add("Authorization", ("{0} {1}" -f $Data.RequestMessage.Headers.Authorization.Scheme, $Data.RequestMessage.Headers.Authorization.Parameter))

$Me = Invoke-RestMethod -Uri "https://graph.microsoft.com/v1.0/me" -Headers $Headers
$Me.displayName
Tony Redmond

Interesting But Not Very Useful Information

All of this is firmly in the interesting but not very useful category. If an app wants to make Graph API requests without using the Microsoft Graph PowerShell SDK, it will do the norm and obtain an access token programmatically before running any requests. The permissions available to the app are the set of delegated and application permissions held by the app’s service principal. If the app runs for over an hour, it will need to renew the access token.

Apart from testing code to write this article, I don’t think I have ever looked at the access token in a Microsoft Graph PowerShell SDK session. I might in the future, but right now I can’t think of a good reason why I should.

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.

August 2025 Update Available for Subscribers to Download

The Office 365 for IT Pros team is delighted to announce the availability of monthly update #122 for Office 365 for IT Pros (2026 edition). This is the first update since the publication of the 2026 book, and it includes a bunch of changes covering new information unearthed or researched over the last month. You can see more details about the updates in our change log.

Subscribers for the 2026 edition can fetch the updated files using the link in the receipt emailed to them from Gumroad.com after their purchase. The link is personalized to the subscriber and always fetches the latest files. See our FAQ for more information.

Many previous subscribers have renewed for the 2026 edition. We are humbled by the level of support we receive from the technical community. If you are a previous subscriber, you should have received email from us with instructions about how to extend your subscription at a heavily discounted rate. Because we became tired of Gumroad.com emails being blocked as spam, we sent individual emails to thousands of previous subscribers. I believe every subscriber should have received a note from us by now. If not, please contact us at o365itprosrenewals AT office365itpros.com.

Microsoft Cloud Keeps on Growing

Microsoft released their FY25 Q4 results on July 30. One of the eye-popping figures was a big leap in Microsoft Cloud revenue to $46.7 billion (up 27% year-over-year). That’s $21 billion more in a quarter than Microsoft earned in FY23 Q1 and represents an annualized run rate of $186.8 billion. Microsoft 365 continues to grow strongly with its revenue up 16% year-over-year. Seat growth is slowing and was 6% year-over-year, mostly in SME and frontline workers. Slower seat growth is inevitable given the size of the installed base (over 430 million, according to CFO Amy Hood when discussing the Microsoft FY25 Q3 results). The growth in revenues is due to upsell to more expensive licenses, including Microsoft 365 Copilot.

Speaking about Copilot, in the best traditional of misleading figures given out during results briefings, Satya Nadella said “Our family of Copilot apps has surpassed 100 million monthly active users across commercial and consumer.” The number claimed sounds impressive, but what everyone really wants to know is how many Microsoft 365 Copilot paid seats are in active use. It was followed by the assertion that “Purview is used by three quarters of Microsoft 365 Copilot customers to protect their data.” Again, no real data to measure anything against.

Interestingly, once again Microsoft didn’t give an updated number for Teams users. The number remains at the 320 million monthly active users claimed in October 2023.

Speaking of numbers, Microsoft reported a 99.995% performance against the Microsoft 365 SLA for the second quarter of 2025. That might come as news to any tenant that experienced a significant outage between April and June, but the result is unsurprising given the number of tenants and seats. It takes a massive outage involving tens of millions of seats over several hours to budge the SLA needle slightly. Outages happen all the time, but none at the level of severity necessary to impact the SLA

Update for the Automating Microsoft 365 with PowerShell eBook

As is our practice, we released an update for the Automating Microsoft 365 with PowerShell eBook earlier than the monthly Office 365 for IT Pros update. The PowerShell book is included with Office 365 for IT Pros, so subscribers should see 4 files when they access the update on Gumroad.com (PDF and EPUB files for both books).

The PowerShell book is available separately, but Office 365 for IT Pros subscribers do not have to purchase it. If you want to read a physical copy, you can buy a paperback version from Amazon.com. I haven’t actually seen the paperback yet, but I plan to get some author copies for delivery to the TEC 2025 conference in Minneapolis at the end of September. Come to TEC and you might get a signed copy! If not, you can still attend TEC sessions delivered by Tony, Paul, Brian, and Michel.

On to Monthly Update #123

Microsoft 365 doesn’t stop changing and we don’t stop analyzing and documenting the most important technical information for Microsoft 365 tenant administrators. It’s what we’ve done since 2015.

New Way to Run DLP Diagnostics Through GUI Instead of PowerShell

The nature of any moderately large Microsoft 365 tenant is that it’s likely to have a collection of different types of policies. Making sure that Entra ID conditional access policies interact well together is essential to control inbound connections and a mistake there can lead to administrators locking themselves out of a tenant. Making mistakes in data lifecycle management (retention) policies can also have grave consequences, such as the famous example from 2020 in the KPMG tenant when an error in a retention policy deleted a bunch of Teams chats. Errors in Data loss prevention (DLP) policies can lead to less obviously bad outcomes, but only because a mistake could end up with sensitive information leaking outside the organization without anyone’s knowledge.

Four DLP Diagnostics

Which brings us to message center notification MC904540 (last updated 9 July 2025, Microsoft 365 roadmap item 418566), announcing that DLP diagnostic options are now available for commercial tenants in the Microsoft Purview compliance portal (Figure 1).

Microsoft originally published the message center notification on 4 October 2024 in anticipation of a preview in December 2024. Alas, problems along the way forced the developers to roll back and rethink the implementation. After additional work, the portal boasts a set of four DLP diagnostics tests that replace the tests previously performed through the ComplianceDiagnostics PowerShell tool.

There’s no word whether additional tests are on the way. However, MC904540 mentions “diagnosing issues encountered while using Microsoft Information Protection (MIP) and Data Loss Prevention (DLP),” so it’s possible that plans are in place to provide diagnostic tests for information protection too.

Testing the DLP Diagnostics

In any case, the DLP diagnostics are intended to help identify the root cause of issues and provide remediation options. I found that some of the tests worked well while others were less impressive. For example, the test to figure out why a DLP policy didn’t signal an alert following a rule match was right on the money when it detected that the DLP rule didn’t include settings to generate an alert (Figure 2). The fix was easy once the fault was identified.

The test to diagnose if a user is covered by a DLP policy was less successful. The output of the test (Figure 3) hid some rule and policy names, and the attention to detail in the output is poor. Like Figure 2, where the reference to “ODB” should be spelt out as OneDrive for Business, the lack of capitalization for “exchange” and the lack of spaces in “OneDriveForBusiness” are easily-fixed bugs.

Perhaps it’s just my tenant where these problems emerged. Perhaps it’s a weird combination of the age of some of the DLP policies and their configurations that cause policy and rule names to disappear. For whatever reason, it was disappointing to see the lack of attention to detail feature in the DLP diagnostics. Although it might seem strange to worry about this kind of thing, experience shows that when attention isn’t paid to the small things in software, big issues might lurk. GitHub Copilot is very good at picking up issues like this and supports multiple languages, so it is really surprising to see Microsoft ship software with so many obvious UX errors.

None of the tests performed by DLP diagnostics are particularly sophisticated and all could be easily done by an experienced administrator who knows the DLP solution. In fairness, the target audience for DLP diagnostics is likely to be tenant administrators who don’t work with DLP very often and need some help to figure out why something might be going wrong.

The Value of Data Loss Prevention

DLP is an important Purview solution that often doesn’t receive enough attention. Microsoft has worked hard to expand DLP capabilities, especially in the area of endpoint devices, and the policies work well for Exchange Online, SharePoint Online, and OneDrive for Business, all of which only require E3 licenses. Including Teams in the mix requires a jump to E5, which has always seemed weird to me. And if you want to use the very valuable DLP policy for Copilot to block AI access to sensitive files, you’ll need Microsoft 365 Copilot licenses.

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

Use a Conditional Access Policy to Block Access to OWA Instead of CAS Settings

Microsoft has updated its advice about how to disable access to OWA while retaining access to the new Outlook for Windows. The update is in MC922623, originally published in October 2024 and updated on 28 July 2025. In a nutshell, Microsoft recommends using a conditional access policy to block access to OWA rather than the mailbox-level OWAEnabled CAS (Client Access Server) setting in CAS.

Apart from the need to deploy Entra P1 licenses, that advice seems straightforward enough. But there are some issues to understand before rushing to deploy a new conditional access policy. Let’s discuss two important points.

Two CAS Settings

The first thing is that there’s actually two policy settings to consider: OWAEnabled and OneWinNativeOutlookEnabled (discussed in this article). Both settings need to be $true in the OWA mailbox policy assigned to user accounts to allow the new Outlook for Windows to load. It seems strange to have two settings, but it’s due to the technical debt accrued over the years managing OWA in Exchange Server and Exchange Online and the need to provide a control to deal with a new client. The fact that OWA and “Monarch” (the new Outlook for Windows) share a lot of code doesn’t help in some respects.

For the purpose of this debate, both OWAEnabled and OneWinNativeOutlookEnabled should be left as $true. In MC922623, Microsoft says keeping both settings at $true will have “no impact on users’ ability to access outlook for the web since the work was already done to block Outlook for the web with another policy.”

Well, that’s not strictly true (no pun intended). For instance, setting OWAEnabled to $false and OneWinNativeOutlookEnabled to $true might seem like the way to block OWA and allow the new Outlook. However, although this configuration blocks OWA, it also stops the new Outlook from being able to download or send messages. Another side-effect (aka, a bug) is that creating a message makes Outlook create multiple copies of the message in the Drafts folder. Overall, it’s best to play safe and ensure that both are kept at $true.

Updated CAS settings can take up to 15 minutes before they are effective.

The Conditional Access Policy to Block OWA

The reference in MC922623 to ”work done to block OWA” is to the conditional access policy (see instructions in the link above). What’s happening here is that Entra ID invokes the conditional access policy as part of its processing of inbound connections. If the inbound connection requests to use Office 365 Exchange Online (the app used by OWA – Figure 1), Entra ID can refuse the connection because the conditional access policy is configured to block OWA. The connection therefore terminates and never gets to Exchange Online for that server to process the connection and check the CAS mailbox settings to determine if mailbox access is permitted with the client.

The downside of using a conditional access policy is that blocking access to the Office 365 Exchange Online app also stops the Teams browser client working (the Teams desktop app continues to work because it uses a different app). I think the reason why this happens is that the Teams browser app shares some components with OWA (like the calendar). Entra ID sees an inbound connection attempting to use an OWA component and terminates the connection in line with the conditional access policy. The dependency of Teams on Exchange Online is listed in Microsoft’s service dependency for conditional access policies guidance.

The nice thing about conditional access policies is that updated settings or new policies become effective almost immediately (Figure 2). Immediacy can also be a bad thing if you make a mistake and lock yourself out of the tenant.

Sometimes Hard to Have Clean Lines in Microsoft 365

The complex interconnected nature of Microsoft 365 sometimes makes it difficult to have nice clean demarcations between applications and workloads. The complex interconnected nature of Microsoft 365 sometimes makes it difficult to have nice clean demarcations between applications and workloads. As we see here, blocking one app with a conditional access policy can have unexpected consequences for other apps.

It’s nice to have choices in how to manage clients, and it makes sense to use a conditional access policy if you have Entra P1 licenses and you can accept the downside of losing Teams browser access. Otherwise, stay with the CAS settings and block access the old way.

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!

Monthly Fee for Guest Accounts That Use ID Governance Features

I recently revisited Entra ID access reviews to find a banner warning about charges for guest accounts that consume Entra ID Governance features (Figure 1). Apparently, the new charges started in June 2025 and are paid for on a metered basis through an Azure subscription associated with the Entra tenant.

The relevant documentation reveals the set of chargeable features for guest accounts. Access reviews for inactive guest accounts are on the list, and that’s why the banner showed up.

Charging is on a monthly active user basis (MAU). This is not the same as the MAU for general guest access to Microsoft 365 groups, teams, and sites, which covers normal activities for up to 50,000 guest accounts monthly. In this case, a monthly active user is any guest account that takes advantage of one of the listed Entra ID governance feature during a month. Every ID Governance MAU incurs a charge of $0.75 (six times the price charged for guest accounts that surpass the 50,000 MAU threshold for normal activity).

Going back to access reviews, if my calculation is correct, a tenant using access reviews to detect and remove inactive guests (as recommended by Microsoft) with access reviews scheduled on a quarterly basis will incur a $3 cost per guest account (4 x 0.75 x number of guests). That might seem like small beans, but costs have a corrosive habit of accruing over time.

DIY Inactive Guest Reviews

It’s not as if Microsoft performs any great magic to detect inactive guests. It’s perfectly feasible to write your own inactive guest removal process and schedule the process using Azure Automation. Your version might not be as pretty as Microsoft’s is, but you can build more intelligence into the review by including searches against audit log data to detect activities other than sign-ins. And a DIY process won’t require Entra P2 licenses either.

Coding a Report of Likely Costs

The Microsoft documentation includes the helpful advice that “You can identify actions that will be billed to the Microsoft Entra ID Governance for guests add-on by looking at your audit logs.” Even a small tenant will have large quantities of data in the Entra ID audit log, so some automation is needed. The data from the Entra ID audit log is eventually ingested into the unified audit log, but in this case, we’ll work with the Entra ID data.

The steps required to find audit log entries that mark chargeable transactions are:

Run the Connect-MgGraph cmdlet to open an interactive Microsoft Graph session. The session needs consent for the AuditLog.Read.All permission, and the signed in user must be an administrator with a role that allows access to the audit logs, like Reports Reader or Security administrator. Finally, the account must have an Entra P1 license, which is needed for API access to audit logs.

Now run the Get-MgAuditLogDirectoryAudit cmdlet to retrieve the audit log entries to analyze. Because Microsoft bills monthly, it seems logical to fetch the logs for the current month:

$FirstDayOfMonth = (Get-Date -Day 1).ToString('yyyy-MM-ddT00:00:00Z')
[array]$AuditRecords = Get-MgAuditLogDirectoryAudit -All -Filter "activityDateTime ge $FirstDayOfMonth and result eq 'success'"

I can’t find a good server-side filter to find the audit records for chargeable events, so a client-side filter does the trick:

[array]$GovernanceRecords = $AuditRecords | Where-Object { $_.additionalDetails.key -eq "GovernanceLicenseFeatureUsed"}

The next part scans the governance records to find if guest users are involved. If so, data is extracted and reported:

If  ('"Guest"' -in $Record.TargetResources.ModifiedProperties.NewValue) {
     $UserDisplayName = ($Record.TargetResources.ModifiedProperties | Where-Object {$_.DisplayName -eq "DisplayName"}).NewValue
     $UserEmail = ($Record.TargetResources.ModifiedProperties | Where-Object {$_.DisplayName -eq "Email"}).NewValue 
     $UserUPN = ($Record.TargetResources.ModifiedProperties | Where-Object {$_.DisplayName -eq "PrincipalName"}).NewValue
     $UserId = ($Record.TargetResources.ModifiedProperties | Where-Object {$_.DisplayName -eq "TargetId"}).NewValue
}

After all records are processed, a report file containing every chargeable event for guest records is available. To reduce the set to individual users, the script sorts the data to extract unique values:

[array]$GovernanceUsers = $GovernanceReport | Sort-Object UserId -Unique | Select-Object UserId, UserDisplayName, UserEmail, UserUPN

Finally, the script reports the results (Figure 2).

You can download the script I wrote from the Office 365 IT Pros GitHub repository.

No Great Insight from Azure Billing

The billing reports for the Azure subscription that is charged has a line item for “P2 monthly active users.” I haven’t seen a detailed list of the guest accounts covered by the charge. Perhaps Microsoft will include this information in the future. If not, I guess it should be easy to correlate the charges levied against a subscription with the list of guest accounts extracted from the audit logs.

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.

Version 14 of Automating Microsoft 365 with PowerShell eBook Available for Download

The Office 365 for IT Pros team is delighted to announce the release of version 14 of the Automating Microsoft 365 with PowerShell eBook. The book is included in the Office 365 for IT Pros eBook bundle and is available for separate purchase by those who are only interested in PowerShell. Naturally, we recommend the full Office 365 for IT Pros bundle! We’ve also updated the paperback edition of Automating Microsoft 365 with PowerShell that’s available on a print on demand basis from Amazon.com.

This update includes new information about Microsoft Graph APIs, the Microsoft Graph PowerShell SDK, code examples, insights gleaned from experience of using Graph APIs and cmdlets in scripts and with Azure Automation, and so on. Version 14 spans 350 content-rich pages and is essential reading for anyone who wants to work with a Microsoft 365 tenant through PowerShell.

If you have an Office 365 for IT Pros subscription or have purchased the separate version of Automating Microsoft 365 with PowerShell, you can download the updated PDF and EPUB files now. Use the View content link in the receipt you were emailed after taking out your subscription to get the files.

Microsoft Graph PowerShell SDK Updates

Speaking of the Microsoft Graph PowerShell SDK, Microsoft released V2.29 on July 9, 2025, and followed up with V2.29.1 a few days later. Regretfully, there was a total lack of formal communication from Microsoft about why the point release was needed so soon after V2.29 appeared. Sources behind the scenes say that a tooling problem was identified that Microsoft felt they should fix. The Microsoft.Graph.BackupRestore module was the only one affected by the V2.29.1 update.

Be aware that the issue with Azure Automation PowerShell runtimes and the Microsoft Graph PowerShell SDK persists. In a nutshell, use PowerShell V5.1 modules and runbooks with the Graph PowerShell SDK (including V2.29.1) until better news emerges.

Metered API Changes

On July 25, Microsoft published message center notification MC1122144 to announce that they are changing how metered APIs in Microsoft Graph incur costs based on usage. Effective August 25, 2025, a set of APIs will no longer be chargeable and it will not be necessary to set up an Azure subscription to pay for the metered use of the APIs.

To say that this announcement was surprising is an understatement. The set of APIs include the assignSensitivityLabel API used to assign sensitivity labels to Office files and PDFs stored in SharePoint Online and OneDrive for Business (here’s how to assign labels with PowerShell). I guess tenants can now build their own auto-label policies to apply sensitivity labels to target content. The APIs also include the Teams chat export API, which is a good example of what Microsoft calls a high-capacity API (access to data at scale). Perhaps Microsoft now considers that its infrastructure can cope with demands from apps to access large quantities of Teams data.

In any case, after August 25, 2025, Azure will register no further billing events when apps call the APIs and customers will receive a final bill.

On to Version 15 of the PowerShell eBook

PowerShell doesn’t remain static and nor do the modules used in Microsoft 365 tenants. We’ll continue working on the Automating Microsoft 365 with PowerShell eBook to add more content by covering additional Graph APIs and new cmdlets introduced in other Microsoft 365 modules, as well as adding more practical examples to demonstrate the principles of using PowerShell to solve real-world problems.

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

Same NoSignOnReply Control for S/MIME Inheritance for Replies as Outlook (Classic)

Message center notification MC1072404 (last updated 21 July 2025) announces the provision of a control over S/MIME inheritance for email replies. The new setting allows tenant administrators to determine whether S/MIME signatures are inherited by default when people use the Reply and Reply All options to generate responses to signed messages.

Essentially, this is the same capability as previously implemented through ADMX Group Policy template files for Outlook (classic), so it’s part of the ongoing work to make sure that the new Outlook is as functional as Outlook classic before the eventual retirement of the old client sometime in 2029 (that date might change if features aren’t in place).

As an online client, the new Outlook depends more on server-based controls than the policy settings stored in the system registry as used by traditional Office apps. Support is rolling out now and should be complete worldwide by early August 2025. Deployment then moves to GCC and should be finished there by late August 2025.

Dropping OWA

When first announced, Microsoft included OWA along with the new Outlook for Windows. This is logical because the two clients share a lot of code. The new Outlook supports functionality that isn’t in OWA, like PSTs (including the recently-introduced export to PST feature) and better offline access, but generally the two clients support the same set of server settings. This is not the case here as Microsoft has decided not to support S/MIME inheritance for replies in OWA.

Updating S/MIME Settings

MC1072404 states that the NoSignOnReply setting is available in Entra ID. This might mean that the tenant S/MIME configuration is stored in Entra ID. However, the Set-SMIMEConfig cmdlet is very much part of both Exchange Server and Exchange Online (the cmdlet goes back at least as far as Exchange 2013 – I can’t recall if it was available for previous versions). Most of the settings manipulated by the cmdlet affect how OWA deals with S/MIME. The NoSignOnReply setting is explicitly excluded for OWA.

In any case, the default value for NoSignOnReply is $true. This means that reply messages created with Reply or Reply All do not inherit the S/MIME signature (Figure 1) from the original message. However, if the original message is encrypted, the replies inherit the same encryption. Microsoft notes that the default setting is useful when an organization has not configured S/MIME signatures for all users.

When the setting is $false, replies inherit the S/MIME signature from the original message. If this is undesirable (for instance, it’s the wrong signature), the user must open S/MIME settings and remove the signature.

Set-SMIMEConfig -NoSignOnReply $false

Details of the S/MIME configuration can be retrieved using the Get-SMIMEConfig cmdlet.

Sites that Duplicate Message Center Notifications are Useless

While checking details of MC1072404, I noticed that there are many sites that simply take the text of message center notifications and publish them as written. No attempt is made to add any value whatsoever in terms of interpretation, insight, or additional information. It’s a wonder to me why people republish message center notifications in this manner. They might get a few page views, but apart from that they clutter up the internet with duplicated material. In fact, given the way that generative AI summaries are now used by Google and other search engines, the number of page views that these sites gain must be much decreased.

We do report on message center notifications, but only when we think we have something useful to add that helps readers understand the nature of the change and how it impacts the Microsoft 365 ecosystem. We don’t always get things right, but at least we’re not a “me too” site.

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

Identifier Makes it Easier to Track User Activities in a Single Session

An interesting July 21 Technical Community announcement describes the introduction of linkable token identifiers for audit events. Essentially, when a user authenticates a session with Entra ID, the session is stamped with a unique GUID (the linkable token identifier). The linkable token identifier is persistent for the session and is inherited by workloads that support the token and inserted into the audit events generated by those workloads accessed during the session.

The idea is that by tracing the linkable token identifier, you can find out what the user did during a session. Linking audit events through the new identifier makes it easier for investigators to query audit data to discover the set of actions taken during a session and their sequencing. This might be necessary to check if an attacker has compromised an account and is exfiltrating data or taking other actions that you don’t want to happen. Of course, account compromise is less likely to happen when user accounts are protected with strong multifactor authentication like the Microsoft Authenticator app, but that’s another story.

The linkable token identifiers are now available in Entra sign-in logs, Exchange Online audit events, SharePoint Online audit events, Teams audit events, and Graph activity logs. Figure 1 shows the identifiers listed in the Entra sign-in log.

Using Audit Searches to Track Activities

Audit events end up in the unified audit log and the article includes a screen shot showing the results of a search using a linked token identifier. Unhappily, the article doesn’t explain that you must use a keyword search to find events linked to a certain identifier (Figure 2).

The reason why a keyword (free text) search is necessary is that workload developers are inconsistent in how they include linkable token identifiers in the AuditData payload of their events. As you’d expect, Entra ID includes a simple SessionId property in the payload, but other workloads like Exchange Online and SharePoint Online refer to the token as AADSessionId.

Finding and Reporting Activities Based on Identifiers

Which brings me to subject of how to search the audit log with PowerShell for all events with a linkable token identifier. The process is reasonably simple. For example, using the Search-UnifiedAuditLog cmdlet, the code is something like this:

[array]$Records = Search-UnifiedAuditLog -Formatted -StartDate $StartDate -EndDate (Get-Date) -UserIds $UserId -FreeText $Session -SessionCommand ReturnLargeSet -ResultSize 5000
  If ($Records.Count -eq 0) {
    Write-Host "No audit records found for session $Session"
    Continue
  } Else {
    $Records = $Records | Sort-Object Identity -Unique
    $Records = $Records | Sort-Object {$_.CreationDate -as [datetime]} 
    Write-Host ("Found {0} audit records for session {1}" -f $Records.Count, $Session)
}

Reporting Audit Events for All Sessions

The code uses a free text search to find all audit events that include the specified linkable token identifier between two dates, removes any duplicates events from the returned set, and sorts the set by the created date.

But how about extending this to generate a report for all events for all sessions within the 30-day period that Entra ID retains sign-in logs. After all, multiple sessions might be created around the same time, and only one of the sessions might be suspicious. To do this, we need to find the full set of sign-in events captured for a user and find the linkable token identifiers in that set. Here’s how to find that information using the Get-MgBetaAuditLogSignIn cmdlet from the Microsoft Graph PowerShell SDK (the beta cmdlet is needed to return the identifiers):

[array]$Logs = Get-MgBetaAuditLogSignIn -Filter "userPrincipalName eq 'lotte.vetler@office365itpros.com'" -All
[array]$Sessions = $Logs | Group-Object SessionId -NoElement | Select-Object -ExpandProperty Name

The $Sessions array now contains the linkable token identifiers, and to generate the report, it’s a matter of looping through the set of identifiers to use each with Search-UnifiedAuditLog to generate the set of audit events for the session. Figure 3 shows the kind of report that can be created from the generated data.

The code I used to create the report is available for download from the Office 365 for IT Pros GitHub repository. In addition to the HTML report, the script also generates a CSV or XLSX file (an Excel worksheet is created if the ImportExcel module is available).

Good for Investigators

I’m sure that investigators will appreciate being able to easily connect the dots to discover what happened during a session. Adding linkable token identifiers to audit events is an example of a low-touch, high-value enhancement for Microsoft 365 tenants. It would be nice if all updates had the same impact.

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.

Removing Members from Groups Can be Complicated

Recently, I discussed how to use Microsoft Graph PowerShell SDK cmdlets to copy the memberships of Entra ID groups from one user to another. I commented that in some cases you might want to remove the memberships for the source user but left that code to the reader to develop and incorporate into the script.

Within an hour of publication, I received a couple of messages asking how to remove users from group memberships. It’s a fair question because the cmdlets used for the task differ across group types. Specifically:

• For Microsoft 365 and security groups, use the Remove-MgGroupMemberByRef cmdlet from the Microsoft Graph PowerShell SDK. At least, that’s the facile answer. As explained below, the real answer is more complicated.
• For distribution lists and mail-enabled security groups, use the Remove-DistributionGroupMember cmdlet from the Exchange Online management module.

Some ask why the membership of mail-enabled security groups is managed using Exchange cmdlets. The answer lies in the mail-enabled nature of these groups. Because they are mail-enabled, their source directory is the Exchange ExODS (Exchange Online Directory Store) rather than Entra ID. Synchronization and dual-write updates keep the two directories in step.

In any case, removing a user account from a distribution list or mail-enabled security group is straightforward:

Remove-DistributionGroupMember -Identity $GroupId -Member $UserId -Confirm:$false -ErrorAction Stop
Write-Host ("User {0} removed from distribution list {1}" -f $TargetDisplayName, $GroupDisplayName) -ForegroundColor Yellow

Why Things are More Complicated with Microsoft 365 Groups

Because of the need to respect how group ownership works, things are a little more complex with Microsoft 365 groups, including the groups used for Teams, and Viva Engage. The rules are:

• If you remove a member, you must check if the account is a group owner. If so, you remove the group owner first and then remove the member.
• However, if the account is the only group owner, you can’t remove them because this would leave the group in an ownerless state.

The Microsoft 365 administrative portals don’t permit the removal of the last owner and insist that groups have at least one owner. It’s possible that groups get into an ownerless state if the account of the last owner is deleted. At that point, the groups ownership governance policy can attempt to find a new owner (if the tenant has Entra P1 licenses) or you can write a PowerShell script to look for a new owner.

Code to Remove Members from Microsoft 365 Groups

The logic for removing a group member is therefore:

• Use the Get-MgGroupOwner cmdlet to fetch the set of group owners and check the set to see if the member being deleted is a group owner.
• If yes, and the number of owners is one, exit.
• If yes, and more than one owner exists, run the Remove-MgGroupOwnerByRef cmdlet to remove the owner first and then run the Remove-MgGroupMemberByRef cmdlet to remove the member.

The usual approach for this kind of processing is to create a function, so here’s an example of a function that takes the user identifier, group identifier, and group display name as parameters (the latter is purely for output purposes) to process the removal of a user account from a Microsoft 365 group or security group:

function Remove-UserFromM365Group {
# Remove a user account from a Microsoft 365 group, checking if the user is an owner first. 
# If the user is an owner and they are not the last owner,
# the function removes the user from as both an owner and a member of the group.
    param (
        [Parameter(Mandatory = $true)]
        [string]$UserId,
        [Parameter(Mandatory = $true)]
        [string]$GroupId,
         [Parameter(Mandatory = $true)]
        [string]$GroupName
    )
    
    $Outcome = $null
    [array]$Owners = Get-MgGroupOwner -GroupId $GroupId | Select-Object -ExpandProperty Id
    if ($UserId -in $Owners) {
        if ($Owners.count -eq 1) {
            Write-Host ("The {0} group has only one owner - can't remove the last owner" -f $GroupDisplayName) -Foregroundcolor Red
            $Outcome = "Failed - can't remove the last owner of a group"
            return $Outcome
        }
        Write-Host ("User {0} is an owner of group {1} - removing both owner and member links" -f $TargetDisplayName, $GroupDisplayName) -ForegroundColor Yellow
        try {
            Remove-MgGroupOwnerByRef -DirectoryObjectId $UserId -GroupId $GroupId
        } catch {
            Write-Host ("Failed to remove user {0} as owner from group {1}: {2}" -f $TargetDisplayName, $GroupDisplayName, $_.Exception.Message) -ForegroundColor Red
            $Outcome = "Failed to remove owner"
            return $Outcome
        }
    }
    try {
        Remove-MgGroupMemberByRef -DirectoryObjectId $UserId -GroupId $GroupId
    } catch {
        Write-Host ("Failed to remove user {0} as member from group {1}: {2}" -f $TargetDisplayName, $GroupDisplayName, $_.Exception.Message) -ForegroundColor Red
        $Outcome = "Failed to remove member"
        return $Outcome
    }

    $Outcome = ("User {0} removed from group {1}" -f $SourceDisplayName, $GroupDIsplayName)
    return $Outcome
}

Better PowerShell developers than I could probably tidy the function, but the code works and demonstrates the principles behind removing members from a Microsoft 365 group (or security group), which is what I set out to do. I’ve updated the original script in GitHub, and you can download the complete code from the Office 365 for IT Pros repository.

Figure 1 shows how to run the script, specifying a source account, a target account, and a Boolean parameter controlling whether to remove the transferred memberships from the source account.

Removing Members from Groups Requires Knowledge

The question about removing group memberships is a great example of why it’s important to understand the technology and how Microsoft 365 really works before attempting to automate operations. Many blogs give partial answers. Without knowledge, you can’t fill in the gaps to create a complete answer, which is why we have the Office 365 for IT Pros eBook including the companion Automating Microsoft 365 PowerShell eBook.

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.

Older Files With Long Retention Periods Might Disappear Unexpectedly

Microsoft introduced retention policies and retention labels as part of its Office 365 Data Governance Framework in April 2017. These components are part of the Purview Data Lifecycle Management solution now. Capabilities have evolved a lot since 2017 in areas like special auto-label policies for “cloudy” attachments, disposition reviews, and the use of trainable classifiers, but the basics remain the same. Retention policies or retention labels track how old items are and when those items reach a threshold, a retention action happens. Often, the action is to delete the item.

Which brings me to a puzzling experience I had a few weeks ago when spreadsheets that I use to track various topics disappeared. The items that I noticed all came from my OneDrive for Business account, and when I checked there, I found the items in the first stage recycle bin. The question was what action moved the items into the recycle bin.

Old Retention Labels Might Have Simple Settings

The answer was simple. When Microsoft introduced retention labels and policies, I created a batch of labels and started to use them to manage content. At the time, things were simpler, and retention operated on creation date. Today, you can choose for retention to operate on the basis of the last modified date, which is the setting I use in more recently-created retention labels. Monitoring the last modified date is better because it means that files that remain in active use are not removed by retention processing, which is probably what you want.

The retention label applied to the disappeared files had a long retention period (Figure 1) but counted the retention period from the created date. It just so happened that all the files that ended up in the recycle bin were created in early 2015 and had therefore reached the end of the retention period. The next time Purview processed OneDrive, it duly noted the fact and took the retention action to move the files into the recycle bin.

Mystery Solved

The mystery of why my files suddenly disappeared from view was solved, but there’s a serious lesson to be learned here. It is quite likely that other Microsoft 365 tenants have retention policies or labels that operate on a “when created” rather than “last modified” basis. Checking the created date for files is very effective at clearing out old material but falls down when that material, although old, is still in active use.

The problem is that you can’t simply update a retention label to change its retention settings. You can change the retention period to increase or decrease the number of days for Purview to retain an item, but you cannot change “when created” to “last modified.” Increasing the retention period is a pragmatic way to solve the immediate problem, but it means that some files that should be removed will stay around for longer, and that’s a bad thing in an era when AI tools cheerfully consume even the oldest and most outdated information to generate responses.

A better long-term solution is to replace old retention labels with updated versions that use the last modified date. This article explains how to use the Get-MgDriveItemRetentionLabel cmdlet from the Microsoft Graph PowerShell SDK to read the retention label applied to files and the Update-MgDriveItemRetentionLabel to apply a replacement label (the same cmdlet can apply a default retention label to a folder). Another Practical365.com article looks at some of the business reasons why it might be necessary to replace retention labels on files, including a script to do the job.

Solving the Problem in Code

In my case, I took the script I wrote to report files stored in a OneDrive for Business account and ran it to identify what retention labels are applied to files in OneDrive. I then created a replacement retention label with the same retention period but with modified date as the test for retention. Finally, I copied the reporting script and modified the function that reads retention label data to look for the label (or labels) to replace and called the Update-MgDriveItemRetentionLabel cmdlet to assign the new label. You can download the script from the Office 365 for IT Pros GitHub repository.

Unfortunately, the gods of scripting (or APIs) intervened and the underlying Graph API developed a problem when updating labels. The same issue surfaced in the SharePoint PnP module. I’ve reported the problem and hope that Microsoft solve the issue soon. In the meantime, I updated the retention labels manually for several important files to make sure that Purview wouldn’t remove them. It’s disappointing that the script doesn’t work at present, but it will in the future.

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.

Better Use of Number Matching and a Refined First Run Experience

The developers of the Microsoft Authenticator app have certainly been busy recently. Following on their announcement that a September 2025 update will make backup and restore easier, we now have the news released in message center notification MC1117816 (18 July 2025) that an update around the same time to simplify the sign-in experience and improve onboarding for users.

Modified Number Matching

In 2022, Microsoft added number matching to the Microsoft Authenticator app to reduce “MFA fatigue,” a symptom that can happen when users are asked to approve a stream of multifactor authentication challenges and can do so with a simple click. If a user responds with a series of clicks (without too much thinking), it makes it easier for an attacker to slip a bad challenge into the stream. Displaying a number and asking the user to match the number from a set of choices forces the user to pay attention. If they don’t, they probably won’t satisfy the challenge. Number matching became generally available in May 2023.

Good as number matching is at seizing user attention, it can sometimes run into difficulties. The most obvious is when Authenticator responds to a sign-in request for an app running on the app. The notification that a response is necessary can appear over the sign-in screen, meaning that the user can’t see the number they need to enter to satisfy the response.

To solve the problem, Microsoft is replacing the number choice with a simple yes or no. The experience is seamless on Android because all apps will pick up the new mechanism. On iOS, users of the Single Sign On (SSO) plug-in will still need to switch to the Authenticator app to complete the sign-in, but number matching won’t be required.

Users signing in from another device will still use number matching to satisfy the multifactor authentication challenge.

I have not seen the change in action, but I am familiar with the issue that Microsoft is attempting to solve. Indeed, so many notifications can pop-up on a busy device that tracking down authentication requests can be challenging. Anything that’s done to smoothen the user experience will be welcome.

Improving the First-Run Experience (FRX)

Microsoft is also making changes to the initial setup of the Authenticator app to give Entra ID accounts priority over personal accounts. I think this makes sense. The more that can be done to make multifactor authentication seamless for Entra ID users, the better the chances of driving the adoption of multifactor authentication in Microsoft 365 tenants. Attackers still target vulnerable accounts with techniques like password sprays.

According to Microsoft, 99.9% of compromised Entra ID accounts don’t use multifactor authentication. That figure should be sobering enough for any tenant administrator to take immediate action to improve their security stance by insisting that all user accounts are protected with multifactor authentication.

And if the Microsoft Authenticator app is easier for people to use, the resistance to moving from more traditional methods of satisfying challenges, like SMS, will be reduced. Some nagging is likely still needed (here’s a script to help) to convince tenant users to adopt strong multifactor authentication methods, but anything to remove barriers is a good idea.

Microsoft also says that they plan to make the option to scan a QR code more obvious. Again, this is goodness because many sites use QR codes as part of the multifactor authentication enrolment process.

Not Big Changes

Neither of the changes described here are in the category of earthshattering updates. Instead, the changes refine how the Microsoft Authenticator app works to make it easier for the average person to use. That’s a good thing, and I look forward to seeing the changes appear in September 2025.

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!

Keep the Default Accent Color or Choose New One

I thought that life was complete when Teams delivered multiple emoji reactions for messages. Now I know I was mistaken because MC1115312 (14 July 2025, Microsoft 365 roadmap item Microsoft 365 roadmap item 497139) announces the arrival of customizable accent colors, which begin to roll out for Teams desktop and browser (but not mobile) clients in late July 2025. Worldwide deployment is scheduled to be complete by the end of August 2025.

I’m unsure of quite how many people have ever woken up saying how nice it would be if Teams supported a selectable accent color – or how many people understand the purpose of an accent color. Mozilla documentation explains that an accent color is a cascading style sheet (CSS) property that sets the color of certain user interface controls.

Selecting a Theme Accent Color

Given that the Teams UX is basically a big browser app, it doesn’t come as a surprise that a style sheet property is involved, but what does it do? Well, users can select a color from a set presented in the Appearance section of the Settings app (Figure 1). According to Microsoft, this is a “visual customization” of the Teams interface that “enhances the user experience.”

The ten colors in the set range from the default (a wishy-washy light blue) to Red to Teal to Pink to Grey. You can’t add extra colors, so Teams can’t comply with expensive corporate brandings that feature an exact shade defined in a Pantone code. There is no administrative control available to set an accent color for users or to disable the option to select an accent color. Choosing an accent color is a purely cosmetic change that is user-driven to reflect personal rather than corporate choice.

You might scoff about the need to respect corporate branding, but I remember a heated debate inside Digital Equipment Corporation when a new CEO decided to refresh the iconic logo with new colors. Cue a surprisingly vicious fight between people who liked different shades of burgundy…

How Teams Uses an Accent Color

When you select a new accent color, Teams uses that color for many different elements in its user interface. The best example I could come up with is from the new threaded layout for channels where the accent color is used to highlight the base topic for a thread. I chose Red as my account color, and you can see the effect in Figure 2. Other elements that use the color include the count of notifications at the top of the screen, hyperlinks, and the display names of conversation participants.

After selecting such a bold color, you can appreciate why the Teams developers chose a muted color as the default (the first color in the list of available accent colors). Figure 3 shows an even more garish appearance using a yellow accent. Of course, beauty is in the eye of the beholder, and you might consider this to be just the kind of thing you want to see when browsing conversations.

Teams uses the chosen accent color in both home and host tenants, so if you’re a guest member of teams in other tenants, your selected color shows up there too. However, the color choice is specific to a workstation, and if you use Teams on another device, you’ll get whatever color is selected there.

One oddity I noticed is that selecting a color in Teams affects the display of other applications. For example, this blog is hosted by WordPress, and the Jetpack stats view (of page views, etc.) changed its color when I selected a new color in Teams. This might just be coincidence, but that’s less likely when the same thing happens on two PCs.

Customization is Good

I don’t think anyone can argue that the provision of options to allow users to customize their working environment is a bad thing. However, sometimes I wonder why effort is expended on developments like selectable accent colors when so much else could be done to address other issues.

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

Six Months of an Extended Security Update Program from October 2025 to April 2026

Those who aren’t dedicated followers of the EHLO blog might have missed two interesting posts this week. The first covers delicensing resiliency for Exchange Online and the news that Microsoft is reducing the threshold for this feature to 5,000 tenant mailboxes. I think the feature should be available to all Exchange Online tenants, but let’s leave that debate aside.

Coping with the consequences of a mailbox becoming delicensed isn’t such an issue for Exchange on-premises organizations. They have their own challenge, notably the need to upgrade to Exchange Server Subscription Edition (SE) before Exchange 2016 and Exchange 2019 exit support on October 14, 2025.

Updating a Server to Exchange Server SE is Boringly Easy

The second EHLO post of the week offers a lifeline to organizations who don’t believe that they can deploy Exchange Server SE by the October 2025 deadline. Performing an in-place server upgrade to Exchange Server SE is the easiest Exchange upgrade an on-premises administrator is likely to ever know. It’s been described as “boring” because literally nothing happens apart from version numbers being updated and a few other minor tweaks. The fact that Exchange 2019 and SE share the same documentation for system requirements testifies to the closeness of the two products.

Microsoft designed the upgrade to the first iteration of Exchange Server SE to be boring to remove the barrier where administrators believe that an Exchange upgrade is a major event with many potential problems lurking under the surface waiting to make a server inoperative. Read the documentation, follow the steps laid down, and your update will proceed smoothly.

Factors Stopping Upgrades Happening

Although the server upgrade is easy, there’s usually some other factors that come into play that can slow deployment. Now is peak vacation period so people might not be available. The organization might decide to introduce new hardware or roll out Windows Server 2025. This might be especially so when the organization runs Exchange 2016 on an older version of Windows Server (here’s the operating systems matrix). In any case, lots of preliminary steps might need to be resolved before anyone sits down to update a server.

To help organizations that are struggling to get their ducks in a row to allow the deployment of Exchange Server SE to proceed, Microsoft is therefore introducing a six-month Extended Security Update program. The idea is simple: After August 1, 2025, customers can contact their Microsoft account team to request a subscription to a new product SKU that entitles them to receive security updates for Exchange 2016 and Exchange 2019 for six months. The price of the SKU is per-server, and it’s assumed that the Microsoft account team knows how many servers a customer operates so that they can calculate an initial price before any discounts are negotiated. If you don’t have a Microsoft account team, call the local Microsoft office and get them involved.

There are several important points to consider before proceeding to enrol in the Extended Security Program:

• The agreement only lasts six months and Microsoft doesn’t plan to extend it past April 14, 2026.
• During the agreement, Microsoft will deliver security updates for problems that the Microsoft Security Response Center deems to be critical or important. In other words, a security issue must meet a threshold before Microsoft will create a security update for Exchange 2016/2019.
• Security updates issued through the program will be released privately to program participants. You won’t be able to download the updates from the Microsoft download center.
• There’s no guarantee that any security problems will emerge between October 15, 2025, and April 14, 2026. In other words, this is insurance in case a problem happens, and no refunds are coming if the security landscape remains calm throughout the six-month program lifetime.
• Microsoft says that they will inform program participants if a security update is available on Patch Tuesdays during the covered period.
• The Extended Security Update Program does not affect the end-of-lifetime support dates for Exchange 2016 and Exchange 2019. Those dates remain as they are. This program only covers security issues.

Not a Revenue Generating Opportunity

Cynics will say that this is yet another example of Microsoft adjusting deadlines, this time to create an opportunity for a little extra revenue by charging customers for six months of security insurance. Pragmatists will recognize just how slow Exchange Server updates have been since Exchange 2000 appeared. Given the engineering costs involved, I doubt Microsoft will make much if anything from the Extended Security Update program. This is no more and no less than a lifeline for those who need that extra time.

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, which includes topics like Exchange Server SE that are important to hybrid Microsoft 365 deployments.

Delicensing Resiliency Protects Against Data Loss – Should Be Available to All

According to an EHLO July 15 post, Microsoft has decided to reduce the threshold for delicensing resiliency from the original level of 10,000 mailboxes announced in November 2024 to 5,000. In other words, the feature to protect against inadvertent data loss due to mailboxes becoming unlicensed is only available for tenants with more than 5,000 mailboxes.

I think the feature should be available to all Exchange Online tenants. Apart from some notional accounting savings accrued by removing unlicensed mailboxes from tenants without a 30-day grace period, Microsoft has no good justification for restricting delicensing resiliency to large tenants. Here’s why.

A Sticking Plaster for Group-Based Licensing

First, delicensing resiliency is a sticking plaster fix to a problem in Microsoft group-based licensing that can cause an account to end up in a situation where it has no license that includes an Exchange Online service plan. When this happens, Exchange Online detects the unlicensed state of the mailbox and disconnects the mailbox to make it inaccessible. The grace period granted through delicensing resiliency allows administrators the time to recognize and correct license allocation mistakes.

The problem was more evident before Exchange Online supported license stacking (the ability for an account to have several licenses with Exchange Online service plans). Stacking allows a mailbox to remain licensed even when an Exchange license is removed from an account. But group-based licensing can become complex when multiple groups are used to assign licenses, including dynamic groups. A change to someone’s membership of a group (or a change to a property that includes them in a dynamic membership) can result in license removal and hence a mailbox disconnection.

It would be better if Microsoft sorted out group-based licensing to remove the possibility of accounts becoming unlicensed. Perhaps the Microsoft 365 admin center, which took responsibility from Entra ID for the management UX for group-based licensing in 2024, could develop a “what if” feature to show administrators what will happen if a change is made to a group and warn against removal of access to critical apps like Teams and Exchange. And in the interim, Exchange Online could make delicensing resiliency available to all tenants.

OneDrive for Business is the Other Major User Personal Storage

It’s not as if such a step would be something new and dramatic. The default retention period for OneDrive for Business accounts belonging to deleted user accounts is 30 days, and that period can be extended to allow nominated individuals to check OneDrive to harvest essential business information. OneDrive and mailboxes are the two primary personal storage locations within Microsoft 365. A similar level of access to the two types of objects should be possible following license removal (often because of account deletion).

Use Retention to Make Unlicensed Mailboxes into Inactive Mailboxes

Another reason for extending delicensing resilience to all tenants is that “big” tenants usually can protect against inadvertent deletion by putting a retention or litigation hold (or holds) on mailboxes to ensure that Exchange Online puts deleted mailboxes into an inactive state. This is another good way to ensure that mailboxes remain available even if a deletion in error occurs. Inactive mailboxes are available to any size of tenant that can set retention holds and there’s no arbitrary number of mailboxes that must be met.

Delicensing resiliency is easier for tenants to use than inactive mailboxes are because the mailboxes remain online and connected. Inactive mailboxes need to be reconnected through administrator intervention. That might have an advantage because the administrator might then understand that a problem exists in how the tenant manages licenses.

All We Need is Simplicity and Consistency

Although there is goodness in building features that protect against data loss, it would be even better if Microsoft was consistent in its policies and practices for controlling user data across the entire Microsoft 365 suite. We’re 14 years into the Office 365 era and while great progress has been made in some area to achieve consistency across workloads, gaps still exist. Blaming the roots of on-premises products is not acceptable any longer. Joined-up thinking is needed, and that doesn’t appear to be the case here.

In the interim, if your tenant has more than 5,000 mailboxes, update your organization configuration to enable Delicensing Resliency using the following command:

Set-OrganizationConfig -DelayedDelicensingEnabled:$true

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!

Copilot Studio Agent Sends Salesforce Customer Data to Attacker

The July 7 report (“A Copilot Studio Story 2: When AIjacking Leads to Full Data Exfiltration“) from Zenity Labs is sobering reading for anyone considering how to introduce Copilot agents within a Microsoft 365 tenant. In a nutshell, Zenity created a replica of a “flagship example” of an agent created using Copilot Studio built by McKinsey & Co and proved that a an email containing a prompt injection sent to the agent could result in the generation of an emailed response containing customer data sent back to an attacker.

I have an instinctive suspicious of reports issued by security researchers because there are too many examples of overhyped text designed purely to enhance the credentials of the company. In this instance, the Microsoft Security Response Center took the issue seriously, so we should too.

The Problem is Still There

We’ve been down this path before with Copilot because researchers reported how they had compromised BizChat at sessions at the Black Hat USA conference in 2024. Copilot agents didn’t exist at the time, but the same method of sending a message for Copilot to process that convinced Copilot to do bad things was used.

Zenity reported the exploit described in the article to Microsoft, who fixed the problem in late April 2025, most likely through the deployment of a “prompt shielding mechanism.” The net result is that attackers cannot use the same avenue to exfiltrate large quantities of data. However, the kicker is that the fix works for the attack as described, but as Zenity says “Unfortunately because of the natural language nature of prompt injections blocking them using classifiers or any kind of blacklisting isn’t enough.” In other words, attackers can find new ways to use natural language prompts to convince agents to do silly things.

The Stupidity of Agents

The problem is, despite all the hype around artificial intelligence, Copilot agents are essentially stupid. They cannot distinguish between good and bad users, nor can they decide that an action demanded of them is wrong or inappropriate. As we head into an era where agents can talk to agents, the need for increased oversight about what agents do and how they do it is all too apparent.

Managing agent objects in Entra ID is a good way to incorporate agents within the infrastructure, but that doesn’t do anything to reveal what agents do in response to different user prompts, including prompts deliberately intended to do harm. You could pour over the details of Copilot interactions captured by the aiInteractionHistory API or the compliance records captured in user mailboxes by the Microsoft 365 substrate searching for evidence of attacker intervention, but what would you look for? Searching for the one API record where 500 Salesforce customer records are sent to an address in Russia might be the equivalent of seeking the proverbial needle in a haystack.

Although ISVs can work on the problem of agent governance, it’s obvious that ISVs can only work with agents using the APIs and data made available by Microsoft. Dealing with prompt injections is something that will remain a Microsoft competence.

As AI tools become more embedded into our work, the more attackers will be interested in seeking gaps. The battle between Microsoft and the bad guys to protect Copilot (apps and agents) is likely to be a ping-pong contest of exploit followed by remediation

The Goodness of Copilot Studio Agents

Don’t get me wrong. I like the ease of use that Copilot Studio brings to the agent creation process. Even an old duffer like me can create and publish an agent from Copilot Studio (Figure 1). We’re simply at the point in the evolution of AI tooling where security, governance, and management struggle to keep up with the pace of innovation and overhyped expectations.

It would be an overreaction to block users from being able to develop agents with Copilot Studio. Some controls are necessary and restricting those who develop agents to a limited group with oversight before publication seems like a reasonable step. I’m sure that more comprehensive development methodologies and structures will emerge over time and will be discussed on the web and at conferences. I’m looking forward to hearing what the experts say at the TEC event in Minneapolis at the end of September. Come along and join the debate!

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

Copilot Search Delivers Even More Intelligence?

Prior to Microsoft’s Copilot launch in March 2023, search was simple. Google dominated and had educated people into performing keyword-based searches to find information. Today, the situation isn’t quite so straightforward. AI-generated executive summaries are the norm for Google and other search engines. Keyword-based searching is very different now.

Copilot came with promise of radically better search. I think Microsoft 365 Copilot has lived up to this promise, but only for Graph-based searches for documents, messages, and email, Web-based searches depend on Bing, and that dependency makes web results less than spectacularly wonderful. Some thought that semantic search would make a big difference, but given that Copilot functions without semantic search, its influence is marginal at best.

Copilot Search Mark 2

Microsoft has a reputation for getting things right on the second or third attempt, which brings us to the launch of Microsoft 365 Copilot search, “a new AI-powered, enterprise-grade search experience” for tenants with Microsoft 365 Copilot licenses. The technology is described in message center notification MC1108844 (3 July 2025, Microsoft 365 roadmap item 490778). The new search is available in targeted release tenants now and is scheduled for general availability starting in mid-July 2025.

According to Microsoft, “Copilot Search leverages Microsoft Graph and Microsoft 365 Copilot connectors to index content across Microsoft 365 and third-party apps. It interprets user context, natural language, behavioral signals, and organizational relationships to deliver highly personalized, context-aware answers to complex queries.” That’s quite a mouthful. After using the new search for several days, it reminds me of the Microsoft Search in Bing feature (retired in March 2025) with a hint of Delve, all wrapped up with BizChat. Microsoft says that the integration with BizChat enables users to move seamlessly from search to task execution.

Copilot Search in Action

After reading the documentation, I headed to the Microsoft 365 Copilot app and selected the Search option, making sure that the option to use the new search was selected. I’ve written extensively about Entra ID license management, so proceeded to see what Copilot Search could find. Figure 1 shows the results. Instead of a simple list of results with the ability to filter by type (files, sites, people, messages, and so on), Copilot Search presents what Microsoft considers to be a more intelligent view, including an extract from the Copilot chat response to the question posed in the search. The full chat response is available by clicking the Continue reading button. In essence, you then participate in a full-blown conversation with Copilot.

The Modified drop-down offers filters for the past 24 hours, past week, past month, and past year. Under Results, you can refine the results based on items found in SharePoint Online, the web (other sites), Outlook mail, and Teams messages (not shown in Figure 1). Loop workspaces and pages are also scanned by search and are included in SharePoint results rather than having their own type.

The web results are generated from Bing, so the normal caveat applies to the accuracy and usefulness of Bing. Microsoft documentation is heavily favored by Bing, so it’s of no surprise that the top two results listed come from that source. Better results are generated if you include a target website address to search. For example, “What Practical365.com articles cover the topic of Entra ID license management”

Like BizChat, the DLP policy for Copilot stops Office documents and PDF files assigned specific sensitivity labels turning up in search results.

Pity About Bing, but Copilot Search Excels with Graph Searches

Like any search, the new Copilot search takes some getting used to before it becomes an effective and efficient tool in user hands. The dependency on Bing weakens the ability of Copilot search to beat Google or other search engines, but the ability to find items in Graph-grounded searches is unmatched. That, and the smooth integration with BizChat and the ability to save output in Copilot pages will likely please people enough to drive usage.

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

New Version Released on July 9

On July 9, 2025, Microsoft released V2.29 of the Microsoft Graph PowerShell SDK to the PowerShell Gallery (Figure 1). The release notes are available but don’t really throw much light into what’s been updated and the set of issues registered in GitHub for the SDK hasn’t gone down, so it’s hard to know exactly what changes Microsoft has made in V2.29. The only way to check is to install V2.29 and run some cmdlets, which is what I did. I used the script described in this article to refresh my PC and picked up recent updates for SharePoint Online and Teams along with the SDK.

Update (July 17): Microsoft has fixed a problem in the SDK and the current version is now 2.29.1. Microsoft hasn’t said what they fixed.

Azure AD PowerShell Finally Going Away

Microsoft recently set the final (no, it won’t be shifted again) retirement date for the Azure AD and Azure AD Preview modules. The underlying infrastructure powering these modules will be turned off in mid-October 2025. It’s not like the slow withdrawal of the MSOL module where some cmdlets (license management) stopped working and others limped on until the module’s retirement in March 2025. Once the shutters come down in mid-October, the Azure AD cmdlets stop working and scripts fail. It’s time to migrate code to use the Microsoft Graph PowerShell SDK, or if you insist, the Entra module (which is based on the SDK).

Testing Microsoft Graph PowerShell SDK V2.29

Migrating to an unstable platform is a bad idea, and the sad fact about the Microsoft Graph PowerShell SDK is that some recent versions have been unmitigated disasters. Released in May, V2.28 of the SDK fixed many problems. The good news is that the suite of commands that I use to test new SDK versions uncovered no problems in dealing with users, groups, sites, mailboxes, and other objects. The new version seems to be as stable as V2.28.

Given the size of the SDK and the number of cmdlets (44,555 spread across the V1.0 and beta modules according to the Get-Command cmdlet), there’s no way that the tests I do will reveal every potential problem in an SDK release. All I can say is that the code in the scripts that I use for testing work without a problem. You can download many of the scripts that I test with from the Office 365 for IT Pros GitHub repository.

Before committing to upgrading a production environment to V2.29, I suggest that you update a couple of workstations and test scripts there. If everything checks out, you can then proceed with a tenant-wide rollout.

Azure Automation Blues

When Microsoft released V2.28 of the SDK, they acknowledged a problem with PowerShell V7.2/V7.1 runtime support in Azure Automation. In a nutshell, it all comes down to the version of .NET supported by the SDK. Microsoft said that the problem would be resolved when Azure Automation supported the V7.4 PowerShell runtime. At the time, support was supposed to appear around June 15. That date was missed. According to the What’s New page for Azure Automation, PowerShell 7.4 is now supported – but the update hasn’t appeared in my tenant. When I checked today, only Azure Automation runbooks configured for the V5.1 runtime worked. V7.1 and V7.2 runbooks barf with an “Invalid JWT access token” error caused because the Connect-MgGraph cmdlet cannot run to authenticate the session.

Until you hear differently, my recommendation is to stay with PowerShell V5.1 for your Azure Automation runbooks. Microsoft will eventually get all of the pieces that it owns and maintains into alignment. It’s just sad when obvious gaps appear between important Microsoft 365 automation components.

Still Positive

Despite the recent issues with the Microsoft Graph PowerShell SDK, I’m still very positive about the SDK. Sure, there’s a learning curve to master when coming from more traditional modules like Azure AD. Yes, the issues are maddening and Microsoft’s seeming inability to drive quality in an essential component is infuriating. But despite all that, the SDK allows you to get behind the scenes of Microsoft 365 in a PowerShell-friendly manner, and that’s what really counts.

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.

Authenticator Embraces a New Method for Account Backup and Restore

My article about adding QR codes to the Microsoft Authenticator app for Entra ID guest accounts is one of the more popular on the Office365itpros.com site. Given the increasing use of multifactor authentication to protect Microsoft 365 accounts and the need for stronger authentication methods to replace insecure SMS-based challenges, it’s unsurprising that the Authenticator app is a popular choice. The app is easy to use and it’s a strong authentication method, so many boxes are ticked.

Where the Authenticator app falls down is when a user gets a new phone, either by choice or through necessity. The gloss of buying a brand-new iPhone is diminished by the pain of reconfiguring the authenticator app to regain access to accounts. Microsoft wants to remove that pain with a “more seamless and secure backup and restore experience using iCloud and iCloud Keychain.”

The change is reported in message center notification MC1111780 (8 July 2025) and will be delivered in an app update that’s expected to roll out in September 2025 with full worldwide deployment scheduled to complete in October 2025. Tenant administrators cannot affect the progress of the roll out, and the change is effective after the installation of the updated app on an iOS device (the Authenticator app also supports iPad devices).

Eliminating the Need for a Microsoft Personal Account

Today, the Authenticator app needs a Microsoft personal account (Figure 1) to backup account names and third-party time-based one-time password (TOTP) credentials used by sites like GitHub and Twitter (the site issues a challenge that is satisfied by a six-digit number generated by the Authenticator app).

Instead of using a Microsoft account for backup and recovery, Authenticator will use the iCloud keychain. Setup of new devices is therefore performed completely within the iOS ecosystem, so it’s smoother and less prone to error. Users don’t have to do anything to benefit from the update. It is enabled automatically if the device runs iOS 16.0 or later and the user’s iOS account enables iCloud and iCloud keychain. It’s likely that relatively few iOS users don’t have these components enabled. Apple is very successful at convincing iOS users to move to new versions of the operating system, so the iOS 16.0 requirement is unlikely to be an issue either, especially in corporate environments.

After the update, Authenticator backs up all account names and third-party TOTP credentials using the iCloud keychain. Nothing else is backed up, specifically Entra ID credentials are not stored, so after moving to a new iOS device, users must sign into their accounts to complete setup.

A Need for User Communication

During the period between now and September 2025, Microsoft will flag the upcoming change with messages in the Authenticator app to inform users about a “new way to backup your account” on its main screen. The settings screen will have a message about replacing the existing iCloud backup mechanism with an enhanced version. It’s possible that users will generate some help desk calls when they read these messages, so organizations should consider some proactive communications to explain what’s happening in non-technical, practical terms.

Finding iOS Devices That Might be Affected

With an eye on communications, the need exists to identify the users of iOS devices that might use the Authenticator app. One of the advantages of having a large repository of PowerShell scripts is the availability of code that can be repurposed. The trick is to figure out what bits to use.

After thinking about it, I decided to reuse some code to report user-preferred authentication methods to find users who’ve opted to use push-based methods. The devices in use can be Android or iOS, so it’s necessary to refine the set to select those who use iOS. The Get-MobileDevice and Get-MobileDevice Statistics cmdlets reveal the operating system used by devices that synchronize with Exchange Online with apps like Outlook for iOS. By checking the devices used by the folks who’ve signed up for push-based methods, we can find and report the people who are actively using iOS. You can download the script from the Office 365 for IT Pros repository. Some sample output is shown below.

Users of iOS devices that are actively in use
---------------------------------------------

User         UPN                                DeviceOS
----         ---                                --------
Jeff Guillet Jeff.Guillet@office365itpros.com   iOS 18.5 22F76
John James   John.James@office365itpros.com     iOS 18.5 22F76
Tony Redmond Tony.Redmond@office365itpros.com   iOS 18.5 22F76

This is a good example of using different sources of Microsoft 365 data to answer a question. Of course, you must know about the sources available to you, but that comes with experience.

Looking Forward to the Upgraded Authenticator App

I’m looking forward to the upgraded Authenticator app. My iPhone 14 is showing signs of age and it’s time to consider moving to a new iOS device (I’ve never used Android). If Microsoft’s promise is correct, the transition should be easier than ever before, and that’s a worthwhile change.

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365. Only humans contribute to our work!

Mail-Enabled Security Groups with Full Access to Shared Mailboxes Makes Access to Protected Messages Easier to Control

Microsoft Purview Message Encryption (previously Office 365 message encryption) or OME allows users to apply two pre-defined rights management-based templates called Do Not Forward and Encrypt Only to protect email. Messages sent to other Microsoft 365 tenants can be read inline by Outlook clients while recipients of messages sent to other email services can read the protected content through the OME portal. Protection extends to email attachments.

Unlike the sensitivity labels created for tenants, administrators cannot edit the settings of the OME templates. The same settings apply in all tenants where OME is configured. For instance, when Outlook clients open messages protected by the Do Not Forward template, the clients disable the Forward, Save As, and Print options and don’t allow the recipient to change the recipient list for a reply.

Improving Access to Protected Messages Delivered to Shared Mailboxes

Shared mailboxes are an important part of the Exchange Online messaging landscape. Since the introduction of Azure Information Protection in 2016, Microsoft has steadily improved the ability of users with access to shared mailboxes to process protected messages. A recent important enhancement is described in message center notification MC794814 (21 May 2024, Microsoft 365 roadmap item 385345), which reports that members of a mail-enabled security group with access to a shared mailbox can read and respond to protected messages.

The caveat is that members of the mail-enabled security group can only read protected messages generated after Microsoft deploys the feature to a tenant. Rollout completed in September 2024, so that shouldn’t be a problem now. Older protected email cannot be read because the “protected wrapper” around those messages doesn’t support access via a mail-enabled security group.

Figure 1 shows a message protected with the Do Not Forward template being read in Outlook (classic). In this case, my account is a member of a mail-enabled security group granted Full Access permission for the Complaints mailbox.

No Need for Direct User Assignment

The important point here is that direct user assignment to the shared mailbox with automapping enabled is no longer required. Direct assignment means that an administrator grants Full Access permission for the shared mailbox to a user account. Automapping is a process where Exchange Online adds a shared mailbox to a profile so that the Outlook (classic) client automatically opens the shared mailbox. This method still works, but now you have the option to use a mail-enabled security group to control shared mailbox membership instead.

Although the mail-enabled security group method works very nicely to allow users to open and read protected messages, remember that separate delegation is required to allow people to send email from the shared mailbox. This can be a Send As or Send on Behalf Of permission.

Why mention a feature launched last year when every Microsoft 365 tenant struggles to manage the ongoing flood of new product feature announcements? Well, the new method seems to have passed people by, so I thought it would be good to highlight it and give the mail-enabled security group approach a little boost. In addition, although MC794814 focused on the Do Not Forward and Encrypt Only templates, it seems like users granted access to a shared mailbox via a mail-enabled security group can read email protected by sensitivity labels too, if the rights assigned in those labels allow access.

Support in OWA and the New Outlook

OWA and the New Outlook are usually faster at deploying enhancements for protected messages. These clients work online and fetch the necessary authorization (use licenses) as required. Outlook (classic) can work offline, so getting the use licenses is more complicated.

OWA and the New Outlook also support the ability to work with protected messages when access is granted via a mail-enabled security group. Figure 2 shows OWA being used to read a protected message in a shared mailbox.

Microsoft Purview message encryption is available to all tenants with Office 365 E3 licenses and above. The Do Not Forward and Encrypt Only templates are very useful and the number of tenants using sensitivity labels grows all the time. Easier access to protected messages in shared mailboxes is welcome, even if it’s taken me far too long to acknowledge the update.

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.

How to Copy Group Membership from One User Account to Another Account

Now that Microsoft has confirmed the final retirement of the Azure AD module in mid-October 2025, the pressure is on to find and update scripts used for operational purposes. The time for learning how to use the Microsoft Graph APIs is past. The focus is now on turning knowledge into Graph-powered scripts.

Which brings me to a question about how to copy group membership from one user account to another. It’s the kind of thing that features in many online forums. In this example, the answer is:

Get-AzureADUserMembership -ObjectId {source user object id}|foreach { Add-AzureADGroupMember -ObjectId $_.ObjectId -RefObjectId {new user object id} }

Another example of the art is found here. The point is that copying group membership from one account to another is clearly something that many people do. I can see why this might be so. For instance, you might want to copy group membership from an account to a new joiner’s account to include them in a bunch of teams.

Alas, the Graph is different to Azure AD, and converting a script to perform the task with the cmdlets from the Microsoft Graph PowerShell SDK is not straightforward. Here’s a few things to think about when dealing with Entra ID groups. The set includes Microsoft 365 groups, security groups, mail-enabled security groups, and distribution lists.

Copying All Group Memberships or Just Some

It seems sensible to make someone a member of work-related groups based on the memberships of another user, but what about groups that are not work-related or don’t align with a specific job or operating unit? The groups used by many teams and Viva Engage (Yammer) communities accommodate discussions about topics that are not strictly associated with the business of an organization, and membership of those groups are determined by an individual’s interest rather than what they do.

Marking Work-Related Groups

Sensitivity labels are the obvious answer to mark work-related groups, but that only works if a tenant uses sensitivity labels for container management and assigns specific labels for groups that are not work-related. Sensitivity labels have become more popular over the last few years, but they are only available to tenants with Office 365 E3 or above licenses. A custom attribute could be used, but that requires the organization to ensure that all groups used for work or non-work topics are clearly marked.

Handling Dynamic Entra ID Groups

Dynamic Entra ID groups use membership rules based on account properties to calculate group membership. It’s very possible to extract the membership rule for a dynamic Entra ID group and figure out what properties to update to add someone to the membership of a dynamic group, but the risk exists that such an update might interfere with the membership rules of other dynamic groups.

Exchange Distribution Lists

Exchange distribution lists are replicated from Exchange to Entra ID, meaning that when a cmdlet runs to find Entra ID groups, the set returned includes distribution lists. Mail-enabled security groups are a form of distribution list. If you want to copy the membership of mail-enabled security groups and regular distribution lists, you’ll need to do this with Exchange Online cmdlets instead of Microsoft Graph PowerShell SDK cmdlets.

Dynamic distribution lists are not replicated from Exchange Online to Entra ID, so the Graph PowerShell SDK cmdlets ignore these objects. If you want to copy membership to dynamic distribution lists, you’ll need to update mailbox properties to match the OPATH queries used by dynamic distribution lists.

Selecting the Right Cmdlet to Copy Group Membership

The Microsoft Graph PowerShell SDK has two cmdlets to fetch memberships held by a user. The Get-MgUserMemberGroup cmdlet performs a transitive lookup to return a set of identifiers for the groups that an account belongs to. The SecurityEnabledOnly switch parameter determines if the cmdlet returns only security-enabled groups or all groups:

[array]$Groups = Get-MgUserMemberGroup -UserId $User.Id -SecurityEnabledOnly:$false

The Get-MgUserMemberOf cmdlet returns groups, administrative roles, and administrative units (including dynamic administrative units) that a user is a member of. In other words, the objects fetched by the cmdlet must be filtered to extract the objects of interest. This command shows how to apply a client-side filter to find groups that don’t use dynamic membership:

[array]$Groups = Get-MgUserMemberOf -UserId $User.Id -All -PageSize 500 | `
    Where-Object {
        ($_.additionalProperties.'@odata.type' -eq '#microsoft.graph.group') -and
        (
            -not ($_.additionalProperties.groupTypes -contains "DynamicMembership")
        )
    } | Select-Object -ExpandProperty Id
If ($null -eq $SourceGroups) {
    Write-Host "No groups found for user $($SourceUser.DisplayName)." -ForegroundColor Yellow
    Break
}

The Get-MgUserMemberOf cmdlet is often preferable because it returns more than a simple list of group identifiers. As you can see from the example above, because the cmdlet deals with different object types, the additionalProperties property contains data that is of value to find specific groups.

An Example Script

A working example is usually helpful to demonstrate how to put principles into action. I’ve written a script that’s downloadable from GitHub to show how to fetch the set of groups from one account and copy the membership to another. The script (Figure 1) includes code to handle the different types of Entra ID groups and to check that it only attempts to add groups that a user isn’t already a member of. It’s enough to serve as the basis for a solution that might meet the needs of your tenant. I’ll let you make the decision about enhancements, such as removing the membership of the source user as groups are processed.

If you need more help to convert old Azure AD scripts, why not invest in a copy of the Automating Microsoft 365 with PowerShell eBook? It includes a bunch of useful examples like those above. The book is available separately or as part of the Office 365 for IT Pros eBook bundle.

Create Audio Overviews for Word and PDF Files and Teams Transcripts

Message center notifications MC1061100 (updated 2 July 2025) and MC1060872 (updated 3 July 2025) both focus on audio overviews generated from documents (Word and PDFs) and Teams meetings (transcripts) stored in OneDrive for Business and Copilot Notebooks. This is yet another example of Microsoft applying AI to Microsoft 365 information. The question is whether having an audio review of a file is of real value or a demonstration of technology that might be used once and then forgotten.

This feature requires a Microsoft 365 Copilot license.

Generating an Audio Overview

The implementation is simple. The Copilot menu for a supported file type in the OneDrive for Business browser interface includes the Create an audio overview option (Figure 1).

Selecting the option causes Copilot to process the file. Logically, it seems like Copilot summarizes the file into a format similar to a Teams transcript and uploads the output to the Azure Audio Stack for transformation into an audio stream (users can save the summary as an .MP3 file in the Recordings folder of their OneDrive for Business account). For now, only English language audio overviews are available, and only files in English can be processed. Copilot politely refused to process documents that contained non-English text, even when the majority of the text was in English. On the other hand, Copilot had no problem processing files containing computer code, such as the PowerShell examples.

Given that Copilot can generate document summaries in different languages and the support for many languages in the Azure Audio Stack, it seems likely that support for other languages will come soon. I also expect to see UX provided to allow users to select other settings, such as the voices used for output (see below).

MC1060872 says that the OneDrive mobile app can generate audio overviews. I haven’t seen the mobile option appear yet.

Audio Overview Styles

The default style summarizes the key points in a document. If you prefer, you can switch the overview to a podcast style using the option in the […] menu. Essentially, the summary is a report of a document read by a single person. The podcast style usually generates a shorter audio stream that’s delivered by two “hosts” (a male voice and a female voice, both with neutral American accents). Figure 2 shows an overview being played with the transcript visible together with the option to switch style.

The audio overview option advises that generation could take a few minutes. I discovered that this is accurate and that overviews for even very large files were available in a couple of minutes. For example, I asked Copilot to generate an audio overview of the Word document for the latest Office 365 for IT Pros eBook. This is a large and complex file (28 MB, 1,250 pages, 22 chapters, and many figures and tables), so I thought it would be a good test. The audio overview was available in less than two minutes. You can download and listen to the summary and podcast versions using the links below to get an idea about the quality and type of output generated for an audio overview.

The DLP Block for Microsoft 365 Copilot

Interestingly, the DLP policy for Microsoft 365 Copilot blocks Copilot from generating audio overviews. I shouldn’t be surprised at this because the idea behind the policy is to stop Copilot from processing confidential files assigned specific sensitivity labels. As noted above, Copilot generates an audio overview using a transcript summary produced from a file. To create the summary, Copilot must be able to extract the file content but is blocked by the DLP policy.

When asked to create an audio overview from a protected file that comes within the scope of the DLP policy, Copilot chews on the problem for a few minutes before concluding that it can’t do anything and errors out (Figure 3). OneDrive must be refreshed before further files can be processed.

Although it’s good that the DLP policy for Microsoft 365 Copilot does its job, the poor user experience in the OneDrive for Business browser interface is evidence that the folks who created the audio overview option never considered that a policy might block Copilot access to a file. It would be much better if the UX displayed an immediate error message to say that Copilot cannot process a file instead of making the user wait for a few minutes before Copilot times out.

Are Audio Overviews Valuable?

I might not be the right target market for audio overviews. I suspect that this feature is directed towards people who can’t use regular Copilot document summaries. In this context, I think audio overviews will be very useful. Another scenario where the feature might shine is the ability to save audio overviews of files to OneDrive for listening to during commutes or other journeys. Like all the AI-driven features, the value comes down to the individual. I’m not sure I will ever use a Copilot-generated audio overview again, but I know how to create one if I need it.

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.

July 1 Announcement of Exchange Server SE Launches the Subscription Era for Exchange Server

Right on schedule, July 1 saw the Exchange engineering team celebrating Microsoft’s new fiscal year by announcing the general availability of Exchange Server Subscription Edition (SE). I’m always suspicious about announcements just made at the end or start of a fiscal year because updates can be timed to satisfy artificial deadlines set by executives (to justify their bonuses). I don’t think that applies in this case because Exchange Server SE is a lightly rebranded version of Exchange 2019. At least, that’s what you might conclude by reading the slim list of changes (like a version number update).

Mentioning the Release to Manufacturing (RTM) build brought back memories of waiting for physical media containing a new release of Exchange Server, going right back to 1994 and the initial builds of “Touchdown” made available to customers. It was a charming look back into the past. Now we simply head online to grab the latest bits (Figure 1) and read the deployment instructions.

Moving to Evergreen Support

The big change is the move away from Exchange development based on three-year cycles (extended to six for Exchange 2019) to “evergreen” development. In some respects, the quarterly cumulative updates for Exchange Server showed the way forward in terms of keeping software refreshed. However, Exchange Server still followed the traditional support model based on versions whereas Exchange Server SE remains supported if customers keep the software refreshed with updates released by Microsoft.

Nine months ago, Microsoft flagged the end of support for Exchange 2016 and Exchange 2019 on October 14, 2025. After this date, Microsoft will no longer provide technical support for problems (aka bugs). The writing is on the wall: to continue in a supported state, customers must adopt Exchange Server SE or move to Exchange Online. Obviously, we’re now deep into the prime vacation period and thoughts might be more focused on suntan lotion than server upgrades, but this is an issue that cannot be overlooked, especially in hybrid environments where Microsoft requires on-premises servers that host connectors to Exchange Online to remain supported.

Email Bombs Away

If you don’t read the Microsoft Defender for Office 365 blog, you might have missed the update about protection against “email bombs.” Essentially, an email bomb is a form of attack against a mailbox where a large volume of messages (the bomb) hit a mailbox. The messages often originate from legitimate sources such as newsletters, but the target user never signed up receive the messages. Given the large quotas assigned to Exchange Online mailboxes, it’s unlikely that an email bomb will cause the mailbox to exceed quota, but the arrival of large numbers of unwanted and unexpected messages is certainly a distraction. And when someone’s distracted, they might make bad decisions, such as accepting help from an attacker who poses as a support representative.

In any case, an update to Microsoft Defender for Office 365 can monitor for the characteristics of email bombs, such as a sudden significant spike in the number of messages received by a mailbox. The spike is detected by comparison against the historical pattern of email traffic observed for the mailbox together with spam signals. When an attack is detected, Defender redirects the problem messages into the mailbox’s Junk Email folder. Microsoft says that they have blocked between 20K and 30K email bombs daily since the initial deployment of the technology in early May 2025.

Microsoft Defender for Office 365 includes a lot of useful protection against different types of email threat. For more details, including licensing, see the service description.

Ongoing Updates

Email security is never a static topic. Whether you’re upgrading on-premises servers to the latest version of Exchange Server to harden servers against external attack or deploying new software to detect and deflect attacks, this is an area we need continuous focus on. The joys of staying up-to-date!

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

Export to PST with the New Outlook for Windows is Slow and Maybe Shouldn’t be Allowed

Giving the New Outlook for Windows (Monarch) client the ability to deal with PST files has long been one of the biggest demands from people who don’t want to move from Outlook (classic). Microsoft delivered code to support import access for PST files a few months ago. Now code to export mailbox items from the New Outlook to a PST file is available in targeted release tenants (message center notification MC1104309, 26 June 2025, Microsoft 365 roadmap item 485737). General availability is scheduled for mid-July 2025. GCC tenants receive the update about a month later.

The Dire Slowness of Export to PST

Before we all get too excited, let me report that exporting mailbox items from the New Outlook to a PST is a slow operation. It took Outlook 27 minutes to export 4,829 items from my Sent Items folder to a PST. The eventual PST ended up as a 1.01 GB file. Your mileage might vary depending on network speed, current demand on the service, and PC configuration, but I doubt that the overall result will be much different. By comparison, exporting the same folder from Outlook (classic) took less than two minutes.

The reason for the slowness is simple. The New Outlook needs to do a lot of work to extract each item from the source mailbox and convert it to the format used by PSTs. It’s not like Outlook (classic), where PST support has been incorporated into the client since day zero and the client and PST use the same MAPI-based underpinnings.

PST and OST files are very close in structure and format. Outlook (classic) uses OST files for offline synchronized copies of mailbox folders and items. The New Outlook takes a completely different approach to offline access, and the differences in approaches contribute to export slowness.

But don’t worry, Microsoft has an option coming to schedule a mailbox export (Microsoft 365 roadmap item 485743) that should remove the pain of watching the New Outlook slowly export items from mailbox to a target PST (Figure 1). The scheduled export option is due to arrive any day now and should help.

Export to PST Limited to a Mailbox or Single Folder

The new Outlook supports the export of a complete mailbox or a selected folder (Figure 2) for any of the mailboxes configured in the Outlook profile. I’m a tad baffled by the design decision to limit export to these options. Exporting an entire mailbox is fine, but why allow the choice of just one folder?

It would make more sense to allow the selection of multiple folders. In Figure 1, the Inbox folder is selected, but I might want to include the Calendar, Sent Items, and other folders in the target PST. Apart from mimicking the process used by Outlook (classic), there doesn’t seem to be much reason to restrict an export to one selected folder.

Do You Want People to Use Export to PST?

The big question remains do you (or rather, the organization) want to allow Outlook users to be able to export items to a PST. It depends on the compliance and governance strategy for the tenant. If you want everything stored in Microsoft 365 to allow Purview solutions like eDiscovery or AI solutions like Microsoft 365 Copilot to be able to find everything, then it seems like allowing people to export items is a bad idea. All you’re doing is giving people an invitation to move messages out of sight. Users might want to export their mailbox, especially when they’re about to take up a new job in a different company, but that’s no reason to allow mailbox exports to happen.

Even with a strict compliance regime in force, there will be situations when PST exports are justified, such as providing copies of items to external experts for review. However, that’s still not a reason to permit mailbox exports across the board.

Fortunately, blocking access to PSTs is easy and quickly accomplished with an update to OWA mailbox policies. Figure 3 shows the result. New Outlook can’t open a previously-added PST and the Export option has disappeared. I like it this way…

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.

MCP Server for Microsoft Learn Delivers Real-Time Access to Microsoft Documentation

Technologists love new technology, even if new technology often disappoints or doesn’t live up to over-hyped expectations. This fact of IT life has been true for as long as I can remember and has applied to mainframes, minicomputers, PCs, and the cloud.

I was reminded about the truth that technology can disappoint when I saw the reactions of many to the news that Microsoft has a Model Context Protocol (MCP) server to allow real-time access by agents to Microsoft documentation (essentially, the contents of the learn.microsoft.com website). The server is currently in public preview.

Most of the reactions I saw were of the “gee-whiz, what a great thing” variety, probably based on the expectation of what an agent might do with Microsoft documentation rather than any experience of the MCP server in action. It will take time before people figure out how to take advantage of Microsoft documentation (question to self, what is the meaning of “official” documentation?).

Using the MCP Server with GitHub Copilot

In any case, it’s easy to add the MCP server to Visual Studio Code, which is what I use to write PowerShell code. The documentation includes a one-click installation which wasn’t quite a one-click activity but worked in the end. When the MCP server for Microsoft Learn is installed, GitHub Copilot can use it as a tool to help answer user prompts. As it happens, I’ve been reviewing some text for the Automating Microsoft 365 with PowerShell eBook and asked GitHub Copilot for some help. Figure 1 shows the response.

At first glance, the response looks perfectly reasonable. The only trouble is that it’s wrong. The cmdlets cited in the answer don’t exist and haven’t existed since the Microsoft Graph PowerShell SDK divided its single module into production and beta modules in V2.0 of the SDK (released in July 2023).

Issues Linger in Documentation

The effectiveness of AI-based tools depend on the accuracy of their input sources. Generative AI can’t create new knowledge. It can only generate responses based on source content, and those responses will be flawed when imperfections exist in the source. The problem here is that the “official documentation” for how to customize item insights privacy was written sometime in 2021 and hasn’t changed much since. According to the page header, Microsoft last updated it on 31 January 2025. However, the content still details the use of incorrect cmdlets.

I know that the information was valid in 2021 because I covered the topic for Practical365.com in April 2021. The problem is that the cmdlets still use a beta endpoint, so the correct cmdlets are Update-MgBetaOrganizationSettingItemInsight and Get-MgBetaOrganizationSettingItemInsight. I don’t blame the writer responsible for the page for missing the esoteric change made to split the Microsoft Graph PowerShell SDK into two modules. The example code is simple. What could go wrong with it?

Official Microsoft Documentation isn’t Perfect

All of this illustrates the fallacy of treating “official” documentation as an infallible source of truth. The Microsoft Learn documentation is a source of valuable information that often delivers great answers. But its content suffers from the same problem as blogs and other online sources of information in that technology moves so fast these days that documentation is in a state of constant flux. Keeping hundreds of thousands of pages current is a never-ending task, even if the technology was relatively stable.

Microsoft 365 is a very dynamic and complex technical environment where features can be affected by licensing, configuration, user settings, and add-ins. Include some recent layoffs of Microsoft writers and a bunch of automatically generated documentation and suddenly, the foundation for the “official” documentation doesn’t look quite as solid. There’s still lots of very useful information in Microsoft Learn even if it’s not quite as perfect as some might think.

Seeking Help for Better Code

It makes perfect sense to use new tools to extract more advantage from existing resources. Perhaps the MCP Server for Microsoft Learn will help to address the knowledge deficit of people struggling to understand how to write better code using Microsoft technologies like the Graph APIs through its integration with GitHub Copilot. We’ll only know if this is the case over time when developers have a chance to understand if the presence of the server improves their code.

I won’t complain if the MCP Server reduces or eliminates the tendency for GitHub Copilot to hallucinate by proposing cmdlets or parameters that don’t exist. Much as I admire GitHub Copilot exhibiting its artistic side when creating previously unknown cmdlets, it’s something that wears over time.

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!

New Office 365 for IT Pros Edition Now Available

The Office 365 for IT Pros team is delighted to announce the publication of the twelfth edition of the Office 365 for IT Pros eBook, including the second edition of the Automating Microsoft 365 with PowerShell eBook (released yesterday). This edition represents the outcome of an end-to-end review of the 2025 edition, including a completely new eDiscovery chapter (due to the big changes Microsoft is rolling out in this area). The new book is available in PDF and EPUB versions from Gumroad.com. If you subscribe to Office 365 for IT Pros, you do not need to buy the PowerShell book separately because it’s included in the Office 365 for IT Pros bundle.

As always, we are making a discounted subscription available to previous subscribers. An email with a code to secure the discount has been sent to subscribers of the 2025 edition from o365itpros@creators.gumroad.com. If you had a subscription for the 2025 edition and did not receive the code, please contact o365itprosrenewals@office365itpros.com and we will fix the problem.

Unfortunately, we have had to increase the price of the book from $49.95 to $59.95. We maintained the original price since 2015 for as long as we could, but inflation, increased processing costs (credit cards, PayPal, etc.), and other costs meant that we couldn’t hold the line any longer. We asked Microsoft Copilot what the value of $49.95 in 2015 dollars is today. Today’s answer is $64.30 (Figure 1).

A week ago when I published our release plan, the suggested price was $67.73. I guess it’s the way you ask a question of AI. In either case, I’m happy that we continue to deliver good value at approximately the equivalent of 12 cups of coffee (the value of the book lasts longer than the value of the caffeine).

Remaining Focused on Practicalities

We remain utterly focused on explaining how Microsoft 365 really works in a very practical sense. Some question the value of books in a world where an AI chatbot spits out an answer to any question in less than a minute. My answer is context and experience. AI chatbots don’t necessarily (or at all) appreciate the context of how something works inside Microsoft 365. Generative AI depends on what’s been published in the past and included in its LLMs. But if that information is outdated, inaccurate, or doesn’t apply to your situation, the response will be wrong. Experience helps understand context. Based on technical skills acquired over years, experience cuts through fluff in a way that AI cannot. AI doesn’t have Microsoft 365 skills, nor does it have experience. All it can do is regurgitate, albeit in a highly proficient and (at times) useful manner.

This doesn’t deny the value of AI in many situations or the important of adapting new technologies like AI where appropriate and cost-effective. Given Microsoft’s massive investment to build out hardware and software capabilities for AI, there is no doubt that AI is a big part of our future. We’ve just got to use the tool in the best way, just like any other tool. For instance, using a Copilot agent to interrogate the contents of Office 365 for IT Pros and Automating Microsoft 365 with PowerShell.

Remember, AI cannot clean up a mess. To be successful with Microsoft 365 Copilot, you need a Microsoft 365 tenant that’s well managed and without a legacy of failed collaboration projects. The knowledge contained in Office 365 for IT Pros helps administrators manage tenants better, even if we can’t do much about the legacy of failed projects.

Additions to the Office 365 for IT Pros Author Team

We welcome two new authors for the 2026 edition. Leah Theil now looks after the Teams Basics chapter (11) while Tony Sterling oversees the Teams management chapter (12). Given the success of Teams within the Microsoft 365 ecosystem, these are important chapters, and I am delighted to have two such experienced professionals take on their care.

Keepit: Our New Sponsor

Keepit A/S, a company specializing in delivering resilience against data loss, is our new sponsor. I’m sure many of you know Keepit from technology conferences where they always serve high-grade coffee on their stand. Making sure that production data is protected is a critical success factor for Microsoft 365 deployments, and Keepit has solid products to protect Entra ID, Microsoft 365 (Exchange Online, SharePoint Online/OneDrive for Business, and Teams), and the Power Platform. We thank Keepit for their support and look forward to working with them over the coming year.

Thanks to Our Subscribers

We couldn’t do any of our work without the support of the people who subscribe to Office 365 for IT Pros, read our articles, and provide feedback. Despite what it might seem like at times, we like to receive notes telling us where we can do better, so thanks a lot to all of you who have helped us improve the books over the years. It’s been an incredibly fulfilling journey since the release of the first edition in 2015. Onward to the next edition!

Completely Revised Version of Automating Microsoft 365 with PowerShell

Last year, the Office 365 for IT Pros team took the decision to carve out a chapter covering using PowerShell with Microsoft 365 and create a separate eBook. This doesn’t mean that the Office 365 for IT Pros eBook doesn’t include PowerShell examples because it still does feature many examples, especially for Teams, SharePoint Online, and Exchange Online. However, we were conscious of the growing influence and importance of the Microsoft Graph APIs and the Microsoft Graph PowerShell SDK and wanted to reflect the critical nature of these components. There’s no doubt that if tenant administrators understand how to interact with Microsoft 365 resources via the APIs (and PowerShell makes this relatively straightforward), it’s much easier to understand how Microsoft 365 works.

This realization brought us to create Automating Microsoft 365 with PowerShell, which we believe is the most complete treatment of using PowerShell to get things done inside a Microsoft 365 tenant that’s available today. Certainly, when you combine all the examples from Automating Office 365 with PowerShell and Office 365 for IT Pros, there’s lots of informative and useful PowerShell code to automate operations in a Microsoft 365 tenant.

An Imperfect First Edition

The first edition wasn’t perfect. Pulling out a bunch of PowerShell content from a book and attempting to make it a coherent story is always a challenge. The challenge becomes more complicated with the changes Microsoft made to the Graph APIs and the Microsoft Graph PowerShell SDK, many of which were to fix problems that should never have happened.

We’ve been working to make the coverage smoother, more informative, and more impactful since the launch of the first edition and have just completed a full end-to-end review of everything in the book. Code has been corrected, tightened, and expanded to make it more useful, and we have added a bunch of new material. We even included the late-breaking news that Microsoft has set a retirement date for the AzureAD module for mid-October 2025. The need for good information about how to migrate scripts that use the AzureAD module to the Microsoft Graph PowerShell SDK has never been more obvious.

The result of that work is delivered in the second edition, which is available today.

Second Edition Available Free to Subscribers

Because we appreciate the support of people who subscribe to our books and understand that sometimes the quality of the first edition of Automating Microsoft 365 with PowerShell wasn’t where we wanted it to be, we are making the second edition available free of charge to anyone who subscribed to the first edition. If you’re a subscriber, all you need to do is use the download link in the receipt emailed to you when you bought the subscription. This link always downloads the latest version of the book, and it will now download the second edition files (EPUB and PDF).

Automating Microsoft 365 with PowerShell is also included in the Office 365 for IT Pros eBook bundle. Subscribers to Office 365 for IT Pros 2026 edition, which we anticipate releasing tomorrow (July 1, 2025) will get the second edition along with the files for Office 365 for IT Pros (2026 edition). We’re also making the second edition available to subscribers to Office 365 for IT Pros (2025 edition). Once again, use the download link in your receipt to fetch the updated files.

Subscribers who download the second edition are eligible to receive updates up to and including June 30, 2026.

Regretfully, we cannot update the paperback version of the book that people have bought. However, the updated text is now available from Amazon.com, for those who like their technical material in a printed form.

Looking Forward to 2026

We’ll continue to work on the second edition of Automating Microsoft 365 with PowerShell over the coming months. There will be new Graph APIs to cover, gaps to fill in, and we know that the Microsoft Graph PowerShell SDK has some work to do to restore its reputation with customers. Nearly four million downloads of V2.25 of the Microsoft Graph PowerShell SDK speak to its popularity and usefulness. What everyone needs now is better quality and stability in the Graph APIs and SDK. When Microsoft delivers new versions, we’ll be there to parse, analyze, and report on the news.

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.

Microsoft Leaves Gaps in Technologies for ISVs to Fill – Like Agent Governance

Every time Microsoft makes a big move, ISVs seek to take advantage with a new product. It’s the way of the work. Microsoft creates technology and ISVs fill the holes left in that technology. In some respects, the cloud is a difficult place for ISVs. There’s less to tweak than in an on-premises environment and although the Graph APIs have extended their coverage to more areas of Microsoft 365 over the last few years, significant gaps still exist for major workloads like Exchange Online and SharePoint Online.

But a new technology creates a new opportunity because everything starts from scratch. Microsoft’s big move into artificial intelligence with Copilot hasn’t created too many opportunities because Copilot depends on a massive infrastructure operated by Microsoft that’s inaccessible except through applications like BizChat. Agents are different. They’re objects that need to be managed. They consume resources that need to be paid for. They represent potential security and compliance problems that require mitigation. In short, agents represent a chance for ISVs to build products to solve customer problems as Microsoft heads full tilt to its agentic future.

Building an Infrastructure for Agent Governance

To be fair to Microsoft, they’ve started to build an infrastructure for agent management. Apart from a whitepaper about managing and governning agents, the first concrete sign is the introduction of agent objects in Entra ID. Microsoft is thinking about how agents can work together, and how that communication can be controlled and monitored. That’s all great stuff and it will deliver benefits in the future, but the immediate risk is the fear that agents might run amok inside Microsoft 365 tenants.

Microsoft reports that there are 56 million monthly active users of Power Platform, or 13% of the 430 million paid Microsoft 365 seats. That’s a lot of citizen developers who could create agents using tools like Copilot Studio. Unless tenant administrators disable ad-hoc email subscriptions for the tenant, developers could be building agents without anyone’s knowledge.

Don’t get me wrong. I see great advantages in agent technology and have even built agents myself, notably a very useful agent to interact with the Office 365 for IT Pros eBook. One thing that we’ve learned over the last 30 years is that when users are allowed to create, they will. And they’ll create objects without thought, and those objects will need to be cleaned up eventually, or, as Microsoft discovered, the mass of SharePoint Online sites created for Teams became a real problem for Microsoft 365 Copilot deployments. Incorporating solid management and governance from the start is of great benefit for new technologies.

Rencore Steps Up with Copilot Agent Governance

All of which brings me to Rencore’s announcement of two new modules for their governance product to deal with Copilot and agent governance and Power Platform governance (Figure 1). Matthias Einig, Rencore’s CEO, has been forceful about the need to take control of these areas and it’s good to see that he’s investing in product development to help Microsoft 365 tenants take control before agents get any chance to become a problem.

I have not used the Rencore product and do not endorse it. I just think that it’s great to see an ISV move into this area with purpose and intent. It seems like Rencore aims to address some major pain points, like shadow IT, the cost of running Copilot agents, over-sharing, and “agent sprawl.” All good stuff.

I’m sure other ISVs will enter this space (and there might be some active in the area already that I don’t know of). This will be an interesting area to track as ISVs seek new ways to mitigate the potential risks posed by agents.

No Time to Relax

Product from one ISV does not mean that we can all relax and conclude that agent management is done. It’s not. The continuing huge investment by Microsoft in this space means that agent capabilities will improve and grow over time. Each improvement and new feature has the potential to affect governance and compliance strategies. Don’t let your guard down and make sure that your tenant has agents under control. And keep them that way.

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.

Token Protection, PRTs, Device Binding, and Session Keys

Last year, I discussed how to use a conditional access policy to apply a new session control called token protection. The idea is to protect against token theft by requiring connections to have a token (the Primary Refresh Token, or PRT) that has a “cryptographically secure tie” with the device that the connection originates from. The PRT is “bound” to a device key that’s securely stored in the device’s Trusted Platform Module (TPM). PRTs are supported on Windows 10 or later devices.

The PRT is an “opaque blob” that’s specific to a user account and device. The Entra ID authentication service issues a PRT following a successful connection by a user when the device is registered, joined, or hybrid joined. Entra ID also issues a session key, an encrypted symmetric key to serve as proof of possession when a PRT attempts to obtain tokens for applications. If an attacker attempts to hijack a connection with an access token they’ve stolen, they’ll fail because they don’t have access to the device key.

Why Does This Matter?

As noted in my article last year, it’s possible to create a conditional access policy with a session control requiring token protection. In other words, when a connection attempts to satisfy the conditions of the policy, it must be able to prove that its PRT is bound to the device where the connection originates and the user making the request. This process is managed by a component called Web Account Manager (WAM).

But conditional access policies can only work if everything involved in the connection understand what’s going on. At the time I wrote the last article, limited support existed for token protection. The reason for this article is that interactive Microsoft Graph PowerShell SDK sessions now support token protection (see details about support for token protection by other applications here). This opens the possibility of extending additional protection for administrators and developers who might work on sensitive data through the Graph SDK.

The reason why you might want to do this is revealed in a recent Entra ID change that shows the resources a user can access when they satisfy a conditional access policy to connect. In this case, the connection is to an interactive Graph PowerShell SDK session, and the resources available in that session depends on the delegated permissions held by the Microsoft Graph Command Line Tools service principal. The set of permissions tends to swell over time as administrators grant consent to permissions needed to work with different cmdlets, but as Figure 1 shows, a Graph PowerShell SDK session can have access to many different resources.

Enabling Token Protection for Graph Interactive Sessions

Normally, interactive Graph PowerShell SDK sessions don’t use WAM. To enable WAM for Graph sessions, run the Set-MgGraphOption cmdlet before running Connect-MgGraph. As the documentation says, the cmdlet sets global configuration options, so the configuration setting stays in force for all Microsoft Graph interactive sessions on the workstation until it is reversed.

Set-MgGraphOption –EnableLoginByWAM $true
Connect-MgGraph

If the device isn’t registered or joined, the conditional access policy condition for token protection isn’t satisfied and the sign-in attempt is rejected with a 530084 error code. The cause is obvious if you examine the policy details captured in the sign-in event (Figure 2).

WAM doesn’t affect app-only authentication for the Graph SDK, including Azure Automation runbooks that use modules and cmdlets from the Graph PowerShell SDK.

Token Protection and Elevated PowerShell Sessions

The Web Account Manager option doesn’t work in elevated PowerShell sessions (run as administrator). Attempts to connect fail with the error “InteractiveBrowserCredential authentication failed: User canceled authentication.”

The solution is two-fold. First, revert to normal authentication on the workstation by running the Set-MgGraphOption cmdlet to set EnableLoginByWAM to $false. If you don’t, authentication fails because a protected token isn’t available (Figure 3). The second step is to remove users who need to run Graph cmdlets in elevated PowerShell sessions from the scope of the conditional access policy. This avoids the user running into problems on other workstations.

Token Protection and Microsoft Graph PowerShell SDK Versions

The WAM option also doesn’t work with the latest versions of the Microsoft Graph PowerShell SDK. This is likely due to Microsoft’s decision to remove support for .NET6 from V2.25 on. In V2.28 of the SDK, the error when running Connect-MgGraph is:

InteractiveBrowserCredential authentication failed: Could not load type 'Microsoft.Identity.Client.AuthScheme.TokenType' from assembly 'Microsoft.Identity.Client, Version=4.67.2.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'.

While Microsoft gets their act together and decides how to fix the issue, the only option is to remain using V2.25. PCs that have upgraded to the current V2.28 release must downgrade to V2.25.

Token Protection is Just Another Tool

Token protection is not for everyone. Its linkup with conditional access policies is another tool for administrators to consider when figuring out how to secure their tenant. My recommendation is that you test the feature and make a measured decision whether it has any value for your organization. Remember that this is an evolving space and other applications are likely to support token protection over time. Maybe one of those applications will be exactly the one you want to secure.

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.

Problems with Azure Automation Afflict Microsoft 365 PowerShell Modules

The recent problems with the Microsoft Graph PowerShell SDK are well documented. Suffice to say that the Graph PowerShell SDK hasn’t been very stable since V2.25. V2.26 and V2.27 just didn’t work, and although Microsoft delivered a much-improved update in V2.28 in May 2025, the Graph PowerShell SDK still has problems with Azure Automation.

In the Azure Automation environment, runbooks are configured to use a runtime version of PowerShell. When a runbook starts, Azure Automation loads the dependent modules (which must be a version that matches the runtime version) on the target server where the runbook executes. Currently, Azure Automation supports runtime versions for PowerShell V5.1, V7.1, and V7.2.

A Question of .NET

PowerShell V5.1 is the “classic” version. V7-based PowerShell is “PowerShell Core.” The V7.1 and V7.2 runtimes support .NET 6 while the latest versions of PowerShell use .NET 8. Software engineering groups don’t like supporting what they consider to be outdated software, so a decision was taken to drop support for .NET 6. The net effect was that V7.1 and V7.2 runbooks couldn’t use the Graph PowerShell SDK. The workaround was to use the PowerShell V5.1 runtime or revert to V2.25 of the Graph PowerShell SDK, which still supports .NET6.

Microsoft says that the solution will come when Azure Automation supports the PowerShell V7.4 runtime. That update was supposed to arrive by June 15, 2025. It’s late, so I cannot confirm or deny if Graph PowerShell SDK V2.28 code supports PowerShell V7.4 runbooks.

The .NET Versioning Problem Strikes Exchange

A week or so ago, a reader complained that the latest version of the Exchange Online management module (now V3.8.0) didn’t run with PowerShell V7.2 runbooks. A previous comment for the article where the issue was raised said that V3.5 was required to support PowerShell V7.2 runbooks as long ago as February 13, 2025. At the time, apart from finding a relevant Stack Overflow discussion, I didn’t pay too much attention to the problem. I guess I became accustomed to the Exchange module just working while the Graph PowerShell SDK was the problem child of the Microsoft 365 PowerShell modules.

As it turns out, the Exchange Online management module shares the same problem as the Microsoft Graph PowerShell SDK. Engineering decided to remove support for .NET 6 in V3.5.1 of the Exchange module and screwed up Azure Automation V7 runbooks. The release notes for V3.5.1 are brief and concise:

Version 3.5.1

• Bug fixes in Get-EXOMailboxPermission and Get-EXOMailbox.
• The module has been upgraded to run on .NET 8, replacing the previous version based on .NET 6.
• Enhancements in Add-VivaModuleFeaturePolicy.

There’s nothing to raise awareness for tenant administrators that the change in supported .NET version will stop runbooks dead in the water. It’s easy to glance over the release notes and conclude that not much has changed and it’s therefore safe to upgrade to the new version. The problem becomes very evident when the Connect-ExchangeOnline cmdlet can’t run and as a result, every other Exchange cmdlet cannot be found (Figure 1).

The Need for Solid Azure Automation Support

No one denies that Microsoft must prune old software from their cloud services. It’s hard enough to keep a service running smoothly when it carries unnecessary baggage in the form of old code. But in the cases of both the Microsoft Graph PowerShell SDK and the Exchange Online Management module, it seems like the engineering groups never stopped to ask if the change might impact the ability of scripts to run. Running scripts interactively revealed no issues, but running code in an interactive session on a Windows PC (or even a Mac) is not the same as Azure Automation firing up a headless server and configuring it with the software necessary to execute a runbook.

Ensuring that shipped modules support Azure Automation is a problem that can be solved by incorporating Azure Automation runbooks in the test procedures that must succeed before a new version of a module can be released. What’s more upsetting is the lack of awareness within Microsoft about why customers pay for Azure Automation to run scripts.

When a script moves from running interactively on an administrator workstation to become an Azure Automation runbook, it’s probably because the script is deemed to be important enough to run on a stable, robust, and secure environment, often on a schedule (the Windows Task Scheduler should not be relied upon to run important scripts). In other words, Azure Automation is an important platform that deserves the respect and solid support of the Microsoft engineers that build PowerShell modules that can run within Azure Automation. That doesn’t seem to be the case today.

Too Much Disruption

Microsoft 365 tenants have suffered far too much disruption with PowerShell modules over the last few years. The retirement of the old Azure AD and MSOL modules was a necessary evil, but Microsoft didn’t handle the situation as well as they should. Many sins might be forgiven if the Microsoft 365 PowerShell modules were rock solid. They’re not currently. Let’s hope that Microsoft does a better job in their testing and pre-release verification processes for PowerShell modules in the future.

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.

Thanks to the Office 365 for IT Pros Subscribers

In a time when some question the value of books, we deeply appreciate the support of the folks who subscribe to the Office 365 for IT Pros eBook. AI tools like ChatGPT and Copilot can find and synthesize information scoured from across the internet to respond to questions, but so far generative AI cannot provide the context or insight that understanding technology often needs.

An ecosystem like Microsoft 365 can become terribly complicated through different combinations of products, licenses, and configurations. Throw in hybrid organizations and there’s enough to melt an administrator’s mind. We don’t pretend that we have more answers than AI can generate; we do say that our answers are based on hard-won experience and a ton of research into why Microsoft 365 works the way that it does. In other words, we ask “why” when AI just accepts what something is.

Heading for a July 1 Release

It’s just seven days to go before we release Office 365 for IT Pros (2026 edition), including Automating Microsoft 365 with PowerShell (2^nd edition). The writing team is still heads-down to make sure that the content is compelling, informative, and up to date, and that any of the issues raised by technical editor Vasil Michev are addressed.

We’ve received some questions about how we will release the 2026 edition. Thankfully, people want to know when they can subscribe to the new edition. With that in mind, here’s our plan.

The Release Plan

The first task is to complete all the updates to the chapters, resolve any open issues, chase down the last-minute glitches, and have a coffee. We can then proceed to do the following:

• Generate the PDF and EPUB files for the two books, check that everything is OK, and if all checks out, upload the new files to Gumroad.com. We then switch the shortcut URL for the current version from the 2025 edition to the 2026 edition.
• The 2025 edition files will remain online to allow subscribers to that edition to download the final updates. We made some small tweaks to the Office 365 for IT Pros (2025 edition) files since releasing update #120 on June 1. The current update number for the 2025 edition is 120.4, dated 21 June 2025. We will start the 2026 edition at update 121.0.
• We will send an offer to current subscribers to allow them to extend their subscription to cover the 2026 edition and receive monthly updates for the next year. To reward the folks who renew subscriptions immediately a new edition is available, the price to extend a subscription in July 2025 is $18.95. After August 1, 2025, the price to extend a subscription increases to $24.95.
• Anyone who bought a full-price ($49.95) copy of the 2025 edition in June 2025 will receive a full discount code to extend their subscription for the 2026 edition.
• The update offer and codes are distributed via email to the addresses registered when people subscribed to the 2025 edition. If an email address is incorrect, you won’t receive anything from us. In this case, send email to contact@office365itpros.com to tell us what’s going on. If we can find you on our subscriber list, we’ll respond with the code.
• Some tenants consider email from Gumroad.com as spam. Our email isn’t and we have experimented with sending email using the Exchange HVE and Azure ECS solutions during the last year. HVE is now out of the picture because Microsoft has decided that it will only handle internal email, but anyway, mass mailings about new versions are always sent from Gumroad.
• New subscriptions for the 2026 edition cost $59.95. This is our first price increase since 2015. According to Copilot, the price should be $67.73, but accepting an AI recommendation without question is never a good idea. We believe that the increase is more than justified by the massive amount of information contained in the two books, which can be reasoned over by a Copilot agent if you want.
• The Automating Microsoft 365 with PowerShell eBook is bundled with Office 365 for IT Pros and doesn’t have to be bought separately. People who subscribed to the first edition of the PowerShell book can download the second edition free of charge. It’s our way of saying thanks to those who bought the first edition while we built out the content.
• For those who like paper books, a version of Automating Microsoft 365 with PowerShell is available in paperback from Amazon.com. This is the same text as the electronic version, except that hyperlinks are converted to footnotes. The paperback also has an index because it’s harder to search through paper. Regretfully, we haven’t found a way to update a paperback remotely, so buying a paper copy of the PowerShell book is like buying any other paperback.
• Anyone who received a free copy of the 2025 edition from us or another source (companies commonly buy multiple copies to give to customers) can use the code to extend their subscription for $18.95. Alternatively, ask the source for the free copy – maybe they have free copies of the 2026 edition to distribute.

2026 or Twelfth?

Some ask us why we name the book after the year ahead. We do so because we match Microsoft’s fiscal year. Their FY26 begins on July 1, 2025. We could call this release Office 365 for IT Pros (12^th edition). Maybe that would be clearer, but the date does help in terms of telling people how recent the content is.

Enjoy the 2026 edition!

Summarize Attachment Feature is an Example of New Features Needed to Maintain Customer Interest

Introducing a new technology is hard. The great expectations created at the initial launch soon meets the hard reality of deployment and things don’t get better until the technology has had time to bake. This is as true for Microsoft 365 Copilot as for any other major technology. I see people questioning whether the $30/user/month really delivers any benefits, with real concern over whether people use any of the purported time saved through Copilot interventions doing anything more valuable than drinking more coffee.

News that the U.S. Better Business Bureau forced Microsoft to change some of the claims it makes about how Microsoft 365 Copilot affects user productivity doesn’t help the case for AI-based assistance. And lukewarm or mildly enthusiastic (but independent) reports about Copilot usage in organizations, like the recent UK Government report based on a 3-month trial for 20,000 employees don’t bolster the case much either.

All Microsoft can do is continue to push out updates and new AI-based features to keep customer interest while Copilot matures to become more useful in day-to-day activities. The result is a flood of new Copilot-related features, not all of which seem valuable except in specific cases. I don’t know whether AI-informed People Skills will become popular (some HR professionals that I know like People Skills a lot). Those in the Power Platform world (now with 56 million monthly active users according to data made available at Microsoft’s FY25 Q3 results) see lots of changes to make Copilot agents more productive. I do like the ability to upload documents to agents for the agents to reason over.

Summarizing Attachments

All of which brings me to the update described in message center notification MC1073094 (13 May 2025, Microsoft 365 Roadmap item 475249). It’s an example of a recent Copilot enhancement to help users process “classic” email attachments faster. Even though cloudy attachments are preferable in many respects, many people still send files instead of links.

Copilot has been able to summarize cloudy attachments for email for quite a while. Now, when a message with one or more classic file attachments arrives, users with a Microsoft 365 license see a new summarize option for Office and PDF attachments. The feature is available in the New Outlook for Windows, OWA, Outlook mobile, and Outlook for Mac. . Microsoft is rolling out the update now with estimated completion by late August 2025. According to MC1112451, Outlook classic will receive the update in mid-July 2025

Figure 1 shows the general idea. A Word file is attached to a message. Clicking the summarize option from the drop-down menu beside the attachment causes Copilot to create and display the summary for the file inside the Summary by Copilot panel (or card). If a message has multiple file attachments, the summarize option must be invoked separately.

Copilot cannot process encrypted attachments (using sensitivity labels or another encryption mechanism).

No Archived Messages

My archive mailbox is full of attachments from long-forgotten projects, including files related to some legal cases that I was involved with. I was curious to see what sense Copilot might extract from some of the PDFs and Word documents from those cases. Oddly, Outlook won’t summarize any of the attachments for messages stored in an archive mailbox. To generate a summary for these files, you must open download and open Office files in a desktop or web app and use the Copilot options available in the app.

Thinking about why this might be so, I guess the logic is that attachments for archived messages probably aren’t of very high interest, and if someone goes to the trouble of finding an archived message, they have a purpose for doing so and won’t mind opening attachments to view content. On the other hand, I could be overthinking things and Microsoft simply designed the feature to work only with messages from the primary mailbox.

The Value of Small Changes

Over my many years of work, I cannot say how many emails I have received with file attachments. Being able to see a quick summary of an attachment is a good example of how AI can be effective. The feature works well because the AI has just one file to process, so it’s unlikely that hallucinations or other issues will occur. You might disagree with points made in the summary, but having the summary is a timesaver and a great starting point for understanding whether a file contains anything important.

Another example of a small but interesting change is the ability to create a meeting from an Outlook email thread (MC1090693, 9 June 2025, Microsoft 365 roadmap item 494154). The idea is that Copilot scans an email thread to determine the topic for a meeting and its participants and creates a meeting invitation ready to go. This kind of thing doesn’t need AI because existing Graph APIs can do the work, but Copilot integrates the work into a new Schedule with Copilot option (only for email threads with sufficient data to base a meeting upon). According the roadmap item, this feature is for the mobile clients, but I bet it will be available in the new Outlook and OWA too.

In the overall scheme of Copilot, delivering Outlook features to make small tasks easier is not important. However, changes that reduce friction for users are important and collectively a bunch of changes like this might just be enough to convince an organization that they really can’t live without Copilot.

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

New Microsoft-Managed App Consent Policy to Control User Consent for Apps

Message center notification MC1097272 (17 June 2025) announces Microsoft’s intention to restrict access to some legacy protocols and introduce a new managed app consent policy to the ability of users to grant consent to third-party apps that want access to files and sites.

Microsoft says that they are updating default settings to help Microsoft 365 tenants “meet the minimum security benchmark and harden your tenant’s security posture.” As far as I can tell, this appears to be a reference to section IM-2 of the Microsoft cloud security benchmark. For good measure, Microsoft throws in the Secure Future Initiative and Secure by Default principle to provide further justification for the change.

No Problem with Blocking Obsolete and Insecure Protocols

I don’t think anyone will complain about blocking browser access to SharePoint and OneDrive via the Relying Party Suite (RPS – another relatively unknown component for most Microsoft 365 tenants). Legacy protocols are blocked in the SharePoint tenant configuration, and this change reinforces the block.

Get-SPOTenant | Select-Object LegacyBrowserAuthProtocolsEnabled

LegacyBrowserAuthProtocolsEnabled
---------------------------------
                             True

Likewise, I don’t think anyone will complain about blocking the FrontPage Remote Procedure Call (FPRPC) protocol for Office file opens. It’s an outdated protocol that attackers have leveraged (here’s an example).

App Consent Policy to Prevent Third-Party Access to Files and Sites

My interest was drawn to the third block, which will introduce a Microsoft-managed app consent policy to require administrator consent for third-party apps that access files and sites. There are a bunch of app consent policies already present in tenants that you can see by running the Get-MgPolicyPermissionGrantPolicy cmdlet from the Microsoft Graph PowerShell SDK (any policy prefixed by “microsoft” is a Microsoft-managed app consent policy):

Get-MgPolicyPermissionGrantPolicy | Format-Table Id, DisplayName, Description -AutoSize

Like many other Microsoft 365 policies, the policy is a container, and the real settings (“condition sets”) are found by running the Get-MgPolicyPermissionGrantPolicyInclude cmdlet. For example, this app consent policy allows administrators to manage all aspects of all apps in a tenant:

Get-MgPolicyPermissionGrantPolicyInclude -PermissionGrantPolicyId "microsoft-application-admin" | Format-List

ClientApplicationIds                        : {all}
ClientApplicationPublisherIds               : {all}
ClientApplicationTenantIds                  : {all}
ClientApplicationsFromVerifiedPublisherOnly : False
Id                                          : 811d2da7-443c-43da-96e7-28d285b234e9
PermissionClassification                    : all
PermissionType                              : application
Permissions                                 : {all}
ResourceApplication                         : any
AdditionalProperties                        : {}

ClientApplicationIds                        : {all}
ClientApplicationPublisherIds               : {all}
ClientApplicationTenantIds                  : {all}
ClientApplicationsFromVerifiedPublisherOnly : False
Id                                          : 60461179-740e-4d8b-9e00-1456a338c44b
PermissionClassification                    : all
PermissionType                              : delegated
Permissions                                 : {all}
ResourceApplication                         : any
AdditionalProperties                        : {}

For more details, see the Graph documentation for permission grant policies. There’s no UX in the Entra admin center to manage app consent policies. This article throws more light onto how to build your own app consent policies.

The Change Doesn’t Affect All Tenants

The change only affects tenants that use the default user consent settings. In my case, I changed the settings (Figure 1) to allow users to consent to a set of low-impact permissions such as User.Read. The Sites.Read.All or Files.Read permissions are definitely not in the low-impact category, which is why Microsoft is blocking them.

If you allow users to consent to permissions, you should monitor the consents to make sure that apps are not asking for unexplainable permissions. You can check permission consents through audit records. You’ll also need to make sure that the admin consent request workflow is operational.

See this article for a script to use the Microsoft Graph PowerShell SDK to generate a report of all delegated permission grants that exist in a tenant. The script reports permissions that apply to all users (consent type of “AllPrincipals”) and specific users (“Principal”). It ignores common permissions such as those required to read the user’s own profile and focuses on permissions that might disclose information if used badly. If you’re concerned about the permissions users have already granted to their data, filter on the grants of the Principal consent type and review those.

The ChatGPT Conundrum

What’s interesting about Microsoft’s move is that it neatly blocks the ability of users to grant consent for the permissions needed by the ChatGPT app to upload files from SharePoint Online and OneDrive for Business for processing by one of the ChatGPT models. A cynic might say that Microsoft is taking this step to make sure that Microsoft 365 Copilot has sole access to files stored in SharePoint Online and OneDrive for Business. A more benign reading is that Microsoft is simply making sure that users can’t inadvertently grant access to third-party apps to access and read their Microsoft 365 files.

In any case, I don’t think people should upload files to ChatGPT because this activity creates all sorts of security concerns. Fortunately, it’s easy to find and block the ChatGPT app if it’s already in a tenant. In addition, ChatGPT cannot process encrypted files protected by sensitivity labels because it doesn’t have the access right needed to open protected files.

Don’t Drop Your Guard

No can argue that we do need to do better to secure tenants, so the changes proposed by Microsoft are welcome. The changes will begin rolling out in mid-July and are due to be in all tenants sometime in August 2025.

There are still too many tenants that don’t protect user accounts with multifactor authentication, which is why bad actors keep using password spray attackers in an attempt to compromise accounts. A recent report describes a password spray attack by a group called SneakyStrike against Entra ID accounts. The report is a little overhyped, but it’s a good reminder that attackers still patiently look for weak tenants to penetrate.

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

Use Microsoft Graph PowerShell SDK Cmdlets to Maintain the Entra ID Custom Banned Password List

Vasil Michev is busy these days. Apart from his day job, he’s doing the technical reviews for the Office 365 for IT Pros (2026 edition) and Automating Microsoft 365 with PowerShell (2^nd edition) eBooks, both due for release on July 1, 2025. Technical editing is an important part of our publication process because it’s an annual end-to-end review of all content to help authors refine their chapters, eliminate old and unnecessary text, and consider what they should be covering.

And still Vasil finds time for his own writing, such as a recent article about using the Microsoft Graph PowerShell SDK to update the banned password list for Entra ID accounts. Given that the Graph PowerShell SDK is a major topic for Automating Microsoft with PowerShell, my attention was immediately drawn to the article to understand what it described and consider it for inclusion in the book. It is now, along with 350+ pages of other PowerShell content about automating different aspects of Microsoft 365 activities.

Global Banned Password List

The Entra ID password protection feature maintains a global list of banned passwords. Microsoft maintains the list and updates it on an ongoing basis from telemetry for Entra ID authentication. All attempts to change account passwords are checked against the global banned list to make sure that the new password is reasonably strong. In other words, it’s not something like “Mypassword” or “Cats.” Tenant administrators cannot affect how Entra ID uses the global list of banned passwords, nor can they add or remove values from the list. It’s just part of how Entra ID works, and this part of password protection is included in the version of Entra ID included with all Microsoft 365 tenants.

Custom Banned Password List

If a tenant has Entra P1 or P2 licenses, they can implement a custom banned password list. The custom list supplements the global banned password list. The custom list is limited to 1,000 entries, but those entries are “key base terms” of between 4 and 16 characters. In other words, Entra ID blocks variations and combinations of the terms in the custom banned password list.

When a custom banned password list is available, Entra ID combines its entries with the global banned password list. The idea is that tenants might want to stop people using organization-specific terms like the names of locations or buildings in passwords because these terms might be easy for attackers to guess in a spray attack. Of course, you shouldn’t be depending on passwords and should deploy multifactor authentication to protect accounts, but it’s worthwhile protecting passwords as much as possible.

Blocking Passwords

Figure 1 shows some of the entries in the custom banned password list as viewed through the Entra admin center. You can see that the last entry is for “VictorMeldrew.” This is a key base term for password checking.

In Figure 2, an administrator has attempted to change an account password through the Microsoft 365 admin center. The password looks strong, but Entra ID rejects it because it includes a key base term. Telling the administrator that the password is easily guessable is just the way Microsoft chose to say: “can’t use that password.”

Updating the Custom Banned Password List with a Script

Vasil’s article covers the basics of creating a directory settings object to hold password protection settings, including the custom banned password list. I used that information to create a script that’s more like something you might use as production code, which you can download from GitHub.

The code:

• Checks if the correct permission (Directory.ReadWrite.All) is available to read, create, and update directory settings. This is a very high-level permission that should be restricted as tightly as possible. You should also monitor the apps that hold this permission to make sure that they are used correctly.
• Import a list of key base terms from a CSV file and checks that each term is at least 4 and no more than 16 characters long.
• Uses the Get-MgBetaDirectorySetting cmdlet to check if a directory setting object for password protection is defined in the tenant. If not, the script runs the New-MgBetaDirectorySetting cmdlet to create and populate a new directory setting object with the list of key base terms (and other default values). The directory setting object is derived from the directory settings template for password rules. The template always has an identifier of 5cf42378-d67d-4f36-ba46-e8b86229381d.
• If a directory setting object for password protection is available, fetch the list of current key base terms and combine it with the new list to generate a combined list. The Update-MgBetaDirectorySetting cmdlet then updates the directory setting object with the combined list.
• Export the newly-updated list to a CSV file.

If you prefer to use the input CSV file as the definitive set of key base terms and not combine the input set with the current set, it’s easy to comment out the two lines that create a combined list.

The only semi-weird thing about the list of key base terms is that it uses tabs for delimitation (which is why the code splits the list using [char]9).

Hopefully the script is of some use. If not, I won’t be offended. Check out the 320-plus scripts in the Office365Itpros GitHub repository. You might find something more useful there!

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.

Marked Lack of Detail around Microsoft 365 Local

Microsoft’s June 16 announcement about “sovereign solutions empowering European organizations” (Figure 1) is obviously an attempt by Microsoft to reassure European customers that continuing to use Microsoft (U.S.-based) technology is a safe choice at a time when many question the policies of the current U.S. administration.

To be fair to Microsoft, they’ve been on the path to respect data sovereignty for many years, starting with the original “Black Forest” implementation of Office 365 for German customers to a point where multiple national-level datacenter regions are available within Europe. Microsoft’s continued efforts to provide comfort to customers who want their data stored in-country and under the control of European law is commendable.

However, the announcement of Microsoft 365 Local confused everyone. According to the announcement, “Microsoft 365 Local provides customers with additional choice by bringing together Microsoft’s productivity server software into an Azure Local environment that can run entirely in a customer’s own datacenter.”

Apart from the Name, No Trace of Microsoft 365

Applying the Microsoft 365 branding to the offering implies some form of connection to Microsoft 365. But apart from a need to connect to Azure., this solution seems to have nothing much to do with Microsoft 365 cloud services. Instead, it appears to be the on-premises versions of Exchange Server, SharePoint Server, and Skype for Business Server running on an Azure Local instance, defined as “a machine or a cluster of machines running the Azure Stack HCI operating system and connected to Azure.”

At this point, Microsoft hasn’t shared details of how the services connect together, but I assume that Active Directory is in the mix too. We also don’t know if the Azure-based local infrastructure operates as a separate deployment, can be integrated into an existing on-premises organization, or operate as part of a hybrid organization.

In other words, Microsoft 365 Local is a modernized example of a packaged Azure-based installation of Exchange, SharePoint, and Skype for Business built according to a reference architecture and accessed via the same kind of clients that people use today to connect to on-premises servers. Unsurprisingly, Microsoft 365 Local doesn’t include Teams because Teams relies so heavily on services from Exchange, SharePoint, OneDrive, Planner, and a bunch of Azure microservices.

The packaging might be innovative, and Microsoft marketing will certainly call the announcement a triumph for branding, but it has nothing to do with Microsoft 365. Anyone who steps back from using Exchange Online with its close integration with SharePoint Online will quickly discover how different things are.

Some Organizations Will Love Microsoft 365 Local

Although I hate the name, a place exists for a solution like Microsoft 365 Local. Some companies want to control their own destiny, which is why they continue running on-premises software; others don’t have sufficient external network capacity to be dependent on cloud services.

Other companies simply want to not have to deal with the blizzard of changes that Microsoft 365 customers have to cope with, or the constant nagging from Microsoft to adopt and use its AI-based tools like Microsoft 365 Copilot. European customers have a strong track record of respecting user privacy, and solutions like the recently-launched AI-powered People Skills are unlikely to be popular with unions or works councils.

Being able to purchase a packaged solution that is hopefully better integrated out-of-the-box is a nicer option than having to convince Exchange Server and SharePoint Server (for instance) to work together, an exercise that is usually guaranteed to frustrate. Presumably the solution leverages the subscription version of the three on-premises servers and will be paid for via an Azure subscription in the same manner as Azure Local.

Lack of Detail is Frustrating

The trouble is the total lack of detail currently available about Microsoft 365 Local. The above is inspired guesswork based on reading between the lines of Microsoft’s announcement. Many questions remain unanswered. Customers will need pricing and availability details from the various hardware vendors listed in the announcement are before they can decide if Microsoft 365 Local is for them. Migration from current on-premises deployments is another issue to resolve as is deployment alongside existing deployments.

The lack of detail is frustrating, but this is a classic marketing playbook: announce a product to gauge interest and follow up if the interest is there. It will be interesting to see what Microsoft 365 Local can deliver and at what cost.

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

New Service to Manage People Skills in an Organization

The April 23, 2025, announcement about the general availability of People Skills, “a powerful new data layer in Microsoft 365 Copilot” is now being followed by the deployment of People Skills to tenants as described in MC1060842 (last updated 3 June 2025, Microsoft 365 roadmap item 485726). Microsoft expects deployment to complete worldwide in mid-July 2025.

People Skills Licensing

Along with the deployment, MC1060845 says that Microsoft is updating Office 365 and Microsoft 365 licenses to include the People Skills Foundation service plan (PEOPLE_SKILLS_FOUNDATION, 13b6da2c-0d84-450e-9f69-a33e221387ca). According to the licensing section of the People Skills documentation, “People Skills comes with your Microsoft 365 or Viva licenses and doesn’t need a separate license.” Other People Skills licenses are available, and Microsoft once again is in danger of confusing customers with licensing. I think Figure 1 boils the licensing situation down to two buckets.

Users with the foundation service plan (included with licenses such as Office 365 E3) can “search to add skills from your taxonomy or imported skills to create a skills profile using the Microsoft 365 profile editor.” In other words, these users can access skill information through the Microsoft 365 profile card and Outlook’s Org Explorer and update their skills via the Microsoft 365 profile editor. Users with Microsoft 365 Copilot licenses can do more, like use the Skills agent to look for people with specific skills in the organization. Or as Microsoft puts it, the agent “helps employees and leaders explore, manage, and use organizational skills for personal growth and strategic planning.”

This list of where skills data appears in Microsoft 365 is worth reading. Not everything is available today, but you can see where Microsoft is heading.

Setting Up People Skills

Before any skills appear in public view, a tenant must go through the People Skills setup process. The setup option is available in the Settings (choose Viva, then data management) or Copilot sections of the Microsoft 365 admin center. Microsoft recommends a quick setup (Figure 2) to configure the People Skills service with default settings, including a skills library of some 16,297 different areas of expertise that people might have.

The setup process runs in the background and takes at least a day to finish. It seems like much of the time taken is to allow skills interferencing by AI to happen. This means that an AI agent examines the details of users and their activity (Graph-based access to email, Teams messages, and documents) to figure out what skills each user might have. For instance, someone with a “Software architect” job title probably knows something about software architecture, and their communications with other users will probably reveal what areas of software architecture they work in. If this sounds creepy, you can disable the feature using Viva policies managed through PowerShell.

For example, these commands reveal the set of features that can be managed through the PeopleSkills module and create a new policy to disable skills interferencing for members of a specific distribution list:

Get-VivaModuleFeature -ModuleId PeopleSkills

Add-VivaModuleFeaturePolicy -Module PeopleSkills -FeatureId SkillsInferencing -IsFeatureEnabled $false -GroupIds NoSkills@office365itpros.com -Name TurnOffSkillsInterferencing

The Get-VivaModuleFeatureEnablement cmdlet checks if the feature is disabled for a user:

Get-VivaModuleFeatureEnablement -ModuleId PeopleSkills -FeatureId SkillsInferencing -Identity Marty.King@office365itpros.com

FeatureId         Enabled
---------         -------
SkillsInferencing   False

Note that if Skills inferencing has already happened for a user, it will take several days for the information to disappear from their user profile. Speaking of profiles, Figure 3 shows how AI-inferenced skills appear in my Microsoft 365 profile card. The skills listed here aren’t confirmed. In other words, they are skills that the AI agents thinks that I might have based on the knowledge available to it (I won’t get upset by the poor spelling of PowerShell).

I’m not sure about some of these skills (like decision making). By selecting the Update your profile option, I can select which skills I agree I have (Figure 4), add some more skills that the AI overlooked by selecting from the skills inventory, and confirm the set. Confirmed skills show up with a blue tick mark when people view the profile card.

Graph API

A ListSkills Graph API is available for the Profile resource type to list the set of skills for a user account. The API uses the User.Read delegated permission and no application permission is available. In other words, you can’t use the API to create a report of skills for every user in the organization. Here’s how to use the Get-MgBetaUserProfileSkill cmdlet from the Microsoft Graph PowerShell SDK to list the skills of the signed in user:

Get-MgBetaUserProfileSkill -UserId (Get-MgContext).Account | Sort-Object DisplayName | Format-Table DisplayName, allowedAudiences, CreatedDateTime

DisplayName                              AllowedAudiences CreatedDateTime
-----------                              ---------------- ---------------
Application Development                  organization     11/06/2025 08:46:52
Application Programming Interfaces (API) organization     11/06/2025 08:46:52
Artificial Intelligence (AI)             organization     11/06/2025 08:46:53
Business Intelligence (BI)               organization     11/06/2025 08:46:53
Business Management                      organization     11/06/2025 08:46:52
Business Negotiation                     organization     11/06/2025 08:46:52
Change Management                        organization     11/06/2025 08:46:53

Some People Skills Oddities

Of course, the combination of skills determined by AI and the user might not actually be true. I could claim to be a Hyper-V expert (I’m not), and the AI might think that I know something about SharePoint Online because I’ve written about the topic often. Oddly, the AI concluded that I know something about Exchange but not about SharePoint, Teams, Planner, or other Microsoft 365-related topics. Although PowerShell is a skill, Microsoft Graph isn’t listed in the skills inventory. I tried to add some custom skills by following the steps in the documentation (requiring a CSV upload to SharePoint is bizarre), but the admin center couldn’t find the CSV uploaded to a site that I owned, no matter what form of a path I used.

The skills used by the latest iteration of skill highlighting and management within Microsoft 365 are not the same as those captured in SharePoint Online or Delve (User Profile Application or UPA skills). According to the documentation, once you enable People Skills, the UPA skills are hidden from the user profile card. This might happen in the future, but I see both sets of skills listed today. Another future is migration of UPA skills to People Skills. Microsoft says that this will happen but hasn’t yet clarified how or when. Perhaps migration isn’t in their current skill set?

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Use Office 365 for IT Pros PDF Files as Knowledge Sources for Copilot

The announcement in message center notification MC1078671 (20 May 2025) that Copilot Studio can deploy agents to SharePoint Online sites (in Copilot Studio terms, SharePoint Online is a channel) gave me an idea. SharePoint has supported agents since October 2024, but those agents are limited to reasoning over the information contained in a site. Copilot Studio can create more flexible and powerful agents that can consume different forms of knowledge, including external web sites and files. Uploaded files are stored in the Dataverse, or the mysterious SharePoint Embedded containers that appeared in tenants recently.

My idea is to use the Office 365 for IT Pros eBook as a source for a Copilot agent. Our subscribers can download updated book files every month in PDF and EPUB format. Copilot can consume text files, including PDFs, as knowledge sources (message center notification MC1058260, last updated 9 June 2025, Microsoft 365 roadmap item 489214). If you have Microsoft 365 Copilot licenses, it seems logical to create an agent that uses the PDFs for the Office 365 for IT Pros and Automating Microsoft 365 with PowerShell eBooks as knowledge sources.

You could even expand the set of knowledge sources to https://office365itpros.com and https://practical365.com to include articles written by our author team. Once the agent is configured, it can be published to a SharePoint Online site for users to interrogate. Sounds good? Let’s explore what you need to do to make the idea come alive.

Adding Files to a Copilot Agent

During an investigation of the various ways to create Copilot agents, I created an agent in Copilot Studio called the Microsoft 365 Knowledge Agent. The agent already reasoned over office365itpros.com and practical365.com. I uploaded the PDF files for the two books to the agent so that the agent now reasons over the two websites and two PDF files (Figure 1). You might notice that I have disabled the options for the AI to use its LLMs and to search public websites when composing answers. That’s because I want the agent to limit its responses to the set of defined knowledge sources.

The upload dialog says that files cannot be “labeled Confidential or Highly Confidential or contain passwords.” This might reflect old information as Microsoft has support for files protected by sensitivity labels in preview. The implementation seems very like support for sensitivity labels in Bizchat in that a user cannot access a file protected by a label if the label doesn’t grant them access to the content. I also assume that Copilot Studio will eventually support the DLP policy for Microsoft 365 to stop confidential files with specific labels being used as knowledge sources.

It can take some time for Copilot Studio to process uploaded files to prepare their content for reasoning, depending on their size. Office 365 for IT Pros is a 1,280-page 27 MB eBook, so it took several hours before Copilot Studio declared the file to be ready. You can upload a maximum of 500 files as knowledge sources for an agent.

Updating the Copilot Agent Instructions

Next, I adjusted the instructions for the agent. Here’s what I used:

• Respond to requests using information from specific curated websites and the files uploaded as knowledge sources.
• Ensure the information is accurate and relevant to the topic.
• Provide well-structured and engaging content.
• Avoid using information from unverified sources.
• Maintain a professional and informative tone.
• Be responsive and prompt in handling requests.
• Focus on topics related to Microsoft 365 and Entra ID technology.
• Write in a professional, clear, and concise manner.
• Output PowerShell code formatted for easy copying and use by readers.
• Ensure the PowerShell code is accurate and functional.
• Do not guess when answering and create new PowerShell cmdlets that don’t exist. Always check that a cmdlet exists before using it in an answer.

Coming up with good instructions for an agent is an art form. I’m sure that these can be improved, but they work.

Publish the Copilot Agent to SharePoint Online

The next task is to publish the agent. To publish the agent to a SharePoint Online site, I selected SharePoint as the target channel (Figure 2) and then selected the site that I wanted to host the agent. I suspect that Copilot Studio caches site information because it wasn’t possible for search to find a new site for several hours after the site’s creation. Publishing to a site creates an .agent file in the default document library in the site.

An agent can only be deployed to a single site. If you make a mistake and deploy the agent to the wrong site, you’ll need to undeploy and remove the site from the agent configuration and then deploy the agent to the correct site.

Out of the box, the only person who can use the agent at this point is the publisher. To make the agent available to all site members, a site administrator needs to mark the agent as approved. The agent then shows up in the list of agents accessed through the Copilot button in the meu bar. Any user with a Microsoft 365 Copilot agent can use the agent as part of their license. Access for other users must be paid for on a pay-as-you-go basis.

Using the Copilot Agent in SharePoint

Interacting with the agent to ask questions from the knowledge contained in Office 365 for IT Pros is just like any other Copilot interaction. Compose a prompt and submit it to the agent, which contemplates the request and responds based on the knowledge available to it (Figure 3).

SharePoint Online is not the only publication channel available to an agent. I also connect the agent to Microsoft 365 and Teams. Figure 4 shows how to chat with the agent in Teams.

The Only Downside is Our Monthly Updates

We know that Office 365 for IT Pros is a big eBook. Sometimes it’s hard to find the precise information that you’re looking for using the standard search facilities. Being able to have an agent reason over the books (and optionally, associated web sites) is an excellent way to have AI do the heavy lifting of finding and extracting knowledge in a very accessible way. The only downside is that you need to update the agent with the new files and republish to the target channels after we release our monthly updates. But that’s not a difficult task – and I am sure that a way will be found to automate the step in the future.

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

Another Fall in Organic Traffic Because People Get What They Need from Generative Summaries

Last November, I wrote about the impact generative AI was having on technology websites. Things have become tougher since with the introduction of generative summaries. Take Figure 1 as an example. I asked Google a question and instead of responding with a list of websites that might contain good answers, Google generates a summary overview of the available information. There’s no need to go anywhere near the article that I published on June 6 because there’s enough information available in the summary to answer the question for most people.

Bing has its own take on generative summaries. I didn’t use it as an example because Bing search results are so horribly bad, especially when it comes to finding content in my site.

The result of the Google changes is a further decline in website traffic. And it’s not just me saying that this is the case. A recent Bain & Company survey found that “80% of US consumers rely on “zero-click” search results, meaning they get the information they need from the search engine’s results page and don’t click through to another website.”

Bain attributes the change in user behavior to the effect of AI search engines and generative summaries, resulting in a 15% to 25% reduction in organic web traffic, or page views created by people who find a website through unpaid search engine results (the listings displayed by Google, Bing, and other search engines) rather than through paid advertising or other marketing channels.

Why Does Falling Organic Traffic Matter?

The thing about generative AI is that it can only generate based on knowledge that exists in its LLMs or can find in a website. Generative AI doesn’t create new knowledge: to some extent, generative AI steals and reuses the work done by many people to understand, analyze, document, and discuss information about all the different topics indexed by the search engines and eventually create those generative summaries.

The model works when search engines directed everyone to the source websites. Those who write are happy that the web views recorded for their site reflect interest in their work. They might also benefit from advertising on the site. Depending on the page views, the revenue from advertising might be enough to live on. More usually, it might cover the domain and hosting fees.

Sites run by commercial companies to publicize their offerings commonly publish information to attract people to the site. The quality of the information varies greatly. Some (CodeTwo Software is an example in the Microsoft 365 space) is well written and very useful. Other sites hype up the problems solved by their current product (the need to spend lots of money to manage Entra ID apps is a common theme today) or dramatically over-emphasize why their product is needed. One example in that category is a site that tells people to run the EDBUTIL utility to defragment Exchange Server databases (last needed with maybe Exchange 2003).

From what I can see from the data for several websites, new content still receives attention and high page views because it is often linked to notifications sent via email, Twitter, Bluesky, or other media channels. A few days later, that material will be absorbed by AI and become less valuable in terms of driving the page views that search engines once sent to the host sites.

Writers Will Stop Sharing Content

The point is that if people and companies don’t see a return on their investment, they won’t write as many articles as they have in the past. A well-written and researched article might take four to six hours to put together, and longer if some PowerShell or other code examples are needed. Who wants to put in that effort, or pay writers to do that work, if page view numbers are continuing to fall month-over-month. Life is too short to throw away hours of effort for no reward (fiscal or just the pleasure of knowing that people read your content).

A real strength of technical communities focusing on topics like Exchange, SharePoint, Teams, and development technologies has been the willingness of people to share their knowledge and expertise, except perhaps via paid subscriptions to Substack or Patreon sites where exclusive access to content can be offered, perhaps for a period before open publication.

If open access to knowledge weakens, we will all be worse off. No amount of generative AI can guide people to a solution that hasn’t ever been documented. The information in the LLMs will gradually degrade because less new knowledge is being publicly shared. Over time, new knowledge might become less and less available to the LLMs and generative AI will become less valuable because it can only output old material.

Publishing the 2026 Edition

For now, the content shared on office365itpros.com will remain public and open to all. I have considered using Substack to host articles that aren’t related to book updates, with free subscriptions to that content for people who buy the Office 365 for IT Pros eBook. We might still go down that route, but for now we’re concentrating on publishing the 2026 edition on July 1, 2025.

I’m interested in hearing what people think about the effect AI has on content that many depend on to do their job. Please let us know your thoughts by posting a comment.

Running Graph API Requests and Checking the Response

Whenever I need to run a Graph API request where a Microsoft Graph PowerShell SDK cmdlet isn’t available (or doesn’t work as expected), my normal go-to solution is the Invoke-MgGraphRequest cmdlet. The cmdlet works well and is extremely useful when testing a new API because it uses the authenticated connection established by the Connect-MgGraph cmdlet. In other words, you don’t need to obtain an access token to run requests because the cmdlet uses the token held by the session, including the scopes (permissions) detailed in the token.

The Graph Explorer App and Its Permissions

However, sometimes the Invoke-MgGraphRequest cmdlet comes up short and a different tool is needed for testing. That’s where the Graph Explorer can help. Like the Microsoft Graph PowerShell SDK, the Graph Explorer is implemented as an enterprise Entra ID app (appid de8bc8b5-d9f9-48b1-a8ad-b748da725064). And like the Microsoft Graph PowerShell Command Line tools app, the Graph Explorer app accumulates a set of delegated permissions over time as consent for permissions is granted to allow requests to run (that’s why the Graph Explorer UI includes a prominent Modify Permissions button).

The permissions allow signed-in users to run Graph API requests and access data available to them. Sometimes too many permissions can get in the way of testing, so it’s a good idea to review the permissions and remove any that seem not to be necessary.

Running an eDiscovery Purge Job

In this case, I was experimenting with the eDiscovery method to purge mailbox data based on a search. This is not the compliance search purge action. It’s an action to purge data found by eDiscovery premium searches. The Clear-MgSecurityCaseEdiscoveryCaseSearchData SDK cmdlet runs purge requests, using a command this:

Clear-MgSecurityCaseEdiscoveryCaseSearchData -EdiscoveryCaseId $Case.Id -EdiscoverySearchId $Search.Id -BodyParameter $PurgeParameters

The problem is that the cmdlet only reports failures (like a malformed payload). It doesn’t report the successful submission of the background purge job it creates, nor does it report the progress and eventual result of the purge job. Submission is like lobbing a stone into a deep black pit.

At first glance, using Invoke-MgGraphRequest doesn’t do any better. Once again, nothing happens, and no insight is available into the progress of the purge job.

$Uri = ("https://graph.microsoft.com/v1.0/security/cases/ediscoveryCases/{0}/searches/{1}/purgeData" -f $Case.Id, $Search.Id)
Invoke-MgGraphRequest -Uri $Uri -Body $PurgeParameters -Method POST

The documentation for the API says that a successful submission returns a 202 Accepted response code, and a response header containing the location of the Purge data operation created to commit the purge. The question is how to see that information.

Graph Explorer Reveals Responses

The Graph Explorer is designed to be a training and debugging tool. As you can see in Figure 1, it displays the 202 Accepted response, and it shows the response header. To see what’s happening with the purge job, copy the location URL and run a GET request against it (in Graph Explorer or using Invoke-MgGraphRequest) and you’ll see details such as the current progress of the purge job.

Invoke-MgGraphRequest Comes Through in the End

You can’t run Graph Explorer in a script. Although the app is great for testing, it can’t work in a production environment. All of which brought me back to the Invoke-MgGraphRequest documentation, where I discovered the ResponseHeadersVariable parameter, which outputs response headers to a variable if generated by an API request. We can’t see the 202 response for a job submission, but we can fetch details of the purge job by extracting the URI from the variable and using it to query the job status. Apparently, the purge succeeded!

Invoke-MgGraphRequest -Uri $Uri -Body $PurgeParameters -Method POST -ResponseHeadersVariable Response

[string]$ResponseLocationURI = $Response.Location
$ResponseURI = [system.uri]$ResponseLocationURI

$ResponseData = Invoke-MgGraphRequest -Uri $ResponseURI -Method Get

Name                           Value
----                           -----
createdDateTime                05/06/2025 13:44:58
id                             f580a3b0c72b4c849912520e04bc39e7
percentProgress                100
@odata.context                 https://graph.microsoft.com/v1.0/$metadata#security/cases/ediscoveryCases('7fc26cf0-bc8d-421c-8ad1-bea9782f564c')/operations/$entity
action                         purgeData
status                         succeeded
@odata.type                    #microsoft.graph.security.ediscoveryPurgeDataOperation
completedDateTime              05/06/2025 13:47:23
createdBy                      {[user, System.Collections.Hashtable], [application, ]}

The learnings here are that the Graph Explorer is a very useful debugging tool and that you should check every cmdlet parameter, even for cmdlets that have become second nature.