Use Microsoft Graph PowerShell SDK Cmdlets to Maintain the Entra ID Custom Banned Password List

Vasil Michev is busy these days. Apart from his day job, he’s doing the technical reviews for the Office 365 for IT Pros (2026 edition) and Automating Microsoft 365 with PowerShell (2^nd edition) eBooks, both due for release on July 1, 2025. Technical editing is an important part of our publication process because it’s an annual end-to-end review of all content to help authors refine their chapters, eliminate old and unnecessary text, and consider what they should be covering.

And still Vasil finds time for his own writing, such as a recent article about using the Microsoft Graph PowerShell SDK to update the banned password list for Entra ID accounts. Given that the Graph PowerShell SDK is a major topic for Automating Microsoft with PowerShell, my attention was immediately drawn to the article to understand what it described and consider it for inclusion in the book. It is now, along with 350+ pages of other PowerShell content about automating different aspects of Microsoft 365 activities.

Global Banned Password List

The Entra ID password protection feature maintains a global list of banned passwords. Microsoft maintains the list and updates it on an ongoing basis from telemetry for Entra ID authentication. All attempts to change account passwords are checked against the global banned list to make sure that the new password is reasonably strong. In other words, it’s not something like “Mypassword” or “Cats.” Tenant administrators cannot affect how Entra ID uses the global list of banned passwords, nor can they add or remove values from the list. It’s just part of how Entra ID works, and this part of password protection is included in the version of Entra ID included with all Microsoft 365 tenants.

Custom Banned Password List

If a tenant has Entra P1 or P2 licenses, they can implement a custom banned password list. The custom list supplements the global banned password list. The custom list is limited to 1,000 entries, but those entries are “key base terms” of between 4 and 16 characters. In other words, Entra ID blocks variations and combinations of the terms in the custom banned password list.

When a custom banned password list is available, Entra ID combines its entries with the global banned password list. The idea is that tenants might want to stop people using organization-specific terms like the names of locations or buildings in passwords because these terms might be easy for attackers to guess in a spray attack. Of course, you shouldn’t be depending on passwords and should deploy multifactor authentication to protect accounts, but it’s worthwhile protecting passwords as much as possible.

Blocking Passwords

Figure 1 shows some of the entries in the custom banned password list as viewed through the Entra admin center. You can see that the last entry is for “VictorMeldrew.” This is a key base term for password checking.

In Figure 2, an administrator has attempted to change an account password through the Microsoft 365 admin center. The password looks strong, but Entra ID rejects it because it includes a key base term. Telling the administrator that the password is easily guessable is just the way Microsoft chose to say: “can’t use that password.”

Updating the Custom Banned Password List with a Script

Vasil’s article covers the basics of creating a directory settings object to hold password protection settings, including the custom banned password list. I used that information to create a script that’s more like something you might use as production code, which you can download from GitHub.

The code:

• Checks if the correct permission (Directory.ReadWrite.All) is available to read, create, and update directory settings. This is a very high-level permission that should be restricted as tightly as possible. You should also monitor the apps that hold this permission to make sure that they are used correctly.
• Import a list of key base terms from a CSV file and checks that each term is at least 4 and no more than 16 characters long.
• Uses the Get-MgBetaDirectorySetting cmdlet to check if a directory setting object for password protection is defined in the tenant. If not, the script runs the New-MgBetaDirectorySetting cmdlet to create and populate a new directory setting object with the list of key base terms (and other default values). The directory setting object is derived from the directory settings template for password rules. The template always has an identifier of 5cf42378-d67d-4f36-ba46-e8b86229381d.
• If a directory setting object for password protection is available, fetch the list of current key base terms and combine it with the new list to generate a combined list. The Update-MgBetaDirectorySetting cmdlet then updates the directory setting object with the combined list.
• Export the newly-updated list to a CSV file.

If you prefer to use the input CSV file as the definitive set of key base terms and not combine the input set with the current set, it’s easy to comment out the two lines that create a combined list.

The only semi-weird thing about the list of key base terms is that it uses tabs for delimitation (which is why the code splits the list using [char]9).

Hopefully the script is of some use. If not, I won’t be offended. Check out the 320-plus scripts in the Office365Itpros GitHub repository. You might find something more useful there!

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

New Service to Manage People Skills in an Organization

The April 23, 2025, announcement about the general availability of People Skills, “a powerful new data layer in Microsoft 365 Copilot” is now being followed by the deployment of People Skills to tenants as described in MC1060842 (last updated 3 June 2025, Microsoft 365 roadmap item 485726). Microsoft expects deployment to complete worldwide in mid-July 2025.

People Skills Licensing

Along with the deployment, MC1060845 says that Microsoft is updating Office 365 and Microsoft 365 licenses to include the People Skills Foundation service plan (PEOPLE_SKILLS_FOUNDATION, 13b6da2c-0d84-450e-9f69-a33e221387ca). According to the licensing section of the People Skills documentation, “People Skills comes with your Microsoft 365 or Viva licenses and doesn’t need a separate license.” Other People Skills licenses are available, and Microsoft once again is in danger of confusing customers with licensing. I think Figure 1 boils the licensing situation down to two buckets.

Users with the foundation service plan (included with licenses such as Office 365 E3) can “search to add skills from your taxonomy or imported skills to create a skills profile using the Microsoft 365 profile editor.” In other words, these users can access skill information through the Microsoft 365 profile card and Outlook’s Org Explorer and update their skills via the Microsoft 365 profile editor. Users with Microsoft 365 Copilot licenses can do more, like use the Skills agent to look for people with specific skills in the organization. Or as Microsoft puts it, the agent “helps employees and leaders explore, manage, and use organizational skills for personal growth and strategic planning.”

This list of where skills data appears in Microsoft 365 is worth reading. Not everything is available today, but you can see where Microsoft is heading.

Setting Up People Skills

Before any skills appear in public view, a tenant must go through the People Skills setup process. The setup option is available in the Settings (choose Viva, then data management) or Copilot sections of the Microsoft 365 admin center. Microsoft recommends a quick setup (Figure 2) to configure the People Skills service with default settings, including a skills library of some 16,297 different areas of expertise that people might have.

The setup process runs in the background and takes at least a day to finish. It seems like much of the time taken is to allow skills interferencing by AI to happen. This means that an AI agent examines the details of users and their activity (Graph-based access to email, Teams messages, and documents) to figure out what skills each user might have. For instance, someone with a “Software architect” job title probably knows something about software architecture, and their communications with other users will probably reveal what areas of software architecture they work in. If this sounds creepy, you can disable the feature using Viva policies managed through PowerShell.

For example, these commands reveal the set of features that can be managed through the PeopleSkills module and create a new policy to disable skills interferencing for members of a specific distribution list:

Get-VivaModuleFeature -ModuleId PeopleSkills

Add-VivaModuleFeaturePolicy -Module PeopleSkills -FeatureId SkillsInferencing -IsFeatureEnabled $false -GroupIds NoSkills@office365itpros.com -Name TurnOffSkillsInterferencing

The Get-VivaModuleFeatureEnablement cmdlet checks if the feature is disabled for a user:

Get-VivaModuleFeatureEnablement -ModuleId PeopleSkills -FeatureId SkillsInferencing -Identity Marty.King@office365itpros.com

FeatureId         Enabled
---------         -------
SkillsInferencing   False

Note that if Skills inferencing has already happened for a user, it will take several days for the information to disappear from their user profile. Speaking of profiles, Figure 3 shows how AI-inferenced skills appear in my Microsoft 365 profile card. The skills listed here aren’t confirmed. In other words, they are skills that the AI agents thinks that I might have based on the knowledge available to it (I won’t get upset by the poor spelling of PowerShell).

I’m not sure about some of these skills (like decision making). By selecting the Update your profile option, I can select which skills I agree I have (Figure 4), add some more skills that the AI overlooked by selecting from the skills inventory, and confirm the set. Confirmed skills show up with a blue tick mark when people view the profile card.

Graph API

A ListSkills Graph API is available for the Profile resource type to list the set of skills for a user account. The API uses the User.Read delegated permission and no application permission is available. In other words, you can’t use the API to create a report of skills for every user in the organization. Here’s how to use the Get-MgBetaUserProfileSkill cmdlet from the Microsoft Graph PowerShell SDK to list the skills of the signed in user:

Get-MgBetaUserProfileSkill -UserId (Get-MgContext).Account | Sort-Object DisplayName | Format-Table DisplayName, allowedAudiences, CreatedDateTime

DisplayName                              AllowedAudiences CreatedDateTime
-----------                              ---------------- ---------------
Application Development                  organization     11/06/2025 08:46:52
Application Programming Interfaces (API) organization     11/06/2025 08:46:52
Artificial Intelligence (AI)             organization     11/06/2025 08:46:53
Business Intelligence (BI)               organization     11/06/2025 08:46:53
Business Management                      organization     11/06/2025 08:46:52
Business Negotiation                     organization     11/06/2025 08:46:52
Change Management                        organization     11/06/2025 08:46:53

Some People Skills Oddities

Of course, the combination of skills determined by AI and the user might not actually be true. I could claim to be a Hyper-V expert (I’m not), and the AI might think that I know something about SharePoint Online because I’ve written about the topic often. Oddly, the AI concluded that I know something about Exchange but not about SharePoint, Teams, Planner, or other Microsoft 365-related topics. Although PowerShell is a skill, Microsoft Graph isn’t listed in the skills inventory. I tried to add some custom skills by following the steps in the documentation (requiring a CSV upload to SharePoint is bizarre), but the admin center couldn’t find the CSV uploaded to a site that I owned, no matter what form of a path I used.

The skills used by the latest iteration of skill highlighting and management within Microsoft 365 are not the same as those captured in SharePoint Online or Delve (User Profile Application or UPA skills). According to the documentation, once you enable People Skills, the UPA skills are hidden from the user profile card. This might happen in the future, but I see both sets of skills listed today. Another future is migration of UPA skills to People Skills. Microsoft says that this will happen but hasn’t yet clarified how or when. Perhaps migration isn’t in their current skill set?

Support the work of the Office 365 for IT Pros team by subscribing to the Office 365 for IT Pros eBook. Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365.

Another Fall in Organic Traffic Because People Get What They Need from Generative Summaries

Last November, I wrote about the impact generative AI was having on technology websites. Things have become tougher since with the introduction of generative summaries. Take Figure 1 as an example. I asked Google a question and instead of responding with a list of websites that might contain good answers, Google generates a summary overview of the available information. There’s no need to go anywhere near the article that I published on June 6 because there’s enough information available in the summary to answer the question for most people.

Bing has its own take on generative summaries. I didn’t use it as an example because Bing search results are so horribly bad, especially when it comes to finding content in my site.

The result of the Google changes is a further decline in website traffic. And it’s not just me saying that this is the case. A recent Bain & Company survey found that “80% of US consumers rely on “zero-click” search results, meaning they get the information they need from the search engine’s results page and don’t click through to another website.”

Bain attributes the change in user behavior to the effect of AI search engines and generative summaries, resulting in a 15% to 25% reduction in organic web traffic, or page views created by people who find a website through unpaid search engine results (the listings displayed by Google, Bing, and other search engines) rather than through paid advertising or other marketing channels.

Why Does Falling Organic Traffic Matter?

The thing about generative AI is that it can only generate based on knowledge that exists in its LLMs or can find in a website. Generative AI doesn’t create new knowledge: to some extent, generative AI steals and reuses the work done by many people to understand, analyze, document, and discuss information about all the different topics indexed by the search engines and eventually create those generative summaries.

The model works when search engines directed everyone to the source websites. Those who write are happy that the web views recorded for their site reflect interest in their work. They might also benefit from advertising on the site. Depending on the page views, the revenue from advertising might be enough to live on. More usually, it might cover the domain and hosting fees.

Sites run by commercial companies to publicize their offerings commonly publish information to attract people to the site. The quality of the information varies greatly. Some (CodeTwo Software is an example in the Microsoft 365 space) is well written and very useful. Other sites hype up the problems solved by their current product (the need to spend lots of money to manage Entra ID apps is a common theme today) or dramatically over-emphasize why their product is needed. One example in that category is a site that tells people to run the EDBUTIL utility to defragment Exchange Server databases (last needed with maybe Exchange 2003).

From what I can see from the data for several websites, new content still receives attention and high page views because it is often linked to notifications sent via email, Twitter, Bluesky, or other media channels. A few days later, that material will be absorbed by AI and become less valuable in terms of driving the page views that search engines once sent to the host sites.

Writers Will Stop Sharing Content

The point is that if people and companies don’t see a return on their investment, they won’t write as many articles as they have in the past. A well-written and researched article might take four to six hours to put together, and longer if some PowerShell or other code examples are needed. Who wants to put in that effort, or pay writers to do that work, if page view numbers are continuing to fall month-over-month. Life is too short to throw away hours of effort for no reward (fiscal or just the pleasure of knowing that people read your content).

A real strength of technical communities focusing on topics like Exchange, SharePoint, Teams, and development technologies has been the willingness of people to share their knowledge and expertise, except perhaps via paid subscriptions to Substack or Patreon sites where exclusive access to content can be offered, perhaps for a period before open publication.

If open access to knowledge weakens, we will all be worse off. No amount of generative AI can guide people to a solution that hasn’t ever been documented. The information in the LLMs will gradually degrade because less new knowledge is being publicly shared. Over time, new knowledge might become less and less available to the LLMs and generative AI will become less valuable because it can only output old material.

Publishing the 2026 Edition

For now, the content shared on office365itpros.com will remain public and open to all. I have considered using Substack to host articles that aren’t related to book updates, with free subscriptions to that content for people who buy the Office 365 for IT Pros eBook. We might still go down that route, but for now we’re concentrating on publishing the 2026 edition on July 1, 2025.

I’m interested in hearing what people think about the effect AI has on content that many depend on to do their job. Please let us know your thoughts by posting a comment.

No MSOL Module, So How Can You Block Email-Based Subscriptions

By now, I assume that every Microsoft 365 tenant administrator knows about the deprecation of the MSOL and AzureAD PowerShell modules. The MSOL module is already retired; the Azure AD module will be retired any day now. Some of the cmdlets in the modules have already stopped working because of the withdrawal of a dependent service.

Which brings me to a note I read in a Microsoft article the other day solemnly informing me that I should block users from signing up for “viral” trial subscription of Copilot Studio by running the Set-MsolCompanySettings cmdlet to block ad-hoc or email-based subscriptions as follows:

Set-MsolCompanySettings -AllowAdHocSubscriptions $False

Of course, the cmdlet is now retired and unavailable, but as the page hasn’t been updated since October 2024, it strikes me that perhaps people haven’t noticed.

In any case, it’s terrifically difficult to maintain total accuracy in documentation for an area that is in a state of constant flux. After coping with change in Microsoft 365 for the last ten years to keep the Office 365 for IT Pros eBook updated, I think I’m an authority on this topic.

The more important issue raised by the documentation deficiency is what is the replacement for the Set-MsolCompanySettings cmdlet? There’s no mention of the cmdlet in Microsoft’s change map page, which helps people find equivalent commands in the Microsoft Graph PowerShell SDK.

No Block for Copilot Studio in the Microsoft 365 Admin Center

It all depends on what you want to do. In this case, the advice given in the page is how to block ad-hoc subscriptions of the type that Copilot Studio allows people to sign up for over a 60-day period. Although Microsoft 365 Copilot is on the list, Copilot Studio is not one of the products governed by the self-service settings in the Microsoft 365 admin center (Figure 1), so Copilot Studio can’t be blocked here or by using the MSCommerce PowerShell module. Copilot Studio uses email-based subscriptions to allow anyone to sign up using an Entra ID or other account, so that’s probably why it’s not on the self-service trials list.

Use the Entra Authorization Policy to Block Email-Based Subscriptions

This brings us to the Entra ID authorization policy. Using the Get-MgPolicyAuthorizationPolicy cmdlet (the Microsoft Graph PowerShell SDK cmdlet that maps the Get method for the resource) to examine the policy settings for my tenant, I see:

Get-MgPolicyAuthorizationPolicy | Format-List

AllowEmailVerifiedUsersToJoinOrganization : False
AllowInvitesFrom                          : everyone
AllowUserConsentForRiskyApps              : False
AllowedToSignUpEmailBasedSubscriptions    : True
AllowedToUseSspr                          : True
BlockMsolPowerShell                       : True
DefaultUserRolePermissions                : Microsoft.Graph.PowerShell.Models.MicrosoftGraphDefaultUserRolePermissions
DeletedDateTime                           :
Description                               : Used to manage authorization related settings across the company.
DisplayName                               : Authorization Policy
GuestUserRoleId                           : 2af84b1e-32c8-42b7-82bc-daa82404023b

The formal documentation for Set-MsolCompanySettings is no longer available, but some source text in GitHub defines the use of AllowAdHocSubscriptions as “to allow users to sign up for email based subscriptions.” That seem to match the AllowedToSignUpEmailBasedSubscriptions setting, so let’s see what happens if I update the setting to false by running the Update-MgPolicyAuthorizationPolicy cmdlet:

Update-MgPolicyAuthorizationPolicy -AllowedToSignUpEmailBasedSubscriptions:$false

The Policy.Read.All permission is required to read the policy settings, and the Policy.ReadWrite.Authorization permission is required to update policy settings.

After updating the policy settings, I removed the Microsoft 365 Copilot license from a user account. This license contains a service plan for Copilot Studio. Removing the license means that the user is forced to take out an email-based subscription to use Copilot Studio.

After going to the Copilot Studio page, the user can click the Try for free button to start their trial. After proving that they’re a human, the process detects that the user has an Entra ID account and asks them to sign in. After signing in, Entra ID checks the tenant authorization policy and declines to go further to complete the email-based subscription because of the policy block (Figure 2).

To revert, update the setting to true.

Update-MgPolicyAuthorizationPolicy -AllowedToSignUpEmailBasedSubscriptions:$true

The user can now complete the sign-in process and access Copilot Studio (Figure 3).

No One-to-One Mapping for the Old Cmdlet

My original question asked what is the replacement for the Set-MsolCompanySettings cmdlet? The answer is that there isn’t a single 1:1 replacement. The Entra ID authorization policy takes care of authorization settings for the tenant, such as email-based subscriptions and whether the tenant allows self-service password reset (SSPR). Some of the other settings are supported in the Entra admin center UX. As to changing tenant id or setting the default usage location for user accounts, I’ll have to go searching…

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

Use an OWA Mailbox Policy Setting to Block PST Access

A reader asked if it is possible to disable the ability of the new Outlook to open PST files, noting that some internet posts say that it’s not yet possible. One example from April 2025 points to the list of Microsoft 365 roadmap items related to PST files and suggests that support is coming.

Well, support is available through the OutlookDataFile setting in OWA mailbox policies. The default is to allow new Outlook clients to access PST files (a longstanding request for many people), but organizations that don’t want people to ever use PST files can easily block access.

Figure 1 shows the default access where users can add PST files for the client to open. As the note says, the current level of support extends to mail items only.

Good reasons exist to justify being able to open PST files. Access to old email is an obvious reason. eDiscovery investigations often use PST files to export mailbox items found by searches for review by external experts.

The downside of allowing access to PST files is the temptation for people to move items from mailboxes into PSTs. This action makes items invisible for compliance purposes. It also makes email inaccessible to AI tools like Microsoft 365 Copilot. More worringly, PSTs encourage bad behavior, such as people filling PSTs with email that they want to preserve when they leave a company. Using sensitivity labels blocks this habit because although users can keep protected items in a PST, they won’t be able to access the items if they can’t authenticate with an account that has access rights to the items.

Mailbox Policy Settings

An OWA mailbox policy is a collection of settings that govern how OWA works. Exchange Online supports multiple OWA mailbox policies, allowing administrators to create and assign different policies to user mailboxes.

The new Outlook is tightly linked to OWA, so it’s unsurprising to find that OWA mailbox policy applies to the new Outlook too, such as the setting to block downloading of attachments. In this case, OWA doesn’t support PST access at all, so the setting is unique to the new Outlook.

Block PST Access in the OWA Mailbox Policy

To block PST access, run the Set-OWAMailboxPolicy cmdlet to update the OutlookDataFile setting. This command updates the setting to Deny to block all access to PSTs:

Set-OwaMailboxPolicy -Identity OWAFullAccess -OutlookDataFile Deny    

The effect is shown in Figure 2. The Outlook Data Files option is now hidden.

Other values for the OutlookDataFile setting are:

• NoExport: Users can’t export from a mailbox to a PST.
• NoExportNoGrow: Users can’t export from a mailbox to a PST or copy items from a mailbox to a .pst file.
• NoExportNoOpen: Users can’t export from a mailbox to a PST, or open new PSTs.
• NoExportNoOpenNoGrow: Users can’t export from a mailbox to a .PST, copy items from a mailbox to a PST, or open new PST files.

These settings are the equivalent of the policy available to control PSTs in Outlook classic.

The effect of the new setting is not immediate. It takes time for Exchange Online to propagate the update to all the mailbox servers used by a tenant, and a further period before clients pick up and apply the setting. The time required might be as short as a few hours and as long as twelve hours. If you’re going to apply a block on PST usage, it’s best to implement the policy before people start to use the new Outlook.

PSTs are Ancient Baggage

Introduced in 1997, PSTs are an archaic part of the history of Exchange. Unfortunately, just like public folders (1996), customers can’t quite get rid of either. I guess we’ll just have to manage the beasts, which is what the mailbox setting described here does for PSTs in the new Outlook, aka Outlook designed for the 2030s dragging along ancient baggage…

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.

Old Message Tracing Components Will be Deprecated in September 2025

The June 3 announcement that the new Exchange Online Message Trace facility is generally available creates some work for Microsoft 365 tenant administrators who use message trace in scripts. The roll-out of the update will happen between mid-June and July 2025. Tenants that participated in the public preview and have V3.7 or later of the Exchange Online management module can already use the new Get-MessageTraceV2 and Get-MessageTraceDetailV2 cmdlets.

In the announcement, Microsoft says that they will deprecate the old message tracing UI from the Exchange admin center and the old Get-MessageTrace and Get-MessageTraceDetail cmdlets beginning September 1, 2025. Microsoft will also deprecate the background reporting web service that responds to requests for online message trace data at the same time. The deployment is limited to commercial tenants and doesn’t currently affect sovereign clouds because of the need to certify code upgrades for those environments.

Time Slipping Away to Upgrade Code

Microsoft will take care of updating the Exchange admin center. Customers and ISVs that depend on the old implementation of message tracing must complete their upgrade by the end of August 2025 before the deprecation cycle begins. If you don’t, the risk is that code will stop working without notice.

Twelve weeks seems like a reasonable amount of time to find and update code. However, we’re heading into a peak vacation period when availability of developers becomes more problematic, so now’s the time to get going.

Checking What’s Needed to Upgrade Scripts

To check out what’s needed, I upgrade two scripts. The first script reports email sent to external recipients by members of a distribution list. The second reports the numbers of outbound and inbound messages sent from domains (Figure 1). The updated scripts are both available in the Office 365 IT Pros GitHub repository (see links in the articles).

Updating the first script was easy. All I needed to do was swap out calls to the Get-MessageTrace cmdlet and replace them with Get-MessageTrace2.

The second script was harder because it used paging to fetch pages containing 1,000 message tracing records. Microsoft’s public preview announcement said that they removed support for pagination. The new mechanism behaves awfully like pagination in that you need to fetch message tracing events in batches of up to 5,000 records until all available data is retrieved. Unlike the pagination used by Graph-based APIs, next link URLs are not used to indicate the point the next set of events start. Instead, fetching based on a mixture of dates and email addresses.

An example is worth many words, so if you’re confused about how to fetch message tracing data, have a look at the script for the second example.

Extended Range of Historical Data Available

According to the public preview announcement, Microsoft plans to deliver the ability to query up to 90 days of historical message tracing data. Initially, Microsoft plans to have 30 days of historical message tracing data available online. However, a single query is limited to ten days, so fetching the message tracing data for 30 days requires three separate queries, each covering a 10-day period. If you fetch data for more than 10 days, Exchange responds with the error message:

Error fetching message trace data: ||The interval between StartDate and EndDate can’t be longer than 10 days.

Not a Difficult Transition

Moving to the new message tracing facility isn’t hard. It shouldn’t take too long to upgrade scripts as the changes are straightforward (and having an example helps). Time is likely to be the problem. Too many competing demands for PowerShell coding, too little time to get everything done.

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

Force Two-Click Confirmation to View Email Protected by Sensitivity Labels

Recently I noticed that OWA behaved differently when previewing email protected by sensitivity labels. Because it’s an online client, OWA has always been able to seamlessly retrieve the authorization to open and display protected messages from the rights management service. Now a message said that organization policies mandate clicking “View message” to access the email content (Figure 1).

It’s no big deal to comply with the demand for the extra click, but what organizational policies are at work here?

The New Setting for Two-Click Confirmation

The answer lies in the Exchange Online organization configuration, specifically the TwoClickMailPreviewEnabled setting. In my tenant, the setting is True, meaning that it’s enabled and forcing OWA to demand the extra click.

But here’s the thing. According to message center notification MC1041456 (26 March 2025, Microsoft 365 roadmap item 483883), the two-click requirement to view protected messages rolled out to general availability in early April 2025 and should be now be complete worldwide. The notification mentions encrypted emails. I have no idea if the feature extends to messages protected with S/MIME or another type of encryption other than Purview sensitivity labels. I hadn’t seen the behavior in OWA before because I’ve been using the new Outlook for Windows. According to MC1041456, the setting should affect that client too, but it doesn’t. The new Outlook ignores the TwoClickMailPreviewEnabled setting and opens protected messages without as much as a brief pause (Figure 2). Perhaps the client is awaiting an update to respect the setting.

The TwoClickMailPreviewEnabled setting doesn’t affect Outlook classic. That client uses a different mechanism to fetch authorization to open protected messages (to allow Outlook to work offline).

Configuring Two-Click Confirmation

A mismatch between documented setting and client behavior isn’t the only thing that’s odd about the information contained in MC1041456. First, the text refers to the setting being in the Microsoft Azure directory. It’s not. The setting is in the Exchange organization configuration. I’m not saying that the setting doesn’t exist somewhere in Entra ID (which I assume the text refers to), but the instructions given to maintain the setting use Exchange Online cmdlets.

MC1041456 asserts “By default, the two-click setting is off.” I checked by running the Get-OrganizationConfig cmdlet and found that the setting is true (enabled):

Get-OrganizationConfig | fl two*

TwoClickMailPreviewEnabled : True

Obviously, somewhere along the line between the message center notification appearing and now the setting had been changed, probably by me.  To reset the setting and remove the requirement for double clicks, I ran:

Set-OrganizationConfig -TwoClickMailPreviewEnabled $false

(MC1041456 refers to Boolean values. You can use $false or 0 to update the setting).

Prompts to use OneDrive

When checking out two-click confirmation, I noticed that both OWA and the new Outlook nag users to use OneDrive to share files rather than uploading copies of files as attachments (Figure 3). This is the effect of MC1053121 (last updated 15 May 2025) to have the Office apps prompt users to make more use of OneDrive. The update is now generally available. I don’t like this kind of nagging and recommend that organizations take the time to review the information in MC1053121 and consider if you want to block the nagging.

Two-Click Confirmation Can be Valuable

Microsoft doesn’t give any clues why they think it is a good idea to “require user confirmation before allowing access to encrypted emails.” My assumption is that the reason has to do with privacy. No one wants to have a confidential message pop up on screen when a chance exists that the information could be read by someone else.

However, in other situations where people have grown used to reading confidential messages without hindrance, they might find two-click confirmation a tiresome restriction on their workflow. The bad thing about the feature is that it’s either on or off for an entire tenant without any ability to grant exclusions.

Forcing the double click confirmation allows the recipient to wait until they’re sure that no one can look over their shoulder or otherwise see the content before going ahead. The volume of notifications that flood into tenants mean that features like this can go by without being noted by administrators. If administrators don’t know about a feature, it can’t be used. And that’s a bad thing.

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

aiInteractionHistory Graph API Available in June 2025

Microsoft 365 message center notification MC1080682 (22 May 2025, Microsoft 365 Roadmap item 491631) announces that the new Microsoft 365 Copilot Interaction Export API (aka, the aiInteractionHistory API) will roll out in June 2025. This is the same API that I covered in a Practical365.com article last December and the documentation still says that the API is available through the Graph beta endpoint. Perhaps the intention is to move the API to the V1.0 (production) endpoint when it’s officially released.

I don’t see much change in how the API works or the retrieved data since I last looked at it. A welcome change is that it is now possible to fetch a maximum of 100 records per request rather then ten. Fetching ten interaction records at a time made the API very slow. Although faster than before, the API is still slow, especially for an API designed to allow third-party apps and ISVs “to export Copilot user interaction data for processing in their security and compliance (S+C) applications.”

Other audit APIs support fetching up to a thousand records at a time. Maybe a V1.0 version of the API will support a higher value. Details of how the API works and an example script can be found in the original article.

Licenses and Permissions

The AiEnterpriseInteraction.Read.All Graph permission needed to access interaction data is not available as a delegated permission, meaning that the only way to access the data is through an app (including app-only interactive Microsoft Graph PowerShell SDK sessions). Weirdly, accounts used to run apps using the API to fetch interaction records must have a Microsoft 365 Copilot license.

What the aiInteractionHistory API Captures

According to Microsoft, the API “captures the user prompts and Copilot responses in Copilot private interactions chat and provides insights into the resources Copilot has accessed to generate the response.” This statement does not mean that the data lays bare the details of Copilot interactions. Some of the information needs to be mined and interpreted to make sense. For instance, here are the details of an interaction record:

Name                           Value
----                           -----
locale                         en-us
body                           {[content, [AutoGenerated]undefined<attachment id="fd3a9044-309c-4ec9-a568-676f1d521f24"></attachment><attachment id="01TAGX3U2ESA5P3HBQZFHKK2DHN…
from                           {[@odata.type, #microsoft.graph.chatMessageFromIdentitySet], [user, System.Collections.Hashtable], [application, ], [device, ]}
appClass                       IPM.SkypeTeams.Message.Copilot.Word
attachments                    {02 Managing Identities.docx, unknown-file-name}
contexts                       {02 Managing Identities.docx, unknown-file-name}
createdDateTime                25/04/2025 09:27:05
conversationType               appchat
interactionType                userPrompt
mentions                       {}
links                          {}
sessionId                      19:t67NyrXsxDyC8qGGCtSQZYjC3TV1lYvq3IkjzpXquUc1@thread.v2
id                             1745573225046
requestId                      GTbr3lBouCMpcP7L1qVv8Q.20.1.1.1.4
etag                           1745573225046

The appClass property tells us what Copilot app the interaction is for. In this case, it’s Copilot for Word. The attachments property tells us if any reference files are used. One is mentioned here, and given that the body property mentions AutoGenerated, we can conclude that this interaction occurred when Copilot for Word generated an automatic summary for a document.

The interactionType tells us that this record is for a user prompt. Responses from Copilot have aiResponse in the interactionType property. User prompts that aren’t for automatic summaries have the text of the prompt in the body property. For example:

Name                           Value
----                           -----
content                        What functionality isn't available with a Microsoft 365 retention policy
contentType                    text

aiInteractionHistory API requests require the identifier for a user account and the response is the records for that user. Details of the user are in the from property, but you’ll have to navigate to from.user.id to see the identifier for the user. A DisplayName property is available in the from structure but doesn’t hold the display name of the user.

Assuming that a third-party application wanted to retrieve the ai interaction history records and process the records for its own purposes, it’s obvious from this brief discussion that the application has some work to do to interpret the raw data to make it useful for compliance investigations or other purposes. The script published with the December article referenced above shows how to approach the task, which is like the parsing of audit records to extract useful content. Figure 1 shows the kind of data that can be extracted from the aiInteractionHistory API records.

The Many Sources of Information About Copilot Interactions

It’s hard to know how useful the aiInteractionHistory API will turn out to be. Other sources of information can be mined to discover how people use Copilot, including usage data, audit records, and the compliance records held in user mailboxes. I guess it all depends on what you’re looking for.

Oddly Named SharePoint Embedded Containers Show Up for Copilot Studio

Microsoft 365 tenant administrators can be swamped with message center notifications, reports about service health issues, and automated email generated by Entra ID and other workloads. Other more important things usually get in the way and often no great harm is done. Right now, there are 830 notifications in the message center for my tenant, and probably only 20% of the notifications are what I consider important. For instance, knowing that a new channel update is available for the Office apps isn’t usually a critical event.

In any case, some gems do appear, and it’s important that tenant administrators keep an eye on what’s happening. Let’s discuss an example involving SharePoint Embedded and Copilot Studio to illustrate the point.

The Set of SharePoint Embedded Containers with GUID Names

At first glance, message center notification MC1058260 (last updated 12 May 2025, Microsoft 365 roadmap item 489214), titled “Microsoft 365 Copilot: Admin controls and user file uploads for agent knowledge sources” didn’t seem too worrying. Given Microsoft’s current preoccupation with AI, it’s unsurprising that flood of notifications describing various Copilot enhancements appear weekly. As I don’t use Copilot Studio much, it was easy to assume that a development won’t impact my tenant.

When investigating how Loop workspaces connected to Teams standard channels, I noticed a bunch of strange containers for the Declarative Agent app had appeared in SharePoint Embedded (Figure 1). Some process had created these containers in three batches on April 27 (3:25am), 8 May (1:53am), and 15 May (2:21pm). All the containers appeared to be empty. The only clue was the application name, indicating that the containers are related to some form of agents.

Agents process information from knowledge sources like SharePoint Online sites. MC1058260 explains that users will soon be able to upload up to 20 documents for agents to use as knowledge sources, and when this happens, the uploaded files are stored in “tenant-owned Microsoft SharePoint Embedded (SPE) containers.” MC1058260 goes on to note that “As part of this rollout, we will pre-provision a limited set of SPE containers in your tenant.” The mystery is solved because these containers are the pre-provisioned containers mentioned by MC1058260. I assume that Microsoft creates the containers to make it faster for users to upload documents (because they don’t have to wait for an agent to create a container).

Adding Files as Knowledge Sources for Agents

My tenant ended up with 80 pre-provisioned containers (so far – I have no idea if more provisioning cycles will happen in the future). As far as I can tell, the provisioning operation didn’t generate any audit records. At least, audit log searches for the creation times for the containers turn up nothing of interest.

My tenant doesn’t have 80 agents in use (the number is more like 8), so I assume that the pre-provisioned containers are a pool that agents can use. To test the theory, I edited an agent that I created with Copilot Studio a couple of months ago and added the source Word document for the Automating Microsoft 365 with PowerShell eBook as a knowledge source (Figure 2).

What I expected to happen is an allocation of one of the pre-provisioned containers to the agent and an update to the container name to change it from the GUID used by the pre-provisioning routine to the name of the agent. Updates don’t happen quickly in the SharePoint admin center and site and containers data is usually at least two days behind real time, so I was prepared to wait. However, no change showed up over the next few days.

The Mysterious SharePoint Embedded Containers Disappear

And then, Microsoft hid the pre-provisioned containers. I had chatted to some Microsoft contacts and complained about the mysterious containers, so I guess they acted. In any case, there’s now no trace of the containers and I can’t find out if the updated agent took over a container. And as I don’t know the application identifier for the Declarative Agent app, I can’t use the Get-SPOContainer cmdlet to retrieve any details like the storage consumption (or name) to check if anything had changed in the set of containers.

It’s probably best that Microsoft hides these containers when they are newly created and empty. However, once a container is used by an agent, I think it should show up in the set of active containers displayed in the SharePoint admin center, if only because the storage consumed by the container is charged against the tenant SharePoint Online storage quota. It’s the kind of detail that Microsoft needs to deliver for tenant-wide agent management.

The mystery is solved, and I learned how to add a file as a knowledge source for an agent. Keep an eye on the notifications posted to the message center. You might even learn something too!

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.