Microsoft Adds Last Used Property for Authentication Methods

The Microsoft 365 User Password and Authentication report is one of the scripts that I pay attention to and attempt to keep up to date as new developments emerge. The last version (V1.4) dealt with a change in how the default MFA method is reported; the version before added details of the authentication methods configured for user accounts.

Now it’s time to go back to refresh the script again because Microsoft has refreshed the beta version of the list authentication methods API to add a last used date time property. Entra ID updates the property when the authentication method (SMS code, passkey, Microsoft authenticator app, and so on) is used to authenticate an account. Looking at the dates in my tenant, I see last used dates going back to January 2023. There might be earlier dates than this noted for some authentication methods, but the point is that this information is now available.

The Value of the Last Used Property

The value of the last used property is that if you know what authentication methods are in active use, you might be able to remove unused authentication methods from user accounts to reduce the available attack surface for those accounts.

In any case, knowing when authentication methods are in active use for accounts is good information to have, especially if you want to encourage (“nag”) people to move away from weak secondary authentication methods like SMS and use something stronger, like the authenticator app or passkeys.

Updating the Script to V1.5

In any case, it was time to break out Visual Studio Code to update the Microsoft 365 User Password and Authentication script. The code uses the Get-MgUserAuthenticationMethod cmdlet to fetch authentication methods for an account. Each method has an identifier, and the more interesting information is found in the additionalProperties property (array). You’ll need at least the UserAuthMethod-MicrosoftAuthApp.Read.All Graph permission to access this information:

[array]$AuthMethods = Get-MgUserAuthenticationMethod -UserId $User.Id -ErrorAction Stop
$AuthMethods

Id
--
28c10230-6103-485e-b985-444c60001490
3ddfcfc8-9383-446f-83cc-3ab9be4be18f
338e704e-bb5c-4b0d-9c2e-458e630e4017

Microsoft updated the Microsoft Graph PowerShell SDK to V2.32 earlier this month. So far, the release has proven stable, and I haven’t run into new problems. It includes the Get-MgBetaUserAuthenticationMethod cmdlet, which returns the last used property:

[array]$AuthMethods = Get-MgBetaUserAuthenticationMethod -UserId $User.Id -ErrorAction Stop
$AuthMethods

Id                                   CreatedDateTime     LastUsedDateTime
--                                   ---------------     ----------------
28c10230-6103-485e-b985-444c60001490 30/05/2020 07:48:05
3ddfcfc8-9383-446f-83cc-3ab9be4be18f
338e704e-bb5c-4b0d-9c2e-458e630e4017                     04/08/2025 06:27:29

Not all authentication methods update the created date and last used date properties, but enough do to make the properties worthwhile.

The interesting thing here is that the cmdlet now surfaces the created date time as a property instead of an item in the additionalProperties array. This change is likely due to an update to the underlying Graph API metadata, and it could result in some scripts breaking if, as expected, the change makes it through to production. I certainly had to make some code changes to accommodate the change in how the created date is exposed. Figure 1 shows some example output where the last used date is reported for two authentication methods.

It would be nice if the data provided for every authentication method was consistent, but it’s not. It’s just another challenge to solve when working with Graph data.

New Version Available from GitHub

The updated (V1.5) version of the script can be downloaded from the Office 365 for IT Pros GitHub repository. I make no claim of greatness for the code. It’s there for people to learn about how to access and use the Graph to interact with authentication methods. No doubt this will interest some and not others. Feel free to upgrade and enhance the code to meet your requirements.

Learn about managing Entra ID and the rest of the Microsoft 365 ecosystem 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.

New Management Wants to Reimagine Outlook but That Doesn’t Mean That the New Outlook Client is Dead

A Tom Warren report in TheVerge.com that Outlook is getting an AI overhaul under new leadership (reported here in an accessible form) certainly caused the imagination of some commentators to go into overdrive. Unfortunately, the conclusions reached are impractical and unlikely. Let me explain why.

The article reported that Gaurav Sareen, corporate VP of global experiences and platform at Microsoft wants the Outlook developers to reimagine how Outlook can serve users by using AI to process email in a much more proactive manner than happens today.

Essentially, Outlook should be like a hyper-efficient assistant that processes email to relieve mailbox owners of the need to review and decide how to handle messages. According to the internal memo seen by Warren, Sareen wants developers to take a new approach: “Instead of bolting AI onto legacy experiences, we have the chance to reimagine Outlook from the ground up.” More importantly, Sareen wants work to happen faster with teams “prototyping and testing in days, not months.”

Senior managers have a habit of laying out grand plans when they take over new responsibilities. That’s OK, because it’s important to have a vision for where a product or technology is heading, so no one can criticize Microsoft executives for setting out how they think development teams should react to the current state of the market and customer demand.

However, Outlook is in the middle of a transition to fulfil the “One Outlook” vision of clients that deliver the same functionality on Windows, Mac, browsers, and mobile clients. The transition from Outlook classic is ongoing, and while I have been critical of the rate of progress and the implementation of some features (like the very slow export to PST), there’s no doubt that Microsoft is making progress. The eventual goal is to be able to transition away from Outlook classic by the time support for the classic client finishes in 2029.

The need to deliver certainty to corporate customers means that it makes zero sense for commentators to conclude that Microsoft will now dump the new Outlook in favor of some AI-infused client that must be designed from the ground up to replace Outlook classic, OWA, Outlook mobile, and the new Outlook.

Microsoft’s Outlook Commitment to Microsoft 365 Customers

Microsoft has a commitment to Microsoft 365 customers to deliver a solid version of Outlook as part of the Microsoft 365 enterprise apps suite. Changing course now to incorporate new AI-powered functionality might sound exciting, but it ignores the simple fact that Microsoft 365 Copilot licenses are not possessed by many tenants, and without Copilot and access to AI-powered features, the vision outlined by Sareen cannot be achieved.

I don’t think Microsoft is willing to give away Copilot licenses just to enable AI features in Outlook. That move wouldn’t go down well with shareholders who look at the massive investments made to build out datacenter capabilities for AI without a clear line of sight about how these investments will deliver revenues.

Microsoft is coy about many Microsoft 365 Copilot licenses they’ve sold. No one knows how many Microsoft 365 Copilot licenses are in active use, but I’m willing to bet that the number of Copilot licensees is hundreds of millions removed from the number of Outlook users. The latest data from the Microsoft FY26 Q1 results indicate that Microsoft 365 has around 446 million paid seats. Let’s say that 400 million of these people use Outlook. That’s a lot of additional AI processing that might be required to deliver a new AI-infused Outlook client, which is why I think that any strategy based on dramatically increasing the amount of AI processing in Outlook will run into the cold brick wall of financial reality.

There’s also the need for Microsoft to deliver a client Exchange Server after Outlook classic retires. This client is unlikely to have as many AI-powered features because it’s much harder to deliver those features in on-premises environments than it is in the cloud.

Evolutionary AI Additions to Outlook

What I think will happen is that Microsoft will continue to press ahead with its One Outlook strategy to equip the new Outlook with equivalent functionality (and more) than is currently available in Outlook classic. It just makes sense for Microsoft to get Outlook to a common code base for multiple platforms.

At the same time, during the period up to 2029 when Microsoft’s committed support for Outlook classic ceases, Microsoft will implement important AI-powered features in Outlook classic to keep corporate customers happy.

At the same time, I believe that Sureen’s memo will force the Outlook development teams to respond with proposals to become more aggressive about bringing AI-powered features into Outlook based on the new Outlook framework. I don’t see any appetite for a third Outlook flavor over the next few years (Outlook classic, new Outlook, and Outlook AI++). That’s not how Microsoft works, especially in a space where they need to keep large corporate customers happy and don’t want to see support costs escalate due to client profusion.

Customer Support and Expectations Moderate Grand Plans

As noted above, new leaders invariably have new ideas about how to move products forward. Just because some of those ideas leak outside is no reason to conclude that Microsoft will suddenly switch course for a product used by hundreds of millions of people. The practical issues of customer expectations and long-term support are enough to moderate even the most radical of new leader ideas. I suspect that the same will happen here. Stay calm and take some happy pills.

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.

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.