Changes to MDO P2 to Remove Requirements to License All Shared Mailboxes

Last August, I wrote about the issue of unexpected costs for Microsoft 365 customers when Microsoft Defender for Office 365 Plan 2 (MDO P2) was enabled in a tenant because MDO P2 is included as a service plan in Office 365/Microsoft 365 E5 licenses. No administrator action is required to use MDO P2; the presence of an E5 license is enough to activate its protection.

According to the MDO service description (August 2025), when MDO P2 is used by a tenant, “licenses must be acquired for users or mailboxes falling under one or more of the following scenarios:

• All Exchange Online users on the tenant. This is because Plan 2 features and capabilities protect all users in the tenant.
• All shared mailboxes on the tenant.”

In other words, the presence of just one E5 license automatically invokes the need for MDO P2 licenses for every Exchange Online user and shared mailbox. Buying MDO P2 at $5/user/month to remain compliant quickly racks up a substantial bill.

Group mailboxes also benefit from MDO P2 protection, but the service description makes no mention of a license requirement for these mailboxes, despite the efforts made by Microsoft over the years to give group mailboxes equivalent functionality to shared mailboxes.

Removing Inconsistency and Incoherence

In short, inconsistencies and incoherence abounded in the MDO P2 licensing requirements. The MDO team agreed to take the issue away to see what could be done to improve matters, and now they’ve come back with a revised licensing scheme.

The big change is the removal of the requirement for MDO P2 licenses for all user and shared mailboxes when E5 licenses are present. The previous position was indefensible and it’s good that Microsoft agreed.

Instead of a “MDO P2 licenses required for all mailboxes” approach, Microsoft uses the “if you benefit from a feature, you pay for a feature” rule that already applied to MDO P1 licensing. The new licensing terms are shown in FIgure 1:

Microsoft Defender for Office 365 P2 can be licensed through any of the following:

“Microsoft Defender for Office 365 Plan 2 standalone, Microsoft 365 E5/A5/G5, Office 365 E5/A5/G5, Microsoft Defender Suite/EDU/GOV/FLW, and Microsoft Defender + Purview Suite FLW provide the rights for a user to benefit from Microsoft Defender for Office 365 Plan 2.”

In other words, tenant administrators must decide which mailboxes should benefit from MDO P2 and then license those mailboxes accordingly. Licensing is automatic for accounts with E5 licenses because the MDO P2 service plan is already present. Shared mailboxes that tenants want to receive MDO protection will need to be licensed.

Custom Policies Required to Scope MDO Coverage

Unless a tenant licenses every user and shared mailbox, the new licensing arrangement means that administrators must create custom scoped policies to enable the MDO P2 safe links, safe attachments, and anti-phishing features for target groups rather than using the scope of the default policy to “cover everyone.” The target group can include user and shared mailboxes.

In large tenants, several custom policies will probably be required to cover different target groups. Dynamic distribution groups aren’t supported for scoped policies, but dynamic Microsoft 365 Groups are. Using dynamic Microsoft 365 Groups creates the requirement for Entra P1 licenses for all users that are members of a dynamic group.

One issue is that the membership rules for dynamic Microsoft 365 Groups don’t offer an off-the-shelf way to find shared mailboxes. Shared mailboxes will need to be marked in some manner such as a value in a custom attribute to allow a membership rule to find and include their accounts in group membership. On the upside, a dynamic Microsoft 365 Group to find shared mailboxes for MDO protection can also assign the MDO P2 license to the mailboxes.

I can see why Microsoft has gone down the path of using custom scoped policies to target the mailboxes to receive MDO protection. It’s a feature that already exists and works, but I’m not sure how much use custom scoped MDO policies get in the real world because I have never used these kinds of policies. I’m also unsure about the amount of administrative effort that will be necessary to set up and maintain the policies, especially in large tenants.

Group Mailboxes Don’t Need MDO Licenses

No mention is made about the group mailboxes used by Microsoft 365 Groups. This might be because Microsoft 365 Groups come about through the creation of other Microsoft 365 objects, like Teams and group-connected SharePoint Online sites. By contrast, creating a shared mailbox is a standalone operation to support the work of a team or to preserve a leaver mailbox, so it could be argued that it would be unfair to insist on licensing the automatic operation. In any case, I suspect that some debate will continue on this point.

Guiding Principles

The new licensing arrangement for MDO P2 can be broken down into four guiding principles:

1. MDO licenses are required for any mailbox (or rather, the user account that the mailbox belongs to) that comes within the scope of an MDO policy to enable features like safe link and safe attachments.
2. The majority of MDO processing happens during mail flow delivery to mailboxes. If a mailbox comes within the scope of an MDO policy (including a policy covering all mailboxes), it gets the benefit of the MDO features. If the account isn’t within the scope of an MDO policy, it doesn’t.
3. When considering the protection of shared mailboxes, only include shared mailboxes that actively receive external email that require protection. Exclude shared mailboxes like those used to retain leaver data (use inactive mailboxes instead), defunct mailboxes (consider their removal), and mailboxes used exclusively to process internal email.
4. MDO licenses don’t need to be assigned to the accounts that own shared mailboxes. All Microsoft requires is that the tenant has sufficient MDO licenses to cover the user and shared mailboxes that come within the scope of MDO policies.
5. Accounts that benefit from MDO P2 features must be licensed for those features.

The new MDO licensing arrangement is better, but it requires more thought and action from tenant administrators, especially to configure and maintain policies to make MDO P2 features available to user accounts.

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.

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

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%PackagesMSTeams_8wekyb3d8bbweLocalCacheMicrosoftMSTeamsEBWebViewLocal 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%PackagesMSTeams_8wekyb3d8bbweLocalCacheMicrosoftMSTeamsEBWebViewWV2Profile_tfwNetwork 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.

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!

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.

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.

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.

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.

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

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.

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_MACHINESOFTWAREPoliciesMicrosoftEdgeLocalNetworkAccessAllowedForUrls]
"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!