Microsoft Leaves Gaps in Technologies for ISVs to Fill – Like Agent Governance

Every time Microsoft makes a big move, ISVs seek to take advantage with a new product. It’s the way of the work. Microsoft creates technology and ISVs fill the holes left in that technology. In some respects, the cloud is a difficult place for ISVs. There’s less to tweak than in an on-premises environment and although the Graph APIs have extended their coverage to more areas of Microsoft 365 over the last few years, significant gaps still exist for major workloads like Exchange Online and SharePoint Online.

But a new technology creates a new opportunity because everything starts from scratch. Microsoft’s big move into artificial intelligence with Copilot hasn’t created too many opportunities because Copilot depends on a massive infrastructure operated by Microsoft that’s inaccessible except through applications like BizChat. Agents are different. They’re objects that need to be managed. They consume resources that need to be paid for. They represent potential security and compliance problems that require mitigation. In short, agents represent a chance for ISVs to build products to solve customer problems as Microsoft heads full tilt to its agentic future.

Building an Infrastructure for Agent Governance

To be fair to Microsoft, they’ve started to build an infrastructure for agent management. Apart from a whitepaper about managing and governning agents, the first concrete sign is the introduction of agent objects in Entra ID. Microsoft is thinking about how agents can work together, and how that communication can be controlled and monitored. That’s all great stuff and it will deliver benefits in the future, but the immediate risk is the fear that agents might run amok inside Microsoft 365 tenants.

Microsoft reports that there are 56 million monthly active users of Power Platform, or 13% of the 430 million paid Microsoft 365 seats. That’s a lot of citizen developers who could create agents using tools like Copilot Studio. Unless tenant administrators disable ad-hoc email subscriptions for the tenant, developers could be building agents without anyone’s knowledge.

Don’t get me wrong. I see great advantages in agent technology and have even built agents myself, notably a very useful agent to interact with the Office 365 for IT Pros eBook. One thing that we’ve learned over the last 30 years is that when users are allowed to create, they will. And they’ll create objects without thought, and those objects will need to be cleaned up eventually, or, as Microsoft discovered, the mass of SharePoint Online sites created for Teams became a real problem for Microsoft 365 Copilot deployments. Incorporating solid management and governance from the start is of great benefit for new technologies.

Rencore Steps Up with Copilot Agent Governance

All of which brings me to Rencore’s announcement of two new modules for their governance product to deal with Copilot and agent governance and Power Platform governance (Figure 1). Matthias Einig, Rencore’s CEO, has been forceful about the need to take control of these areas and it’s good to see that he’s investing in product development to help Microsoft 365 tenants take control before agents get any chance to become a problem.

I have not used the Rencore product and do not endorse it. I just think that it’s great to see an ISV move into this area with purpose and intent. It seems like Rencore aims to address some major pain points, like shadow IT, the cost of running Copilot agents, over-sharing, and “agent sprawl.” All good stuff.

I’m sure other ISVs will enter this space (and there might be some active in the area already that I don’t know of). This will be an interesting area to track as ISVs seek new ways to mitigate the potential risks posed by agents.

No Time to Relax

Product from one ISV does not mean that we can all relax and conclude that agent management is done. It’s not. The continuing huge investment by Microsoft in this space means that agent capabilities will improve and grow over time. Each improvement and new feature has the potential to affect governance and compliance strategies. Don’t let your guard down and make sure that your tenant has agents under control. And keep them that way.

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

Token Protection, PRTs, Device Binding, and Session Keys

Last year, I discussed how to use a conditional access policy to apply a new session control called token protection. The idea is to protect against token theft by requiring connections to have a token (the Primary Refresh Token, or PRT) that has a “cryptographically secure tie” with the device that the connection originates from. The PRT is “bound” to a device key that’s securely stored in the device’s Trusted Platform Module (TPM). PRTs are supported on Windows 10 or later devices.

The PRT is an “opaque blob” that’s specific to a user account and device. The Entra ID authentication service issues a PRT following a successful connection by a user when the device is registered, joined, or hybrid joined. Entra ID also issues a session key, an encrypted symmetric key to serve as proof of possession when a PRT attempts to obtain tokens for applications. If an attacker attempts to hijack a connection with an access token they’ve stolen, they’ll fail because they don’t have access to the device key.

Why Does This Matter?

As noted in my article last year, it’s possible to create a conditional access policy with a session control requiring token protection. In other words, when a connection attempts to satisfy the conditions of the policy, it must be able to prove that its PRT is bound to the device where the connection originates and the user making the request. This process is managed by a component called Web Account Manager (WAM).

But conditional access policies can only work if everything involved in the connection understand what’s going on. At the time I wrote the last article, limited support existed for token protection. The reason for this article is that interactive Microsoft Graph PowerShell SDK sessions now support token protection (see details about support for token protection by other applications here). This opens the possibility of extending additional protection for administrators and developers who might work on sensitive data through the Graph SDK.

The reason why you might want to do this is revealed in a recent Entra ID change that shows the resources a user can access when they satisfy a conditional access policy to connect. In this case, the connection is to an interactive Graph PowerShell SDK session, and the resources available in that session depends on the delegated permissions held by the Microsoft Graph Command Line Tools service principal. The set of permissions tends to swell over time as administrators grant consent to permissions needed to work with different cmdlets, but as Figure 1 shows, a Graph PowerShell SDK session can have access to many different resources.

Enabling Token Protection for Graph Interactive Sessions

Normally, interactive Graph PowerShell SDK sessions don’t use WAM. To enable WAM for Graph sessions, run the Set-MgGraphOption cmdlet before running Connect-MgGraph. As the documentation says, the cmdlet sets global configuration options, so the configuration setting stays in force for all Microsoft Graph interactive sessions on the workstation until it is reversed.

Set-MgGraphOption –EnableLoginByWAM $true
Connect-MgGraph

If the device isn’t registered or joined, the conditional access policy condition for token protection isn’t satisfied and the sign-in attempt is rejected with a 530084 error code. The cause is obvious if you examine the policy details captured in the sign-in event (Figure 2).

WAM doesn’t affect app-only authentication for the Graph SDK, including Azure Automation runbooks that use modules and cmdlets from the Graph PowerShell SDK.

Token Protection and Elevated PowerShell Sessions

The Web Account Manager option doesn’t work in elevated PowerShell sessions (run as administrator). Attempts to connect fail with the error “InteractiveBrowserCredential authentication failed: User canceled authentication.”

The solution is two-fold. First, revert to normal authentication on the workstation by running the Set-MgGraphOption cmdlet to set EnableLoginByWAM to $false. If you don’t, authentication fails because a protected token isn’t available (Figure 3). The second step is to remove users who need to run Graph cmdlets in elevated PowerShell sessions from the scope of the conditional access policy. This avoids the user running into problems on other workstations.

Token Protection and Microsoft Graph PowerShell SDK Versions

The WAM option also doesn’t work with the latest versions of the Microsoft Graph PowerShell SDK. This is likely due to Microsoft’s decision to remove support for .NET6 from V2.25 on. In V2.28 of the SDK, the error when running Connect-MgGraph is:

InteractiveBrowserCredential authentication failed: Could not load type 'Microsoft.Identity.Client.AuthScheme.TokenType' from assembly 'Microsoft.Identity.Client, Version=4.67.2.0, Culture=neutral, PublicKeyToken=0a613f4dd989e8ae'.

While Microsoft gets their act together and decides how to fix the issue, the only option is to remain using V2.25. PCs that have upgraded to the current V2.28 release must downgrade to V2.25.

Token Protection is Just Another Tool

Token protection is not for everyone. Its linkup with conditional access policies is another tool for administrators to consider when figuring out how to secure their tenant. My recommendation is that you test the feature and make a measured decision whether it has any value for your organization. Remember that this is an evolving space and other applications are likely to support token protection over time. Maybe one of those applications will be exactly the one you want to secure.

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

Problems with Azure Automation Afflict Microsoft 365 PowerShell Modules

The recent problems with the Microsoft Graph PowerShell SDK are well documented. Suffice to say that the Graph PowerShell SDK hasn’t been very stable since V2.25. V2.26 and V2.27 just didn’t work, and although Microsoft delivered a much-improved update in V2.28 in May 2025, the Graph PowerShell SDK still has problems with Azure Automation.

In the Azure Automation environment, runbooks are configured to use a runtime version of PowerShell. When a runbook starts, Azure Automation loads the dependent modules (which must be a version that matches the runtime version) on the target server where the runbook executes. Currently, Azure Automation supports runtime versions for PowerShell V5.1, V7.1, and V7.2.

A Question of .NET

PowerShell V5.1 is the “classic” version. V7-based PowerShell is “PowerShell Core.” The V7.1 and V7.2 runtimes support .NET 6 while the latest versions of PowerShell use .NET 8. Software engineering groups don’t like supporting what they consider to be outdated software, so a decision was taken to drop support for .NET 6. The net effect was that V7.1 and V7.2 runbooks couldn’t use the Graph PowerShell SDK. The workaround was to use the PowerShell V5.1 runtime or revert to V2.25 of the Graph PowerShell SDK, which still supports .NET6.

Microsoft says that the solution will come when Azure Automation supports the PowerShell V7.4 runtime. That update was supposed to arrive by June 15, 2025. It’s late, so I cannot confirm or deny if Graph PowerShell SDK V2.28 code supports PowerShell V7.4 runbooks.

The .NET Versioning Problem Strikes Exchange

A week or so ago, a reader complained that the latest version of the Exchange Online management module (now V3.8.0) didn’t run with PowerShell V7.2 runbooks. A previous comment for the article where the issue was raised said that V3.5 was required to support PowerShell V7.2 runbooks as long ago as February 13, 2025. At the time, apart from finding a relevant Stack Overflow discussion, I didn’t pay too much attention to the problem. I guess I became accustomed to the Exchange module just working while the Graph PowerShell SDK was the problem child of the Microsoft 365 PowerShell modules.

As it turns out, the Exchange Online management module shares the same problem as the Microsoft Graph PowerShell SDK. Engineering decided to remove support for .NET 6 in V3.5.1 of the Exchange module and screwed up Azure Automation V7 runbooks. The release notes for V3.5.1 are brief and concise:

Version 3.5.1

• Bug fixes in Get-EXOMailboxPermission and Get-EXOMailbox.
• The module has been upgraded to run on .NET 8, replacing the previous version based on .NET 6.
• Enhancements in Add-VivaModuleFeaturePolicy.

There’s nothing to raise awareness for tenant administrators that the change in supported .NET version will stop runbooks dead in the water. It’s easy to glance over the release notes and conclude that not much has changed and it’s therefore safe to upgrade to the new version. The problem becomes very evident when the Connect-ExchangeOnline cmdlet can’t run and as a result, every other Exchange cmdlet cannot be found (Figure 1).

The Need for Solid Azure Automation Support

No one denies that Microsoft must prune old software from their cloud services. It’s hard enough to keep a service running smoothly when it carries unnecessary baggage in the form of old code. But in the cases of both the Microsoft Graph PowerShell SDK and the Exchange Online Management module, it seems like the engineering groups never stopped to ask if the change might impact the ability of scripts to run. Running scripts interactively revealed no issues, but running code in an interactive session on a Windows PC (or even a Mac) is not the same as Azure Automation firing up a headless Linux server and configuring it with the software necessary to execute a runbook.

Ensuring that shipped modules support Azure Automation is a problem that can be solved by incorporating Azure Automation runbooks in the test procedures that must succeed before a new version of a module can be released. What’s more upsetting is the lack of awareness within Microsoft about why customers pay for Azure Automation to run scripts.

When a script moves from running interactively on an administrator workstation to become an Azure Automation runbook, it’s probably because the script is deemed to be important enough to run on a stable, robust, and secure environment, often on a schedule (the Windows Task Schedule should not be relied upon to run important scripts). In other words, Azure Automation is an important platform that deserves the respect and solid support of the Microsoft engineers that build PowerShell modules that can run within Azure Automation. That doesn’t seem to be the case today.

Too Much Disruption

Microsoft 365 tenants have suffered far too much disruption with PowerShell modules over the last few years. The retirement of the old Azure AD and MSOL modules was a necessary evil, but Microsoft didn’t handle the situation as well as they should. Many sins might be forgiven if the Microsoft 365 PowerShell modules were rock solid. They’re not currently. Let’s hope that Microsoft does a better job in their testing and pre-release verification processes for PowerShell modules in the future.

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

Thanks to the Office 365 for IT Pros Subscribers

In a time when some question the value of books, we deeply appreciate the support of the folks who subscribe to the Office 365 for IT Pros eBook. AI tools like ChatGPT and Copilot can find and synthesize information scoured from across the internet to respond to questions, but so far generative AI cannot provide the context or insight that understanding technology often needs.

An ecosystem like Microsoft 365 can become terribly complicated through different combinations of products, licenses, and configurations. Throw in hybrid organizations and there’s enough to melt an administrator’s mind. We don’t pretend that we have more answers than AI can generate; we do say that our answers are based on hard-won experience and a ton of research into why Microsoft 365 works the way that it does. In other words, we ask “why” when AI just accepts what something is.

Heading for a July 1 Release

It’s just seven days to go before we release Office 365 for IT Pros (2026 edition), including Automating Microsoft 365 with PowerShell (2^nd edition). The writing team is still heads-down to make sure that the content is compelling, informative, and up to date, and that any of the issues raised by technical editor Vasil Michev are addressed.

We’ve received some questions about how we will release the 2026 edition. Thankfully, people want to know when they can subscribe to the new edition. With that in mind, here’s our plan.

The Release Plan

The first task is to complete all the updates to the chapters, resolve any open issues, chase down the last-minute glitches, and have a coffee. We can then proceed to do the following:

• Generate the PDF and EPUB files for the two books, check that everything is OK, and if all checks out, upload the new files to Gumroad.com. We then switch the shortcut URL for the current version from the 2025 edition to the 2026 edition.
• The 2025 edition files will remain online to allow subscribers to that edition to download the final updates. We made some small tweaks to the Office 365 for IT Pros (2025 edition) files since releasing update #120 on June 1. The current update number for the 2025 edition is 120.4, dated 21 June 2025. We will start the 2026 edition at update 121.0.
• We will send an offer to current subscribers to allow them to extend their subscription to cover the 2026 edition and receive monthly updates for the next year. To reward the folks who renew subscriptions immediately a new edition is available, the price to extend a subscription in July 2025 is $18.95. After August 1, 2025, the price to extend a subscription increases to $24.95.
• Anyone who bought a full-price ($49.95) copy of the 2025 edition in June 2025 will receive a full discount code to extend their subscription for the 2026 edition.
• The update offer and codes are distributed via email to the addresses registered when people subscribed to the 2025 edition. If an email address is incorrect, you won’t receive anything from us. In this case, send email to contact@office365itpros.com to tell us what’s going on. If we can find you on our subscriber list, we’ll respond with the code.
• Some tenants consider email from Gumroad.com as spam. Our email isn’t and we have experimented with sending email using the Exchange HVE and Azure ECS solutions during the last year. HVE is now out of the picture because Microsoft has decided that it will only handle internal email, but anyway, mass mailings about new versions are always sent from Gumroad.
• New subscriptions for the 2026 edition cost $59.95. This is our first price increase since 2015. According to Copilot, the price should be $67.73, but accepting an AI recommendation without question is never a good idea. We believe that the increase is more than justified by the massive amount of information contained in the two books, which can be reasoned over by a Copilot agent if you want.
• The Automating Microsoft 365 with PowerShell eBook is bundled with Office 365 for IT Pros and doesn’t have to be bought separately. People who subscribed to the first edition of the PowerShell book can download the second edition free of charge. It’s our way of saying thanks to those who bought the first edition while we built out the content.
• For those who like paper books, a version of Automating Microsoft 365 with PowerShell is available in paperback from Amazon.com. This is the same text as the electronic version, except that hyperlinks are converted to footnotes. The paperback also has an index because it’s harder to search through paper. Regretfully, we haven’t found a way to update a paperback remotely, so buying a paper copy of the PowerShell book is like buying any other paperback.
• Anyone who received a free copy of the 2025 edition from us or another source (companies commonly buy multiple copies to give to customers) can use the code to extend their subscription for $18.95. Alternatively, ask the source for the free copy – maybe they have free copies of the 2026 edition to distribute.

2026 or Twelfth?

Some ask us why we name the book after the year ahead. We do so because we match Microsoft’s fiscal year. Their FY26 begins on July 1, 2025. We could call this release Office 365 for IT Pros (12^th edition). Maybe that would be clearer, but the date does help in terms of telling people how recent the content is.

Enjoy the 2026 edition!

Summarize Attachment Feature is an Example of New Features Needed to Maintain Customer Interest

Introducing a new technology is hard. The great expectations created at the initial launch soon meets the hard reality of deployment and things don’t get better until the technology has had time to bake. This is as true for Microsoft 365 Copilot as for any other major technology. I see people questioning whether the $30/user/month really delivers any benefits, with real concern over whether people use any of the purported time saved through Copilot interventions doing anything more valuable than drinking more coffee.

News that the U.S. Better Business Bureau forced Microsoft to change some of the claims it makes about how Microsoft 365 Copilot affects user productivity doesn’t help the case for AI-based assistance. And lukewarm or mildly enthusiastic (but independent) reports about Copilot usage in organizations, like the recent UK Government report based on a 3-month trial for 20,000 employees don’t bolster the case much either.

All Microsoft can do is continue to push out updates and new AI-based features to keep customer interest while Copilot matures to become more useful in day-to-day activities. The result is a flood of new Copilot-related features, not all of which seem valuable except in specific cases. I don’t know whether AI-informed People Skills will become popular (some HR professionals that I know like People Skills a lot). Those in the Power Platform world (now with 56 million monthly active users according to data made available at Microsoft’s FY25 Q3 results) see lots of changes to make Copilot agents more productive. I do like the ability to upload documents to agents for the agents to reason over.

Summarizing Attachments

All of which brings me to the update described in message center notification MC1073094 (13 May 2025, Microsoft 365 Roadmap item 475249). It’s an example of a recent Copilot enhancement to help users process “classic” email attachments faster. Even though cloudy attachments are preferable in many respects, many people still send files instead of links.

Copilot has been able to summarize cloudy attachments for email for quite a while. Now, when a message with one or more classic file attachments arrives, users with a Microsoft 365 license see a new summarize option for Office and PDF attachments. The feature is available in the New Outlook for Windows, OWA, Outlook mobile, and Outlook for Mac, but not for Outlook classic. Microsoft is rolling out the update now with estimated completion by late August 2025.

Figure 1 shows the general idea. A Word file is attached to a message. Clicking the summarize option from the drop-down menu beside the attachment causes Copilot to create and display the summary for the file inside the Summary by Copilot panel (or card). If a message has multiple file attachments, the summarize option must be invoked separately.

Copilot cannot process encrypted attachments (using sensitivity labels or another encryption mechanism).

No Archived Messages

My archive mailbox is full of attachments from long-forgotten projects, including files related to some legal cases that I was involved with. I was curious to see what sense Copilot might extract from some of the PDFs and Word documents from those cases. Oddly, Outlook won’t summarize any of the attachments for messages stored in an archive mailbox. To generate a summary for these files, you must open download and open Office files in a desktop or web app and use the Copilot options available in the app.

Thinking about why this might be so, I guess the logic is that attachments for archived messages probably aren’t of very high interest, and if someone goes to the trouble of finding an archived message, they have a purpose for doing so and won’t mind opening attachments to view content. On the other hand, I could be overthinking things and Microsoft simply designed the feature to work only with messages from the primary mailbox.

The Value of Small Changes

Over my many years of work, I cannot say how many emails I have received with file attachments. Being able to see a quick summary of an attachment is a good example of how AI can be effective. The feature works well because the AI has just one file to process, so it’s unlikely that hallucinations or other issues will occur. You might disagree with points made in the summary, but having the summary is a timesaver and a great starting point for understanding whether a file contains anything important.

Another example of a small but interesting change is the ability to create a meeting from an Outlook email thread (MC1090693, 9 June 2025, Microsoft 365 roadmap item 494154). The idea is that Copilot scans an email thread to determine the topic for a meeting and its participants and creates a meeting invitation ready to go. This kind of thing doesn’t need AI because existing Graph APIs can do the work, but Copilot integrates the work into a new Schedule with Copilot option (only for email threads with sufficient data to base a meeting upon). According the roadmap item, this feature is for the mobile clients, but I bet it will be available in the new Outlook and OWA too.

In the overall scheme of Copilot, delivering Outlook features to make small tasks easier is not important. However, changes that reduce friction for users are important and collectively a bunch of changes like this might just be enough to convince an organization that they really can’t live without Copilot.

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

New Microsoft-Managed App Consent Policy to Control User Consent for Apps

Message center notification MC1097272 (17 June 2025) announces Microsoft’s intention to restrict access to some legacy protocols and introduce a new managed app consent policy to the ability of users to grant consent to third-party apps that want access to files and sites.

Microsoft says that they are updating default settings to help Microsoft 365 tenants “meet the minimum security benchmark and harden your tenant’s security posture.” As far as I can tell, this appears to be a reference to section IM-2 of the Microsoft cloud security benchmark. For good measure, Microsoft throws in the Secure Future Initiative and Secure by Default principle to provide further justification for the change.

No Problem with Blocking Obsolete and Insecure Protocols

I don’t think anyone will complain about blocking browser access to SharePoint and OneDrive via the Relying Party Suite (RPS – another relatively unknown component for most Microsoft 365 tenants). Legacy protocols are blocked in the SharePoint tenant configuration, and this change reinforces the block.

Get-SPOTenant | Select-Object LegacyBrowserAuthProtocolsEnabled

LegacyBrowserAuthProtocolsEnabled
---------------------------------
                             True

Likewise, I don’t think anyone will complain about blocking the FrontPage Remote Procedure Call (FPRPC) protocol for Office file opens. It’s an outdated protocol that attackers have leveraged (here’s an example).

App Consent Policy to Prevent Third-Party Access to Files and Sites

My interest was drawn to the third block, which will introduce a Microsoft-managed app consent policy to require administrator consent for third-party apps that access files and sites. There are a bunch of app consent policies already present in tenants that you can see by running the Get-MgPolicyPermissionGrantPolicy cmdlet from the Microsoft Graph PowerShell SDK (any policy prefixed by “microsoft” is a Microsoft-managed app consent policy):

Get-MgPolicyPermissionGrantPolicy | Format-Table Id, DisplayName, Description -AutoSize

Like many other Microsoft 365 policies, the policy is a container, and the real settings (“condition sets”) are found by running the Get-MgPolicyPermissionGrantPolicyInclude cmdlet. For example, this app consent policy allows administrators to manage all aspects of all apps in a tenant:

Get-MgPolicyPermissionGrantPolicyInclude -PermissionGrantPolicyId "microsoft-application-admin" | Format-List

ClientApplicationIds                        : {all}
ClientApplicationPublisherIds               : {all}
ClientApplicationTenantIds                  : {all}
ClientApplicationsFromVerifiedPublisherOnly : False
Id                                          : 811d2da7-443c-43da-96e7-28d285b234e9
PermissionClassification                    : all
PermissionType                              : application
Permissions                                 : {all}
ResourceApplication                         : any
AdditionalProperties                        : {}

ClientApplicationIds                        : {all}
ClientApplicationPublisherIds               : {all}
ClientApplicationTenantIds                  : {all}
ClientApplicationsFromVerifiedPublisherOnly : False
Id                                          : 60461179-740e-4d8b-9e00-1456a338c44b
PermissionClassification                    : all
PermissionType                              : delegated
Permissions                                 : {all}
ResourceApplication                         : any
AdditionalProperties                        : {}

For more details, see the Graph documentation for permission grant policies. There’s no UX in the Entra admin center to manage app consent policies. This article throws more light onto how to build your own app consent policies.

The Change Doesn’t Affect All Tenants

The change only affects tenants that use the default user consent settings. In my case, I changed the settings (Figure 1) to allow users to consent to a set of low-impact permissions such as User.Read. The Sites.Read.All or Files.Read permissions are definitely not in the low-impact category, which is why Microsoft is blocking them.

If you allow users to consent to permissions, you should monitor the consents to make sure that apps are not asking for unexplainable permissions. You can check permission consents through audit records. You’ll also need to make sure that the admin consent request workflow is operational.

See this article for a script to use the Microsoft Graph PowerShell SDK to generate a report of all delegated permission grants that exist in a tenant. The script reports permissions that apply to all users (consent type of “AllPrincipals”) and specific users (“Principal”). It ignores common permissions such as those required to read the user’s own profile and focuses on permissions that might disclose information if used badly. If you’re concerned about the permissions users have already granted to their data, filter on the grants of the Principal consent type and review those.

The ChatGPT Conundrum

What’s interesting about Microsoft’s move is that it neatly blocks the ability of users to grant consent for the permissions needed by the ChatGPT app to upload files from SharePoint Online and OneDrive for Business for processing by one of the ChatGPT models. A cynic might say that Microsoft is taking this step to make sure that Microsoft 365 Copilot has sole access to files stored in SharePoint Online and OneDrive for Business. A more benign reading is that Microsoft is simply making sure that users can’t inadvertently grant access to third-party apps to access and read their Microsoft 365 files.

In any case, I don’t think people should upload files to ChatGPT because this activity creates all sorts of security concerns. Fortunately, it’s easy to find and block the ChatGPT app if it’s already in a tenant. In addition, ChatGPT cannot process encrypted files protected by sensitivity labels because it doesn’t have the access right needed to open protected files.

Don’t Drop Your Guard

No can argue that we do need to do better to secure tenants, so the changes proposed by Microsoft are welcome. The changes will begin rolling out in mid-July and are due to be in all tenants sometime in August 2025.

There are still too many tenants that don’t protect user accounts with multifactor authentication, which is why bad actors keep using password spray attackers in an attempt to compromise accounts. A recent report describes a password spray attack by a group called SneakyStrike against Entra ID accounts. The report is a little overhyped, but it’s a good reminder that attackers still patiently look for weak tenants to penetrate.

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

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

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

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

Global Banned Password List

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

Custom Banned Password List

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

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

Blocking Passwords

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

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

Updating the Custom Banned Password List with a Script

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

The code:

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

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

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

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

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

Marked Lack of Detail around Microsoft 365 Local

Microsoft’s June 16 announcement about “sovereign solutions empowering European organizations” (Figure 1) is obviously an attempt by Microsoft to reassure European customers that continuing to use Microsoft (U.S.-based) technology is a safe choice at a time when many question the policies of the current U.S. administration.

To be fair to Microsoft, they’ve been on the path to respect data sovereignty for many years, starting with the original “Black Forest” implementation of Office 365 for German customers to a point where multiple national-level datacenter regions are available within Europe. Microsoft’s continued efforts to provide comfort to customers who want their data stored in-country and under the control of European law is commendable.

However, the announcement of Microsoft 365 Local confused everyone. According to the announcement, “Microsoft 365 Local provides customers with additional choice by bringing together Microsoft’s productivity server software into an Azure Local environment that can run entirely in a customer’s own datacenter.”

Apart from the Name, No Trace of Microsoft 365

Applying the Microsoft 365 branding to the offering implies some form of connection to Microsoft 365. But apart from a need to connect to Azure., this solution seems to have nothing much to do with Microsoft 365 cloud services. Instead, it appears to be the on-premises versions of Exchange Server, SharePoint Server, and Skype for Business Server running on an Azure Local instance, defined as “a machine or a cluster of machines running the Azure Stack HCI operating system and connected to Azure.”

At this point, Microsoft hasn’t shared details of how the services connect together, but I assume that Active Directory is in the mix too. We also don’t know if the Azure-based local infrastructure operates as a separate deployment, can be integrated into an existing on-premises organization, or operate as part of a hybrid organization.

In other words, Microsoft 365 Local is a modernized example of a packaged Azure-based installation of Exchange, SharePoint, and Skype for Business built according to a reference architecture and accessed via the same kind of clients that people use today to connect to on-premises servers. Unsurprisingly, Microsoft 365 Local doesn’t include Teams because Teams relies so heavily on services from Exchange, SharePoint, OneDrive, Planner, and a bunch of Azure microservices.

The packaging might be innovative, and Microsoft marketing will certainly call the announcement a triumph for branding, but it has nothing to do with Microsoft 365. Anyone who steps back from using Exchange Online with its close integration with SharePoint Online will quickly discover how different things are.

Some Organizations Will Love Microsoft 365 Local

Although I hate the name, a place exists for a solution like Microsoft 365 Local. Some companies want to control their own destiny, which is why they continue running on-premises software; others don’t have sufficient external network capacity to be dependent on cloud services.

Other companies simply want to not have to deal with the blizzard of changes that Microsoft 365 customers have to cope with, or the constant nagging from Microsoft to adopt and use its AI-based tools like Microsoft 365 Copilot. European customers have a strong track record of respecting user privacy, and solutions like the recently-launched AI-powered People Skills are unlikely to be popular with unions or works councils.

Being able to purchase a packaged solution that is hopefully better integrated out-of-the-box is a nicer option than having to convince Exchange Server and SharePoint Server (for instance) to work together, an exercise that is usually guaranteed to frustrate. Presumably the solution leverages the subscription version of the three on-premises servers and will be paid for via an Azure subscription in the same manner as Azure Local.

Lack of Detail is Frustrating

The trouble is the total lack of detail currently available about Microsoft 365 Local. The above is inspired guesswork based on reading between the lines of Microsoft’s announcement. Many questions remain unanswered. Customers will need pricing and availability details from the various hardware vendors listed in the announcement are before they can decide if Microsoft 365 Local is for them. Migration from current on-premises deployments is another issue to resolve as is deployment alongside existing deployments.

The lack of detail is frustrating, but this is a classic marketing playbook: announce a product to gauge interest and follow up if the interest is there. It will be interesting to see what Microsoft 365 Local can deliver and at what cost.

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

New Service to Manage People Skills in an Organization

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

People Skills Licensing

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

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

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

Setting Up People Skills

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

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

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

Get-VivaModuleFeature -ModuleId PeopleSkills

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

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

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

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

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

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

Graph API

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

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

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

Some People Skills Oddities

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

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

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

Use Office 365 for IT Pros PDF Files as Knowledge Sources for Copilot

The announcement in message center notification MC1078671 (20 May 2025) that Copilot Studio can deploy agents to SharePoint Online sites (in Copilot Studio terms, SharePoint Online is a channel) gave me an idea. SharePoint has supported agents since October 2024, but those agents are limited to reasoning over the information contained in a site. Copilot Studio can create more flexible and powerful agents that can consume different forms of knowledge, including external web sites and files. Uploaded files are stored in the Dataverse, or the mysterious SharePoint Embedded containers that appeared in tenants recently.

My idea is to use the Office 365 for IT Pros eBook as a source for a Copilot agent. Our subscribers can download updated book files every month in PDF and EPUB format. Copilot can consume text files, including PDFs, as knowledge sources (message center notification MC1058260, last updated 9 June 2025, Microsoft 365 roadmap item 489214). If you have Microsoft 365 Copilot licenses, it seems logical to create an agent that uses the PDFs for the Office 365 for IT Pros and Automating Microsoft 365 with PowerShell eBooks as knowledge sources.

You could even expand the set of knowledge sources to https://office365itpros.com and https://practical365.com to include articles written by our author team. Once the agent is configured, it can be published to a SharePoint Online site for users to interrogate. Sounds good? Let’s explore what you need to do to make the idea come alive.

Adding Files to a Copilot Agent

During an investigation of the various ways to create Copilot agents, I created an agent in Copilot Studio called the Microsoft 365 Knowledge Agent. The agent already reasoned over office365itpros.com and practical365.com. I uploaded the PDF files for the two books to the agent so that the agent now reasons over the two websites and two PDF files (Figure 1). You might notice that I have disabled the options for the AI to use its LLMs and to search public websites when composing answers. That’s because I want the agent to limit its responses to the set of defined knowledge sources.

The upload dialog says that files cannot be “labeled Confidential or Highly Confidential or contain passwords.” This might reflect old information as Microsoft has support for files protected by sensitivity labels in preview. The implementation seems very like support for sensitivity labels in Bizchat in that a user cannot access a file protected by a label if the label doesn’t grant them access to the content. I also assume that Copilot Studio will eventually support the DLP policy for Microsoft 365 to stop confidential files with specific labels being used as knowledge sources.

It can take some time for Copilot Studio to process uploaded files to prepare their content for reasoning, depending on their size. Office 365 for IT Pros is a 1,280-page 27 MB eBook, so it took several hours before Copilot Studio declared the file to be ready. You can upload a maximum of 500 files as knowledge sources for an agent.

Updating the Copilot Agent Instructions

Next, I adjusted the instructions for the agent. Here’s what I used:

• Respond to requests using information from specific curated websites and the files uploaded as knowledge sources.
• Ensure the information is accurate and relevant to the topic.
• Provide well-structured and engaging content.
• Avoid using information from unverified sources.
• Maintain a professional and informative tone.
• Be responsive and prompt in handling requests.
• Focus on topics related to Microsoft 365 and Entra ID technology.
• Write in a professional, clear, and concise manner.
• Output PowerShell code formatted for easy copying and use by readers.
• Ensure the PowerShell code is accurate and functional.
• Do not guess when answering and create new PowerShell cmdlets that don’t exist. Always check that a cmdlet exists before using it in an answer.

Coming up with good instructions for an agent is an art form. I’m sure that these can be improved, but they work.

Publish the Copilot Agent to SharePoint Online

The next task is to publish the agent. To publish the agent to a SharePoint Online site, I selected SharePoint as the target channel (Figure 2) and then selected the site that I wanted to host the agent. I suspect that Copilot Studio caches site information because it wasn’t possible for search to find a new site for several hours after the site’s creation. Publishing to a site creates an .agent file in the default document library in the site.

An agent can only be deployed to a single site. If you make a mistake and deploy the agent to the wrong site, you’ll need to undeploy and remove the site from the agent configuration and then deploy the agent to the correct site.

Out of the box, the only person who can use the agent at this point is the publisher. To make the agent available to all site members, a site administrator needs to mark the agent as approved. The agent then shows up in the list of agents accessed through the Copilot button in the meu bar. Any user with a Microsoft 365 Copilot agent can use the agent as part of their license. Access for other users must be paid for on a pay-as-you-go basis.

Using the Copilot Agent in SharePoint

Interacting with the agent to ask questions from the knowledge contained in Office 365 for IT Pros is just like any other Copilot interaction. Compose a prompt and submit it to the agent, which contemplates the request and responds based on the knowledge available to it (Figure 3).

SharePoint Online is not the only publication channel available to an agent. I also connect the agent to Microsoft 365 and Teams. Figure 4 shows how to chat with the agent in Teams.

The Only Downside is Our Monthly Updates

We know that Office 365 for IT Pros is a big eBook. Sometimes it’s hard to find the precise information that you’re looking for using the standard search facilities. Being able to have an agent reason over the books (and optionally, associated web sites) is an excellent way to have AI do the heavy lifting of finding and extracting knowledge in a very accessible way. The only downside is that you need to update the agent with the new files and republish to the target channels after we release our monthly updates. But that’s not a difficult task – and I am sure that a way will be found to automate the step in the future.

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

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

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

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

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

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

Why Does Falling Organic Traffic Matter?

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

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

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

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

Writers Will Stop Sharing Content

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

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

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

Publishing the 2026 Edition

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

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

Running Graph API Requests and Checking the Response

Whenever I need to run a Graph API request where a Microsoft Graph PowerShell SDK cmdlet isn’t available (or doesn’t work as expected), my normal go-to solution is the Invoke-MgGraphRequest cmdlet. The cmdlet works well and is extremely useful when testing a new API because it uses the authenticated connection established by the Connect-MgGraph cmdlet. In other words, you don’t need to obtain an access token to run requests because the cmdlet uses the token held by the session, including the scopes (permissions) detailed in the token.

The Graph Explorer App and Its Permissions

However, sometimes the Invoke-MgGraphRequest cmdlet comes up short and a different tool is needed for testing. That’s where the Graph Explorer can help. Like the Microsoft Graph PowerShell SDK, the Graph Explorer is implemented as an enterprise Entra ID app (appid de8bc8b5-d9f9-48b1-a8ad-b748da725064). And like the Microsoft Graph PowerShell Command Line tools app, the Graph Explorer app accumulates a set of delegated permissions over time as consent for permissions is granted to allow requests to run (that’s why the Graph Explorer UI includes a prominent Modify Permissions button).

The permissions allow signed-in users to run Graph API requests and access data available to them. Sometimes too many permissions can get in the way of testing, so it’s a good idea to review the permissions and remove any that seem not to be necessary.

Running an eDiscovery Purge Job

In this case, I was experimenting with the eDiscovery method to purge mailbox data based on a search. This is not the compliance search purge action. It’s an action to purge data found by eDiscovery premium searches. The Clear-MgSecurityCaseEdiscoveryCaseSearchData SDK cmdlet runs purge requests, using a command this:

Clear-MgSecurityCaseEdiscoveryCaseSearchData -EdiscoveryCaseId $Case.Id -EdiscoverySearchId $Search.Id -BodyParameter $PurgeParameters

The problem is that the cmdlet only reports failures (like a malformed payload). It doesn’t report the successful submission of the background purge job it creates, nor does it report the progress and eventual result of the purge job. Submission is like lobbing a stone into a deep black pit.

At first glance, using Invoke-MgGraphRequest doesn’t do any better. Once again, nothing happens, and no insight is available into the progress of the purge job.

$Uri = ("https://graph.microsoft.com/v1.0/security/cases/ediscoveryCases/{0}/searches/{1}/purgeData" -f $Case.Id, $Search.Id)
Invoke-MgGraphRequest -Uri $Uri -Body $PurgeParameters -Method POST

The documentation for the API says that a successful submission returns a 202 Accepted response code, and a response header containing the location of the Purge data operation created to commit the purge. The question is how to see that information.

Graph Explorer Reveals Responses

The Graph Explorer is designed to be a training and debugging tool. As you can see in Figure 1, it displays the 202 Accepted response, and it shows the response header. To see what’s happening with the purge job, copy the location URL and run a GET request against it (in Graph Explorer or using Invoke-MgGraphRequest) and you’ll see details such as the current progress of the purge job.

Invoke-MgGraphRequest Comes Through in the End

You can’t run Graph Explorer in a script. Although the app is great for testing, it can’t work in a production environment. All of which brought me back to the Invoke-MgGraphRequest documentation, where I discovered the ResponseHeadersVariable parameter, which outputs response headers to a variable if generated by an API request. We can’t see the 202 response for a job submission, but we can fetch details of the purge job by extracting the URI from the variable and using it to query the job status. Apparently, the purge succeeded!

Invoke-MgGraphRequest -Uri $Uri -Body $PurgeParameters -Method POST -ResponseHeadersVariable Response

[string]$ResponseLocationURI = $Response.Location
$ResponseURI = [system.uri]$ResponseLocationURI

$ResponseData = Invoke-MgGraphRequest -Uri $ResponseURI -Method Get

Name                           Value
----                           -----
createdDateTime                05/06/2025 13:44:58
id                             f580a3b0c72b4c849912520e04bc39e7
percentProgress                100
@odata.context                 https://graph.microsoft.com/v1.0/$metadata#security/cases/ediscoveryCases('7fc26cf0-bc8d-421c-8ad1-bea9782f564c')/operations/$entity
action                         purgeData
status                         succeeded
@odata.type                    #microsoft.graph.security.ediscoveryPurgeDataOperation
completedDateTime              05/06/2025 13:47:23
createdBy                      {[user, System.Collections.Hashtable], [application, ]}

The learnings here are that the Graph Explorer is a very useful debugging tool and that you should check every cmdlet parameter, even for cmdlets that have become second nature.

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.

Change Applies on July 1 to Tenants that Integrated SharePoint with Entra ID B2B Collaboration

The announcement in message center notification MC1089315 (6 June 2025) that Microsoft is dumping the old one-time passcode (OTP) authentication mechanism for SharePoint Online and OneDrive for Business sharing is unexpected, but only because it took Microsoft so long to make the change.

After July 1, 2025, external users who have received a sharing link from a user in a tenant that uses OTP authentication will discover that they have lost access to the shared content (files, folders, or sites). Microsoft says that they’re making the change to “enhance security.” I think this is correct, and the change delivers an additional benefit to Microsoft because it gets rid of an old feature.

A History of One-time Passcodes in SharePoint Online

OTP-based sharing links (aka, the “Secure external sharing recipient experience”) predates the support of Entra ID B2B Collaboration (guest accounts) within SharePoint Online. That support arrived as a result of guest access to Office 365 groups (now Microsoft 365 groups) in September 2016. Guest accounts took a while to catch on, and Office 365 groups only became really popular after the advent of Teams in early 2017. Indeed, Teams didn’t surpass 20 million active users in November 2019 before massive growth occurred in Teams usage during the Covid-19 pandemic.

Although Teams growth propelled similar growth in groups and SharePoint usage, there was no great push to move tenants off OTP authentication to SharePoint and OneDrive integration with Azure AD (now Entra ID). External sharing worked, so why bother?

Microsoft began the process to get off OTP by integrating OTP with Entra ID B2B Collaboration in October 2021. Essentially, the change ensured that external users who received OTP sharing links had guest accounts created for them in the tenant directory. The next step made sure that new tenants created after March 31, 2023, could only use B2B collaboration.

The plan now revealed “only impacts organizations that have already enabled or plan to enable SharePoint and OneDrive integration with Microsoft Entra B2B.” In other words, nothing changes for tenants that did not link SharePoint Online and OneDrive for Business to Entra ID B2B Collaboration. I wonder what proportion of the SharePoint community still use one-time passcodes exclusively for sharing.

The Result of the Change

MC1089315 rates this change to be “highly relevant.” In other words, it will affect how users work because:

• After July 1, all new sharing links generated for external people will use Entra ID B2B Collaboration and the sharees will receive email containing the sharing link generated by the Entra ID Invitation Manager service. This shouldn’t cause too much upheaval because the process is reasonably painless. I use it all the time to share documents with several other Microsoft 365 tenants and haven’t had any issues with sharing links that I can remember.
• After July 1, all previously issued sharing links based on one-time passcodes generated by SharePoint Online and OneDrive for Business will stop working. Obviously, this aspect of the change could cause confusion when a link sent to users doesn’t work. July 1 is a Tuesday, and it’s entirely possible that many sharing links with one-time passcodes arrive in user mailboxes on Monday, June 30. If the recipients action the links immediately, they can access the shared content. If they delay, the links stop working. It’s as simple as that.

Microsoft says that users will be told “Sorry, something went wrong. This organization has updated its guest access settings. To access this item, please contact the person who shared it with you and ask them to reshare it with you.” What’s gone wrong is that Microsoft decommissioned one-time passcodes. However, the statement is accurate that the only way to resume access to the shared content is to receive a new sharing link generated based on B2B collaboration. The potential for impact on users and the knock-on effect on help desks is clear.

MC1089315 notes that users will be required to complete multi-factor authentication (MFA) registration as part of the Entra ID B2B onboarding process. That’s strictly only true if the tenant that hosts the content requires MFA, most likely with a conditional access policy to block access unless an MFA challenge is satisfied. Even if your tenant doesn’t use MFA today (which it should), it is the hosting tenant that gets to choose whether MFA is required.

A Good Change

I bet this change will cause confusion and some upheaval in the weeks after July 1. After that, everything should calm down as the old OTP-based sharing links work their way out of the system. It’s good to have consistency and security and having one method to secure sharing links seems like a good change to make. At least, it is in my book.

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.

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.

Multiple Emojis Apparently Creates More Nuanced Responses

My life became complete when message center notification MC1084032 appeared on 27 May 2025 to announce that Teams users can add multiple emoji reactions when they respond to messages. Microsoft 365 roadmap item 491468 explains the need for the new capability, saying that allows users “to express a wide range of emotions effectively. Use combinations of emojis for a richer and more nuanced response, quickly conveying your feelings and thoughts, like agreement, urgency or sentiment, without extra replies—keeping discussions focused and efficient.”

Obviously, I never realized how deficient I have been in restricting myself to a single emoji reaction per chat or channel message. Now users can add up to 20 emojis in their response to messages, including custom emojis (maybe the new sticker generator promised for Paint will make it easier to create custom emojis).

Adding Multiple Emoji Reactions

Technically speaking, the ability for a user to post multiple emoji reactions isn’t hard to implement. The Graph chatMessage: setReaction API deals with posting reactions. The implementation is mostly client-side to lift the previous single reaction and permit up to 20 reactions instead (Figure 1). Users add emoji reactions through the more reactions button under the text of a message. Keep on clicking the button to add emojis. To remove an emoji added in error, select it from the set of emojis again.

Posting a reaction adds it to the collection of reactions for the target message. Although multiple reactions can come from individual users now, it’s really no different to managing a collection containing multiple individual reactions from multiple users.

The reaction list at the bottom of a message might be very colorful, but given that Teams supports over 800 emojis plus custom emojis, inviting users to create combinations of 20 emojis might result in more confused rather than nuanced responses.

As now, Teams lists the reactions in order of popularity (Figure 2) and ensures that the user viewing a message always sees their responses. In other words, Teams filters the response collection by the viewing user to list the most popular responses first. Other responses in the order they are posted then fill out the set of up to 20 emojis displayed under the message.

Schedule and Clients

Rollout is scheduled for early June 2025 to targeted release tenants followed by general availability in mid-June 2025. Full deployment, including to the GCC, GCC High, and DoD clouds should be complete by mid-August 2025. The new capability will be available in Teams desktop, browser, and mobile clients.

No administrative control is available to allow tenants to restrict users to fewer than 20 emojis. There’s also no way to disable the standard set of emojis at either a tenant or team level. I guess at this point no self-respecting messaging service could operate without supporting emojis in one form or another.

Will Users Notice Multiple Emoji Reactions?

Microsoft doesn’t say where the demand came from to warrant the investment to update Teams to allow users to add up to 20 emojis in a composite reaction to a message. I certainly have never heard of such a request, but I guess I’m not in the category of user that this change will please. I don’t think I shall ever contemplate how to combine emojis into a symphony of nuanced response. A simple thumbs-up reaction normally does the trick.

In any case, I wonder how organizations will communicate the news of the new capability to users. What form of words will they use to explain how to use multiple emojis to send effective responses. I’ll look forward to learning more.

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.

Use the Import-Export Graph API to Copy Data from Mailboxes Without a Trace

A recent LinkedIn post by a security practitioner set some alarm bells ringing when it disclosed that the Graph Mailbox Import-Export APIs processed mailbox content without creating audit events to track activity. Given that a) any operation that can exfiltrate mailbox data could be a highly prized tool for attackers and b) the extensive auditing capabilities built into Microsoft 365, this oversight is more than surprising.

What’s poignant about the situation is that Microsoft released the Mailbox Import-Export Graph APIs as part of their campaign to eliminate Exchange Web Services (EWS). EWS is deemed to be insecure and was used to exfiltrate mailbox data from many sensitive executive mailboxes in the Midnight Blizzard attack on Microsoft’s own tenant in March 2024.

Since then, Microsoft has been on a campaign to eradicate EWS from Microsoft 365 as quickly as practicable. The deadline for all apps to stop using EWS is October 2026, and Microsoft plans to eliminate EWS from first-party apps by October 2025, with recent moves to lay the path for Exchange Online and Teams to stop using EWS to share free-busy information and other data.

To be fair to Microsoft, the Mailbox Import-Export Graph API is in preview and beta software usually has a few holes to fill before it can become generally available. On the other hand, Microsoft launched the API in January 2025 and you’d imagine that someone in the development team would have noticed by now. The good news is that Microsoft has acknowledged the issue. I don’t imagine that it will take them long to begin generating audit events for import and export activities.

For an independent take on using the Mailbox Import-Export Graph API, I recommend reading the articles published by MVP Glen Scales.

Testing Auditing of Permanent Removals

Another step in the EWS removal process came with the launch of APIs to permanently remove mailbox items (including calendar items, contacts, and events). Given the issue reported above, I wanted to check if Exchange Online generated audit events for the permanent removal APIs. It’s not inconceivable that an attacker would seek to remove some items from a mailbox, and so much the better if they can do it without detection.

I processed some permanent deletions for mailbox objects and then ran an audit search for hard deletions (which is what these events are).

[array]$Records = Search-UnifiedAuditLog -StartDate '29-May-2025 10:00' -EndDate (Get-Date) -Formatted -SessionCommand ReturnLargeSet -ResultSize 5000 -Operations 'HardDelete'

Audit events for the permanent deletions duly turned up.

Permanent Removals of Calendar Events

I then processed a permanent deletion of a calendar event by finding some events in my own calendar, selecting one, and deleting it:

[array]$Events = Get-MgUserCalendarView -UserId $userId -Startdatetime "2025-01-01T19:00:00-08:00" -Enddatetime "2025-02-20T19:00:00-08:00"
$Event = $Events[1]
$Uri = $("https://graph.microsoft.com/v1.0/users/{0}/Events/{1}/permanentdelete" -f $UserId, $Event.Id)
Invoke-MgGraphRequest -Uri $Uri -Method Post

Again, Exchange Online captured a hard delete audit event for the deletion (Figure 1)

Deleting different types of mailbox items permanently generates audit events. I expected this to be the case because these are not new APIs. Instead, Microsoft extended existing APIs to support permanent deletion, and the extension picked up the existing auditing mechanism.

Auditing is Critical

Some might consider the inclusion of auditing to be a small point when an API is in beta. It’s an arguable point, but the counter is that attackers don’t care if an API that can do a job for them is a beta or production API. All they worry about is the outcome, which could be a bunch of data noiselessly moved out of a tenant.

Of course, the tenant must be compromised beforehand, but evidence exists of cases where attackers penetrated a tenant and waited months before seizing an opportunity to do damage. A beta API that doesn’t generate audit records sounds like just the kind of tool attackers might like to use.

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.

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.

Monthly Update #120 Now Available for Subscribers to Download

The Office 365 for IT Pros team is delighted to announce the availability of monthly update #120 for the Office 365 for IT Pros (2025 edition) eBook. Updated PDF and EPUB files are available for the main book and for the Automating Microsoft 365 with PowerShell eBook (previously released last week). The files can be downloaded using the link in the receipt subscribers received when they bought the book or from their Gumroad accounts. See our FAQ for more information about downloading updates and the change log for information about changes made in this update.

This is the last monthly update for the 2025 edition. We plan to release the 2026 edition on July 1, 2025, and begin a new cycle of monthly updates (#121 to #132) to bring us to June 2026. We’ll let subscribers know when the 2026 edition is available and it is our sincere hope that you’ll all join us for another year of constant change across the Microsoft 365 ecosystem. As is our normal practice, anyone who buys the 2025 edition at full price during June 2025 will receive a free upgrade to the 2026 edition when it is available.

Seeking a Million Prompts

As we prepare for the new edition, we keep our eyes open for news that we might like to cover. One interesting item that won’t make it into the book is the news that Shoosmiths, a UK-based law firm will share a £1m sterling bonus among its employees if the employees clock up one million Microsoft Copilot prompts in its new financial year. Presumably, the prompts will be counted using the aiInteractionHistory Graph API or audit records.

Shoosmiths estimates that the target will be achieved if each employee uses Copilot “4 times per working day.” That target shouldn’t be too hard to meet. Law firms are prolific users of documents, so the automatic summaries generated by Copilot in Word will go a long way to achieving the bonus (which might not be what the Shoosmiths bosses anticipated).

Microsoft 365 Gets to 430 Million Paid Seats

I usually write about Microsoft’s quarterly results but failed to do so for the FY25 Q3 announcement. The reason is simple: the data shared by Microsoft is great from a financial perspective (revenue was $70.1 billion and increased 13% (up 15% in constant currency)), but poor in terms of Microsoft 365 news. Where once it was common for Microsoft to report growth in seat numbers and other details, now it’s all about spending on artificial intelligence and the growth of agents.

A couple of things did stand out from the transcript of the quarterly results meeting with analysts.

First, Microsoft CFO Amy Hood said that paid Microsoft 365 commercial seats grew to “over 430 million,” a growth of 7% year-over-year. She also observed that Microsoft 365 seat growth in the current quarter would see “moderation given the size of the installed base.” In other words, Microsoft has signed up so many customers that adding a few extra million seats each quarter barely budges the needle.

However, Hood said that she expected Microsoft 365 revenue growth of 14%. The gap between seat growth and revenue growth is accounted for customers buying upgraded licenses, including moving lower-level licenses to Microsoft 365 E5 and buying Microsoft 365 Copilot.

The quarterly results didn’t mention Teams, the poster child of Microsoft 365 for the last few years, The last number given for Teams users was 320 million in October 2023. If growth in Teams usage had matched Microsoft 365, that number would be around 350 million now. Instead, CEO Nadella chose to emphasize the growth in Power Platform, saying “We now have 56 million monthly active Power Platform users, up 27% year-over-year, who increasingly use our AI features to build apps and automate processes.” He also said that Copilot usage increased three times year-over-year, but that’s a useless statistic without knowing the baseline.

Office 365 for IT Pros Enters an Agentic World

Obviously, there’s a lot of people using Power Platform (about 13.25% of all paid seats). Some of that growth probably comes from Copilot agents. Microsoft doesn’t have a great story about management of agent lifecycle, deployment, and access across a Microsoft 365 tenant, and the announcement that Entra ID will deliver some agent management capabilities in the Entra admin center is a good step forward. Technology keeps on changing, and we keep on tracking that change through updates to Office 365 for IT Pros. Onward to the 2026 edition!

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.

Administrative Interfaces Can List Hidden Group Memberships, but Graph-Based Apps Need Extra Permission

A user of the Microsoft 365 Groups and Teams activity report script (which I should do some work on to upgrade some really old code) pointed out that they weren’t getting details of groups with hidden membership. I’ve written about groups with hidden membership before and observed that administrative interfaces like the Microsoft 365 admin center or Entra admin center have access to hidden membership (Figure 1) where user-facing clients like Outlook block access to hidden group memberships.

PowerShell modules built for administrative use also count is administrative interfaces, so cmdlets like Get-UnifiedGroupLinks from the Exchange Online management module report hidden memberships as happily as they list open memberships. Modules like Exchange Online assume that anyone running their cmdlets is an administrator, so they extend the same access to data that the administrator enjoys through an admin portal.

Listing Hidden Group Memberships is Different with the Graph

The Graph API is different. Working on a least permission model, the Graph makes no assumptions about permissions when a session starts and the only access to data available during the session is via granted permissions. The permissions can be delegated (access to data available to the signed-in user) or application (available to tenant data). Delegated permissions are used for interactive sessions. Application permissions are used by apps (which can run in interactive sessions).

When the problem was first reported, I did a quick check but couldn’t find anything wrong. But I screwed up by running commands in an interactive session signed in with an account that held the Exchange administrator role. Interactive sessions use delegated permissions, but they also respect any of the administrative roles assigned to the account, so while the Get-MgGroupMember cmdlet would normally stop me seeing the members of a group with hidden membership, the Exchange administrator role removed the block and made the membership visible.

This experience proves once again that any testing for a Graph access scenario should be done with application permissions. In other words:

• Create an app (registration).
• Assign the app the lowest possible level of permissions you think are needed to get the job done.
• Test.
• Refine as necessary using different permissions until the test is successful.

Fetching Hidden Group Membership

In this scenario, I started off with an app with consent to use the Group.Read.All and User.Read.All permissions. The former is needed to read group details; the latter to retrieve member information (user accounts). I then disconnected my current interactive Microsoft Graph PowerShell SDK session and signed in with the app, using the thumbprint of an X.509 certificate uploaded to the app to authenticate. Running Get-MgContext confirmed the available permissions (scopes):

Connect-MgGraph -Tenantid $TenantId -AppId $AppId -CertificateThumbprint $Thumbprint
(Get-MgContext).Scopes | Format-List
User.Read.All
Group.Read.All

Now attempt to read the membership of a group with hidden membership. The Get-MgGroupMember cmdlet returns nothing, but we know why because the visibility property of the group is set to HiddenMembership. A group might have no members, but if its visibility property is set to HiddenMembership, there might be data to retrieve,

Get-MgGroupMember -GroupId $GroupId

Get-MgGroup -GroupId $GroupId | Select-Object Visibility

Visibility
----------
HiddenMembership

The Visibility property is most often used to note whether a group has private or public membership. Unfortunately, it’s not a filterable property for the Graph, so to find the groups with hidden membership, you do something like this:

[array]$Groups = Get-MgGroup -All -PageSize 500
$Groups | Where-Object {$_.Visibility -eq 'HiddenMembership' } | Format-Table DisplayName, Id, Visibility

To find details of the hidden membership, grant consent for the app to use the Member.Read.Hidden permission. Disconnect and reconnect using the app and make sure that Member.Read.Hidden is available. Now run Get-MgGroupMember again:

[array]$Members = Get-MgGroupMember -GroupId $GroupId

Id                                   DeletedDateTime
--                                   ---------------
eff4cd58-1bb8-4899-94de-795f656b4a18
cad05ccf-a359-4ac7-89e0-1e33bf37579e
08dda855-5dc3-4fdc-8458-cbc494a5a774
75ba0efb-aed5-4c0b-a5de-be5b65187c08
4daa5f06-55eb-4d79-9a24-1be369919fec
59e09287-ac1b-4ff7-80a3-08d0d1eed939

Or to see the display names of the members:

$Members.additionalProperties.displayName
Tony Redmond
James Ryan
Sean Landy
Terry Hegarty
Otto Flick
Hans Geering (Project Management)

If an app has a higher-level permission, such as Directory.Read.All, it can also read hidden membership. The same permission governs access to hidden memberships of Entra ID groups and administrative units.

The Takeaway about Graph Permissions

The takeaway here is not to assume anything about Graph permissions. The ability of the Microsoft Graph Command Line Tools app (used for Microsoft Graph PowerShell SDK interactive sessions) to accrue delegated permissions over time is both a benefit and a problem. When you can, use app-only mode to validate exactly what permissions are required to run your code.

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.

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.

Entra Agent ID Debuts as the Basis for Agent Management

Last February, I reviewed the burgeoning presence of agents within Microsoft 365 and asked if the danger existed of agents running amok. In other words, agents could be deployed and run without any kind of tenant control. Three months later, the May 19, 2025, announcement that the Entra admin center will support the management of custom agents is a good step forward in the development of a management framework for agents to match Microsoft’s vision of an agentic future.

Listing Agents in the Entra Admin Center

Microsoft’s announcement says that “it’s critical to track agent identities, manage their lifecycle and permissions, and carefully secure their access to your organization’s resources.” Their answer is Entra Agent ID, which is now available in preview in the Entra admin center. Essentially, the Entra admin center recognizes agents as a type of object that it can manage and surfaces the agents in the Enterprise applications section if an administrator applies a filter to display agents (Figure 1), just like using a filter to display the service principals used by managed identities.

“Agents” covers anything from the Copilot agents in SharePoint Online sites to the more sophisticated (and complicated) custom agents created with Copilot Studio or the Azure AI Foundry. Copilot agents linked to SharePoint sites don’t pose a management issue because they are managed (and shared) like any other site object. Entra Agent ID takes on the task of managing custom agents by automatically assigning these agents an identity within Entra ID. Microsoft says that giving agents a manageable identity “is the first step in a broader initiative to manage and protect non-human identities as organizations continue to build AI agents.”

Limited Functionality for Now

The functionality available to manage agents through the Entra admin center is very limited. Essentially, you can list agents and amend some properties. However, you cannot update the display name of an agent to replace the obscure naming used by Copilot Studio. When I tried, the Entra admin center failed with a data validation error (Figure 2). I was able to update the Notes and Logo properties.

I assume the reason why the display name can’t be updated is that the value is used in some way to link Entra ID to Copilot Studio. I’m surprised by the failure because updating agent display names would make it much easier to find agents. A display name is just that – a name by which people can recognize an object. It shouldn’t be a form of immutable link between systems (that’s what GUIDs are for).

The only reason I recognize the agent is that it’s the only one I have published from Copilot Studio. Looking through a bunch of computer-generated names that mean nothing to humans to find the right agent to manage isn’t a real issue now, but if Microsoft lives up to its promise to deliver “more access management, security, and identity governance capabilities for Microsoft Entra Agent ID, plus support for agents from Security Copilot, Microsoft 365 Copilot and third-party solutions” over the next six months, the ability to quickly locate an agent in the Entra admin center will become more important.

It All Takes Time

Rome wasn’t built in a day and Entra ID won’t truly accommodate agents quickly. It will take time before the Entra admin center can do more than simply listing agents. Giving agents an Entra identity lays the foundation for other administrative features. I hope that Microsoft also delivers Graph APIs for agent management, just in case Entra doesn’t deliver everything an organization needs.

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.

The Teams Discover Feed and Its Settings

The Discover Feed is shown at the top of the teams list and is available to users with more than five channels. Its intention is to highlight unseen messages that might otherwise be missed. A setting to enable or disable the Discover feed is in the Chats and Channels section of Teams settings (Figure 1).

After selecting a message in the Discover feed, users can also customize how the feed selects messages in the future by using the more options menu to opt not to see posts from the person who posted the message or the channel that they posted to. Clicking the settings (cogwheel) icon in the top-right corner of the feed shows the users and channels that the feed currently ignores (Figure 2).

The Discover feed sounds like an excellent feature, but I don’t use the feed very often. The reason is that Teams doesn’t support the Discover Feed for guest users. Most of my work with Teams is as when signed in as a guest into other tenants. In some of those tenants, where I am I am member of several teams with many channels, I would use the Discover feed if it was available to me, but it’s not.

I assume that the reason why guests are not supported is that some data relating to the feed is stored in the user mailbox (where most settings are located). Guest accounts have cloud-only special mailboxes, but maybe the work to hold these settings in those mailboxes hasn’t been done. All speculation on my part!

Users Must Have At least Five Channels to see the Discover Feed

All of which brings me to message center notification MC1066160 (1 May 2025) where Microsoft announced that they are limiting access to the feed unless users are part of five or more channels (including hidden channels). It’s an example of a change to tweak an existing feature, just like the change to introduce calendar notifications in the Activity Feed made last year.

This change is already active for Teams desktop and web clients. There’s nothing that tenant administrators need to do (or can do) relating to the change. Everything happens in client code and there’s no way for administrators to disable the Discover feed feature or control how it works on either a user-specific or tenant-wide basis.

Microsoft says that the change will “help to ensure the Discover Feed includes meaningful updates and conversations and avoids showing an empty or low-activity feed.” Their logic is simple. The Discover feed exists to highlight information that you might otherwise miss because of a lack of time to scan every channel available to you. If you can only access three or four channels, you don’t need this help because it’s as easy to check which channel names are bolded in the channel list. If you find a channel with new content, you can open it.

And Even if You Have More Than Five Channels

Even if someone can access more than five channels, the Discover feed might not be much good if only one or two of the channels are active because the only messages that end up in the feed will come from the active channels. Again, it’s often easier to check what’s going on in a small set of active channels.

No Real Interest from Me for Now

To be honest, I had forgotten that the Discover feed existed. It was only the appearance of MC1066160 that made me look at the feed again. Even in its new focused mode, I don’t think the feed will do much for me until Microsoft updates the Discover feed to support guests.

More information about the Discover feed is available in this Microsoft support article.

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.

Update #12 Available to Help People Figure Out Microsoft 365 PowerShell

As is our norm, we have released the monthly update for the Automating Microsoft 365 with PowerShell eBook some days before the end of the month to allow us to concentrate on working on the Office 365 for IT Pros eBook. The current version number is 12.2 and the updated PDF and EPUB files are available for subscribers to download from Gumroad.com. Please use the link in your receipt (which always fetches the latest files) or go to your Gumroad account, See our FAQ for more information about downloading book updates.

The Automating Microsoft 365 with PowerShell eBook is available separately and as part of the Office 365 for IT Pros eBook bundle. The same update is available to all subscribers.

We also have a paperback version of the book available from Amazon.com. This version is proving to be more popular than we anticipated. I guess some people still like the tactile experience of reading a real book, and we are happy to oblige. Regretfully, we cannot provide monthly updates to the paperback edition as there’s no way to paste (literally) updated text into paper copies.

Focus Areas for Update #12

Most of the work in Update #12 focused on adding extra detail to the sections covering retrieving calendar information, messages, group-based license assignments, and sensitivity labels. Like always, a bunch of other changes were made to clarify thoughts or correct possible misinterpretations.

It’s the nature of a book like this that developments in Microsoft’s tools affect our content, so some Graph API requests that were used because of problems with Microsoft Graph PowerShell SDK cmdlets are now replaced by cmdlets following the release of V2.28 of the SDK on May 10, 2025.

Should I Upgrade to V2.28 of the Graph PowerShell SDK?

So far, the experience with V2.28 is positive. However, this isn’t a massive endorsement because the previous versions were so buggy and poorly tested prior to release. I think it’s safe to say that V2.28 is at least as good as V2.25, which was the last good release.

This does not mean that V2.28 is bug free. I think it would be impossible to release even a 99% bug-free Graph PowerShell SDK. The number of dependencies on many different product groups, the complex interactions with other PowerShell modules and products like Azure Automation, and the errors and omissions in the Open API documents that describe the different Graph APIs all create the potential for problems like missing parameters or failure to process parameters properly. Throw in some Entra ID authentication problems, like the current bug that sometimes requires double authentication after running the Connect-MgGraph cmdlet to create an interactive session, and it’s easy to understand why there’s over 160 reported issues for the SDK.

Bugs are a fact of IT life, and the presence of some known bugs is no reason to avoid using the Graph PowerShell SDK. In fact, the SDK is more popular now than ever before because of the retirement of the AzureAD and MSOL modules (some people still ask why they can’t run Connect-MSOLService or Connect-AzureAD like they used to…). It does mean that you should:

• Pay attention to the known bugs reported to Microsoft.
• Report any bugs that you find that aren’t on the known issues list.
• Be prepared to use the underlying Graph API if a Graph PowerShell SDK cmdlet doesn’t work as expected (alternatively, if a parameter doesn’t work, try passing values in a hash table using the BodyParameter parameter).

Overall, I think it’s safe to upgrade to V2.28. Remember to upgrade modules used as resources by Azure Automation accounts too.

On to Update #13

Work has now started on update #13, which is planned for July 1. This version of the book will be part of Office 365 for IT Pros (2026 edition), which we plan to release on the same day. Happy coding!

The Latest Iteration of Channel Note Taking

In the past, every Teams channel had the Wiki tab to facilitate information sharing between channel members. The Wiki tab went away in 2023 and was replaced by OneNote. Many people love OneNote and that app is still a good option that’s been joined by Loop workspaces. According to Microsoft 365 notification MC973493 (last updated 9 May 2025, Microsoft 365 roadmap item 472022), deployment of the update to enable adding a Loop workspace as a channel tab will complete by the end of May 2025.

Loop workspaces appeared when Microsoft shipped the Loop app in 2023. At that point, Loop workspaces were personal. It’s taken since then to enable support for the features necessary to support Teams such as Microsoft 365 groups and sensitivity labels.

Making Loop Workspaces Possible

Adding a Loop workspace as a channel tab allows everyone in the team to work on the same content (organized in workspace pages and Loop components) with changes synchronized in almost real time. Like all resources managed by a Microsoft 365 group, all team members have equal access to the Loop workspace.

Three prerequisites must be met before Loop workspaces can be added as a channel tab:

1. The tenant must enable use of the Loop app.
2. Team members who want to create workspaces must have a license that includes Loop.
3. The Loop Teams app must be available to team members (Figure 1). Updating access for the app in the Teams admin center can take several hours to become effective.

With everything in place, team members allowed to add channel tabs can add a new tab and choose Loop as the app for the tab. They can use the channel name for the workspace or choose a different name (Figure 2).

Once the workspace is active, team members can interact with the Loop workspace in the same way as they’d do through the Loop app, adding components and pages to organize content. In Figure 3, I’ve added a task list component to help organize the publication of the next edition of the Office 365 for IT Pros eBook. Like task lists in Loop components in Outlook or Teams chat, a team member can open the tasks in Planner or To Do.

SharePoint Embedded Container

Like other Loop workspaces, the physical instantiation for the new workspace is a SharePoint Embedded container that’s visible through the SharePoint admin center (Figure 4). Note that the owner of the container is the Microsoft 365 group and the ownership type is group rather than personal. The container receives the same sensitivity label as assigned to the owning group at the time of creation.

The workspace is quite separate to Teams. If a team member removes the channel tab by mistake, it’s easy to recreate the tab and reconnect the workspace. If the team is deleted, the workspace is also deleted like other team resources. Likewise, if a deleted team with a workspace is restored within the 30-day grace period, the workspace is also restored.

Loop workspaces are restricted to standard Teams channels. They don’t support the membership models used by private and shared channels. This is understandable because Loop has only just mastered the art of using Microsoft 365 groups for membership management.

Long-term Replacement for OneNote?

Some commentators believe that Loop will eventually replace OneNote. Certainly, Microsoft development appears to be focused on Loop these days and Microsoft is building Loop into as many places within Microsoft 365 as possible. Copilot Pages is a notable example of a Loop-powered app. It wouldn’t be surprising if Microsoft rationalized its note-taking apps around Loop in the future.

Before rationalizing anything, it would be nice if Microsoft updated the Get-SPOContainer cmdlet (from the SharePoint management module) to handle workspaces owned by Microsoft 365 groups. I updated my script to report Loop workspaces to handle group-owned workspaces, but the detail about the containers just isn’t there today.

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.

Solves the Problem of Migrating Data Protected by Sensitivity Labels

I’ve worked as an advisor with Quest for several years, but I had no indication that they would launch a product to migrate content protected by sensitivity labels from one Microsoft 365 tenant to another. That capability is now available in Quest On Demand Migration.

The tenant migration issue has existed since Microsoft introduced Azure Information Protection labels (now sensitivity labels) in 2016. The problem doesn’t arise with labels that simply mark content as being of a certain nature. It comes into play when sensitivity labels apply rights-management based encryption where usage rights define the level of access granted to individual users for protected files or messages.

The popularity of sensitivity labels has increased over time as more tenants come to understand the value of protecting their most sensitive content using the labeling features built into the Office apps. It’s true that labeling only extends to Office documents and PDFs, but that set covers most files created within Microsoft 365 tenants.

The advent of Microsoft 365 Copilot and its ability to find and use files stored in SharePoint Online and OneDrive for Business means that sensitivity labels are even more important. By themselves, sensitivity labels won’t stop apps like BizChat finding sensitive documents, but they can stop Copilot reusing content from those documents in its responses. The DLP policy for Microsoft 365 Copilot imposes a better block by stopping Copilot finding documents assigned specific sensitivity labels.

The growth in protected content creates a problem for tenant-to-tenant migration projects. Many products are available to move Exchange mailboxes and SharePoint files between tenants. However, migration products usually assume that the data they move is unprotected and that users will be able to access the content once it reaches the target tenant. That assumption doesn’t hold true when sensitivity labels protect email and files. The challenge is to move protected items from the source tenant in such a way that protection is maintained and respected by the target tenant.

Methods to Remove Sensitivity Labels from Files

Until now, the guidance for source tenants is to remove protection from content before migration to the target tenant. There are a couple of ways of doing this, starting off by assigning an account super-user privilege to allow them to remove sensitivity labels from files. Finding and processing protected files is an intensely manual process that’s prone to error. It will take a long time to prepare, move, and check any reasonable collection of labelled files, like the 5,188 items with the Public label as reported by the Purview Data Explorer (Figure 1).

The SharePoint Online PowerShell module includes the Unlock-SPOSensitivityLabelEncryptedFile cmdlet. Administrators can use the cmdlet to remove protection from files in SharePoint sites and OneDrive for Business accounts. It is possible to script the removal of labels from files, but the automation journey breaks down when the files reach the target tenant and need to be relabeled.

SharePoint also supports the assignSensitivityLabel Graph API, which can remove or assign labels to files. However, assignSensitivityLabel is a metered API, meaning that each time the API is run, Microsoft charges $0.00185 (USD) paid for through an Azure subscription. That doesn’t seem like a big fee until the need exists to process tens of thousands of documents to remove labels in the source tenant and reapply labels in the target tenant.

No Solution for Protected Exchange Messages

Note that Exchange Online is missing from the discussion. That’s because all the methods described so far don’t handle email. I don’t know how clients like Outlook and OWA apply sensitivity labels to messages (it’s likely done using APIs from the Microsoft Information Protection SDK), but no cmdlets or Graph APIs are available to remove labels from messages or apply sensitivity labels in bulk to a set of messages migrated in mailboxes moved from one tenant to another.

Migrating Protected Content Between Tenants

All of which means that Quest’s claim to migrate protected content from Exchange Online, SharePoint Online, and OneDrive for Business is very interesting. It’s the first ISV migration offering that I know of which offers such a capability.

Reading the announcement and the accompanying Quest Knowledge Base article gives some insight into how the On Demand product handles protected items. A discovery process (like running the Get-Label cmdlet) finds the set of sensitivity labels in the source tenant. The labels from the source tenant are mapped to labels in the target in some form of table. Normal migration processing moves the data, and some form of post-migration task then updates the labels from the source tenant to matching labels for the target. Quest doesn’t describe what magic is used to make sure that protected content works when it reaches the target tenant, but the knowledge base article mentions the Microsoft Information Protection SDK, so it’s likely that On Demand uses MIP SDK API calls to read and update sensitivity labels for the migrated items.

User-Defined Permissions and Keys

Although creating the capability to move protected content between tenants is a great step forward for migration projects, there are always edge cases to consider. Sensitivity labels with user-defined permissions are an example. These labels are challenging because the permissions vary from item to item. SharePoint Online only recently gained support for sensitivity labels with user-defined permissions, and it’s interesting that Quest claim support for user-defined permissions out of the box.

Quest doesn’t mention sensitivity labels with double-key encryption (DKE), nor do they explain if On Demand supports migration of sensitivity labels with encryption based on customer keys rather than Microsoft-managed keys (sometimes called bring-your-own-key or BYOK). There’s a bunch of complexity involved in moving key management between tenants and it would be surprising if Quest supported BYOK. Thankfully, most customers use Microsoft-managed keys with sensitivity labels because it simplifies operations.

Let the Competition Begin

Overall, it’s great that an ISV has taken on and solved the challenge of moving protected content between tenants. The nature of competition is that once a migration vendor introduces a new capability, their competitors respond. We might see even more interesting developments in this space over the coming months.

Unless You Consider Excel Passwords to be Real Passwords

I see that some web sites have picked up the penetration test story about using Microsoft 365 Copilot to extract sensitive information from SharePoint. The May 14 Forbes.com story is an example. The headline of “New Warning — Microsoft Copilot AI Can Access Restricted Passwords” is highly misleading.

Unfortunately, tech journalists and others can rush to comment without thinking an issue through, and that’s what I fear has happened in many of the remarks I see in places like LinkedIn discussions. People assume that a much greater problem exists when if they would only think things through, they’d see the holes in the case being presented.

Understanding the Assumptions made by the Penetration Test

As I pointed out in a May 12 article, the penetration test was interesting (and did demonstrate just how weak Excel passwords are). However, the story depends on three major assumptions:

• Compromise: The attacker has control of an Entra ID account with a Microsoft 365 Copilot license. In other words, the target tenant is compromised. In terms of closing off holes for attackers to exploit, preventing access is the biggest problem in the scenario. All user accounts should be protected with strong multifactor authentication like the Microsoft authenticator app, passkeys, or FIDO-2 keys. SMS is not sufficient, and basic authentication (just passwords) is just madness.
• Poor tenant management: Once inside a tenant and using a compromised account, Microsoft 365 Copilot will do what the attacker asks it to do, including finding sensitive information like a file containing passwords. However, Copilot cannot find information that is unavailable to the signed-in user. If the tenant’s SharePoint Online deployment is badly managed without well-planned and well-managed access controls, then Copilot will happily find anything that the user’s access allows it to uncover. This is not a problem for Copilot: it is a failure of tenant management that builds on the first failure to protect user accounts appropriately.
• Failure to deploy available tools: Even in the best-managed SharePoint Online deployment, users can make mistakes when configuring access, Users can also follow poor practice, such as storing important files in OneDrive for Business rather than SharePoint Online. But tenants with Microsoft 365 Copilot licenses can mitigate against user error with tools available to them such as Restricted Content Discovery (RCD) and the DLP policy for Microsoft 365 Copilot. The latter requires the tenant to deploy sensitivity labels too, but that’s part of the effort required to protect confidential and sensitive information.

I’m sure any attacker would love to find an easily-compromised tenant where they can gain control over accounts that have access to both badly managed SharePoint Online sites that hold sensitive information and Microsoft 365 Copilot to help the attackers find that information. Badly-managed and easily-compromised Microsoft 365 tenants do exist, but it is my earnest hope that companies who invest in Microsoft 365 Copilot have the common sense to manage their tenants properly.

Uploading SharePoint and OneDrive Files to ChatGPT

Personally speaking, I’m much more concerned about users uploaded sensitive or confidential information to OpenAI for ChatGPT to process. The latest advice from OpenAI is how the process works for their Deep Research product. Users might like this feature because they can have their documents processed by AI. However, tenant administrators and anyone concerned with security or compliance might have a different perspective.

I covered the topic of uploading SharePoint and OneDrive files to ChatGPT on March 26 and explained that the process depends on an enterprise Entra ID app (with app id e0476654-c1d5-430b-ab80-70cbd947616a) to gain access to user files. Deep Research is different and its connector for SharePoint and OneDrive is in preview, but the basic principle is the same: a Graph-based app uploads files for ChatGPT to process. If that app is blocked (see my article to find out how) or denied access to the Graph permission needed to access files, the upload process doesn’t work.

Set Your Priorities

I suggest that it’s more important to block uploading of files from a tenant to a third-party AI service where you don’t know how the files are managed or retained. It certainly seems like a more pressing need than worrying about the potential of an attacker using Microsoft 365 Copilot to run riot over SharePoint, even if a penetration test company says that this can happen (purely as a public service, and not at all to publicize their company).

At least, that’s assuming user accounts are protected with strong multifactor authentication…

Two Workplace Analytics Service Plans to Enable Viva Insights

Microsoft message center notification MC1009917 (last updated 25 April 2025, Microsoft 365 roadmap item 471002) announced the inclusion of Viva Insights in the Microsoft 365 Copilot license. The mechanism used is the addition of two “Workplace Analytics” service plans to join the existing eight service plans (table 1) that make up the Copilot license. More information is available in the documentation for the Copilot features made available by these service plans.

Table 1: Microsoft 365 Copilot Service Plans

The last update from Microsoft said that updates to add the Viva Insights service plans completed in mid-April 2025.

Viva Insights and Microsoft 365 Copilot

According to Microsoft, access to Workplace Analytics allows “IT admins and analysts can tailor advanced prebuilt Copilot reports with their business data or create custom reports with organizational attributes, expanded Microsoft 365 Copilot usage metrics, and more granular controls.” The data is exposed in Viva Insights (web), the Viva Insights Teams app (Figure 1), and the Viva Insights mobile apps.

Everyone running a Copilot deployment is intimately aware of the need to track and understand how people use AI in different apps. The API behind the Copilot usage report in the Microsoft 365 admin center delivers sparse information. It’s possible to enhance the usage report data with audit data and use the result to track down people who don’t make use of expensive licenses, but that requires custom code. Hence the insights reported in the Copilot Dashboard in Viva Insights.

A note in the announcement says that access to the Copilot Dashboard now requires a minimum of 50 Viva Insights (Copilot) licenses. As obvious from Figure 1, my tenant has fewer than 50 licenses, but can still use Viva Insights because it’s not a new tenant.

What Service Plans Do

As you’re probably aware, a license (product, or SKU) is something that Microsoft sells to customers. A service plan enables or disables specific functionality within a license. For example, the Copilot license includes the Copilot Studio in Copilot for Microsoft 365 service plan, which in turn allows users to create agents in Copilot Studio. If you don’t want people to be able to access Copilot Studio, you can disable the service plan.

Disabling a service plan can be done by updating a user’s licenses through the Microsoft 365 admin center. Options are available to do this through User Accounts or License Details (Figure 2).

If you use group-based licensing, you can amend the options for the Copilot license to remove service plans. However, this affects every user in the group, so you might end up with one group to assign “full” Copilot licenses and another to assign “restricted” licenses.

Be Careful When Disabling Copilot Service Plans

One potential issue with some Copilot service plans is that you’re never quite sure what removing a service plan will do. Removing the Microsoft 365 Copilot in Productivity Apps service plan seems straightforward because it disables the Copilot options in the Office desktop apps (all platforms). But disabling the Intelligent Search service plan will mess up any app that uses Copilot to search.

Blocking Copilot Studio is problematic. Removing the service plan only removes the ability of a user to sign in to use Copilot Studio. They can still sign in for a 60-day trial, just like anyone else with an email address who doesn’t have a Copilot Studio license.

Disabling Copilot Service Plans with PowerShell

Disabling service plans through a GUI can rapidly become tiresome. I wrote a PowerShell script to (downloadable from GitHub) to demonstrate how to use the Set-MgUserLicense cmdlet from the Microsoft Graph PowerShell SDK to disable a Copilot service plan. Another variation on removing service plans is explained here.

The script checks for group-based license assignment for Copilot licenses and if found, creates an array of excluded accounts that it won’t process. It then scans for accounts with a Microsoft 365 Copilot license and if the account isn’t excluded, runs Set-MgUserLicense to disable the Copilot Studio service plan. It’s just an example of using PowerShell to automate a license management operation and is easily amended to process any of the Copilot service plans. Enjoy!!

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology. The Office 365 book package includes the Automating Microsoft 365 with PowerShell eBook.

Microsoft Layoffs Remind Microsoft 365 Tenants About the Need to Preserve Ex-Employee Data

This week’s news that Microsoft is trimming 3% of its global workforce brought shock to those affected by the elimination of their position. My LinkedIn feed has been flooded by updates from people who discovered that they’re in a position that they never anticipated, some of whom have been with Microsoft for many years. I’ve been involved in many downsizing actions at Digital Equipment Corporation, Compaq, and HP, and it’s never easy for managers and employees alike. I wish all those affected the best of luck in finding new positions.

The hope of Microsoft management is probably that the layoffs will result in a leaner, more agile organization, the only goodness for the Microsoft 365 community that comes from the episode is that it’s a great reminder for tenant administrators to review the process used to secure ex-employee information following a termination.

Changes in Microsoft 365 Make It More Complex to Preserve Ex-Employee Data

Ten years ago, the task was relatively simple because fewer types of information needed to be secured. Today, new applications and more integration between applications means that the task is more complex.

The basics remain:

• Terminating access to resources by revoking access tokens, disabling accounts, and changing account passwords.
• Physically securing devices (workstations and mobile devices) or remote wipes to remove corporate content.
• Preserving application information such as mailboxes and OneDrive for Business accounts.

Deleting a user account via the Microsoft 365 admin center (Figure 1) takes care of the basics. To do a more comprehensive job, it’s best to script all the steps with PowerShell.

I recommend using inactive mailboxes to retain mailbox content rather than making a regular user mailbox into a shared mailbox, but advantages exist for both approaches. Happily, not much has recently changed with mailbox retention. The situation is completely different with OneDrive for Business in terms of the app reliance on OneDrive and how Microsoft deals with unlicensed OneDrive accounts.

The Key Role Played by OneDrive for Business

OneDrive for Business has become the de facto storage destination for many Microsoft apps, storing files as diverse as Loop components, Teams meeting recordings, and whiteboards. Microsoft’s enthusiasm knows no boundaries when it comes to storing files in OneDrive for Business. Even PowerShell module installations end up in OneDrive for Business if you’re not careful.

Message center notification MC1053121 (last updated 23 April 2025) describes how users who don’t use the Known Folder Move (KFM) feature to redirect common folders like Documents from local disks to OneDrive will be more aggressively “encouraged” to back up files in OneDrive for Business. This change is rolling out to general availability and should be active worldwide by mid-June 2025. If you don’t like users seeing this kind of prompting, consider the new Restrict KFM from Office policy for the Office apps (see MC1053121 for details).

Because OneDrive for Business accounts owned by ex-employees are so important from a retention perspective, it’s important to ensure an alternative site administrator (usually the ex-employee’s manager) is assigned to these accounts so that any useful information in the account is retained. Moving shared objects like Loop components or files shared in Teams chats from the account will break sharing. Eventually, the organization can remove the OneDrive account. If the account remains online, Microsoft will archive the now-unlicensed OneDrive account. Deleting or archiving the account will also break sharing!

The challenges of dealing with OneDrive accounts owned by ex-employees is one of the reasons why it is important to coach users to store corporate information in SharePoint Online instead of keeping files in OneDrive for Business. Unfortunately, that advice is often observed more in theory than practice.

The New Challenge Posed by Flows and Agents

Power Platform flows are often tied to a user account. If the account goes away or is disabled, the flow will stop working. That shouldn’t be a problem if the process performed by the flow is personal to the now-departed employee. On the other hand, if the flow does something that others depend on, that process is now broken and needs to be fixed.

The same applies to agents. It all depends on what an agent does and who uses it. Personal agents will stop running when an account is no longer available to authenticate and that shouldn’t be a problem. But we’re at the early stages of understanding the development, deployment, and management of agents within Microsoft 365 tenants, and care must be taken to ensure that any agents created and maintained by ex-employees remain functional when needed or are disabled and removed if not. This doesn’t happen automatically when an administrator disables or deletes a user account.

Other Issues Requiring Attention

Apart from personal data, there are other issues that might need attention to preserve ex-employee data, including the ownership of:

• Microsoft 365 groups, security groups, and distribution lists.
• Loop workspaces and the associated SharePoint Embedded container.
• Entra ID apps.
• Recurring meetings.
• Phone numbers for use with the Teams Phone system.

The point is that the Microsoft 365 ecosystem continues to evolve. This means that processes and procedures used to manage access to Microsoft 365 resources must evolve in step. This week’s Microsoft layoffs are a regrettable reminder of that fact.

Keep up with the changing world of the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. Monthly updates mean that our subscribers learn about new developments as they happen.

One Step Forward, Six Steps Back for Flawed Releases

Literally millions of people download and use the Microsoft Graph PowerShell SDK. With the retirement of the older Azure AD and MSOL modules, an obvious spike in the number of downloads occurred, all of which meant that the SDK is now a critical automation component for many Microsoft 365 tenants.

On May 10, 2025, Microsoft released V2.28 of the Microsoft Graph PowerShell SDK to the PowerShell Gallery (Figure 1). This release follows a catalog of woe since the release of V2.26 of the Graph PowerShell SDK on February 25, 2025. In an attempt to stem a cascade of bugs, Microsoft followed up by releasing V2.26.1, and V2.27 in April. It was all to no avail. In a case of one step forward, six steps back, V2.27 addressed a problem with Azure Automation but introduced the disappearing payload issue.

Disappearing Payloads

Graph API requests to create or update objects like users, groups, and policies usually include a JSON-formatted payload containing parameter values or instructions. Graph SDK cmdlets also use payloads, usually formatted as hash tables, that are passed to the underlying Graph API requests when the cmdlets run. You can see the Graph API request and payload used by an SDK cmdlet by including the Debug parameter.

Soon after the release of V2.27, developers complained that cmdlets did not pass the provided payload. An example of the problem is the inability to pass parameters when assigning licenses to user accounts with the Set-MgUserLicense cmdlet. Because license management is such an important task, this problem easily fell into the “must fix quick” category. Another example is when the payload disappears when updating an application with the Update-MgApplication cmdlet, or when creating a new calendar event with New-MgUserEvent ignores the start and end times.

Running what appears to be perfectly good code (often copied from Microsoft documentation) only to run into inexplicable failures is frustrating and annoying. A problem like this happening after a succession of flawed releases is especially worrisome because you’d expect Microsoft to have upped their game and improved software release processes.

Cautious Optimism

At this point, just a few days since the release of V2.28, I am cautiously optimistic. Microsoft is closing SDK issues in GitHub as people test the problems reported with previous releases. I have not experienced any new problems, scripts run without problems (aside from my own bugs), and everything works with PowerShell 5.1 runbooks in Azure Automation, as far as I can see (or rather, test). PowerShell V7 runbooks are still problematic and will remain so until Azure Automation supports PowerShell V7.4 in mid-June 2025.

I guess the takeaway is that V2.28 of the Microsoft Graph PowerShell SDK seems to be as stable as V2.25. Given that Microsoft has fixed some bugs, V2.28 is likely a little better. That’s as far as I would go at this point. V2.28 is definitely worth testing in a development environment to make sure that production scripts run with.

Each installation of the Microsoft Graph PowerShell SDK leaves a bunch of modules on your PC. When you install, make sure that you clean out old files and reboot, just to make sure that the new modules are used. To make things a little easier, I have a script to install and clean up modules on a local PC and another to update the Graph PowerShell modules used with Azure Automation.

Next Steps

I doubt that V2.28 will be perfect. New bugs will emerge, and we already know that some reported bugs are not fixed. One issue that I am tracking is where interactive sessions fail to recognize URIs when running cmdlets (including Invoke-MgGraphRequest) and respond with an “Invalid URI: The format of the URI could not be determined.” error. Running Connect-MgGraph to reconnect the session restores everything to good health, but suddenly losing the ability to run cmdlets is a disturbing problem that Microsoft needs to fix.

Overall, I’m not all that worried about seeing a few new bugs or having to wait a little longer for Microsoft to fix known issues. If you do find a bug, please take the time to report it by filing a report in GitHub. Don’t complain if things are not fixed if you don’t report the problem.

All I want is to see V2.28 resort relative stability to the Microsoft Graph PowerShell SDK in such a way that Microsoft 365 tenants can depend on it for day-to-day management of users, groups, licenses, devices, and other objects. That’s not too much to ask.

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.

Maybe a Microsoft 365 Retention Policy is Better than an eDiscovery Hold

Last month, I wrote about how to replace Exchange Online litigation holds, which only preserve mailbox content, with holds applied by Purview eDiscovery cases. The advantage gained by this exercise is that eDiscovery holds can also secure the OneDrive for Business accounts owned by specific users, including those who leave the company.

My idea works, but it’s unnatural. eDiscovery cases are designed to secure information required by eDiscovery investigations, not to preserve information for indeterminate periods. Retention policies are the designated Microsoft 365 mechanism to retain information. Still, I enjoyed probing how to use eDiscovery case holds, and the good news is that much of the code written to prove the principle can be repurposed for retention policies.

Using a Retention Policy

A Microsoft 365 retention policy can cover many different types of data. In terms of mailbox data, a Microsoft 365 retention policy isn’t as granular as Exchange (“legacy”) retention tags, nor does a Microsoft 365 retention policy support the move to archive action to move items from a primary mailbox into its associated archive mailbox. For these reasons, Microsoft hasn’t deprecated Exchange retention policies and tags.

The question of granularity doesn’t arise with litigation holds because a litigation hold retains everything in the primary and archive mailbox. We can therefore replace litigation holds with a retention policy to hold everything indefinitely, and that policy will place a hold on everything in the mailboxes and OneDrive accounts that are added as locations to the policy.

Dealing with the 1,000-Location Limit

The only real limitation that exists is the maximum number of locations supported for Exchange mailboxes and OneDrive accounts. A retention policy that uses static locations can add up to 1,000 locations for each type. It’s unlikely that a tenant will have more than 1,000 mailboxes on litigation hold, but if this is the case, the choice is to either split the locations across multiple retention policies or use an adaptive scope to identify the mailboxes. A retention policy based on an adaptive scope isn’t subject to the 1,000-location limit.

The easiest way to mark mailboxes to be found by an adaptive scope is to set a value in one of the fifteen custom properties available for mailboxes. Each of the mailboxes (accounts) covered by an adaptive scope requires an Office 365 E5, Microsoft 365 E5, or Microsoft E5 Compliance license.

Creating the Retention Policy and Rule

A retention policy consists of two parts. The policy defines the set of target locations, like Exchange mailboxes, OneDrive accounts, SharePoint Online “classic” sites, and Microsoft 365 groups. Figure 1 shows the target locations for a “standard” retention policy. Specific retention policies can be created for Teams channel messages, Teams chat and Copilot interactions, and Viva Engage (Yammer) community messages.

The policy rule defines the retention settings, or what the policy does to the items found in the target locations. In this instance, the rule is very simple because the idea is to mimic what a litigation hold often does, which is to apply an unlimited hold. Litigation holds do accommodate a limited duration hold, and it would be possible to recreate this kind of hold with a retention policy, but here we’re just proving the principle, so it’s enough to show how to create the retention policy and a rule to hold continue indefinitely. Here’s the code:

Write-Host "Creating Microsoft 365 retention policy to replace litigation holds..." -ForegroundColor Yellow
$NewPolicy = New-RetentionCompliancePolicy -Name "Litigation Hold Retention Policy" -ExchangeLocation $MailboxesToHold -OneDriveLocation $OneDriveToHold  `
    	-Comment ("Retention policy to replace litigation holds created by Switch-LitigationHoldsforRetentionPolicies.PS1 script on {0}" -f (Get-Date).ToString("dd-MMM-yyyy")) `
If ($NewPolicy) {
    Write-Host ("Retention policy {0} created" -f $NewPolicy.Name) -ForegroundColor Green
    $NewPolicyRule = New-RetentionComplianceRule -Name LitigationHoldRule -Policy "Litigation Hold Retention Policy" -RetentionDuration unlimited `
        -Comment "Created by Switch-LitigationHoldsforRetentionPolicies.PS1 script" 
    If ($NewPolicyRule) {
        Write-Host ("Retention rule {0} created" -f $NewPolicyRule.Name) -ForegroundColor Green
    } Else {
        Write-Host "Failed to create retention rule" -ForegroundColor Red
        Break
    }
} Else {
    Write-Host "Failed to create retention policy" -ForegroundColor Red
    Break
}

If you want to create a more complicated retention rule, it’s probably best to do so via the Purview compliance portal GUI. You can download the script I used from GitHub.

After applying a retention policy, it can take a few days before the policy becomes fully effective. I’d wait a week and then remove the litigation holds from the mailboxes.

Dump Litigation Holds Now

I don’t hesitate to recommend phasing litigation holds out in favor of retention policies. At this point, litigation holds are a dead-end street that Microsoft is putting little or no effort into. By comparison, Microsoft 365 retention policies are more functional and under active development, which makes them a better long-term bet for meeting the retention needs of Microsoft 365 tenants.

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.

Make Sure that Users Can’t Download Copies of Attachments to Unmanaged Devices

A recent encounter with David Los in Microsoft’s HQ in Redmond reminded me of a relatively unknown feature of OWA mailbox policies that might be of interest as the new Outlook for Windows progresses. In October 2018, David wrote about how to combine a setting in a OWA mailbox policy with an Entra ID conditional access policy to block the download of attachments on untrusted (unmanaged) devices. It’s a similar idea to the SharePoint Online’s block download access policy.

Fast forward seven years and OWA mailbox policies control many aspects of how the new Outlook for Windows work, so let’s see if the setting works as well for it as it does for OWA.

Updating the Conditional Access Setting for an OWA Mailbox Policy

The magic starts with the ConditionalAccessPolicy setting in a OWA mailbox policy. The values of the setting can be:

• Off (default): Exchange Online doesn’t attempt to apply a CA policy.
• ReadOnly: Users can’t download attachments to make local copies (which means that they cannot use the Office apps to edit files). They can view attachments in the browser.
• ReadOnlyPlusAttachmentsBlocked: User cannot view attachments at all.

To set the block in the OWA mailbox policy, sign into the Exchange Online management PowerShell module with an account holding the Exchange administrator role and run the Set-OWAMailboxPolicy cmdlet to update an OWA mailbox policy. I don’t recommend that you update the default policy unless you want the block to apply to all users. Choose a different policy (or create a new policy by running the New-OWAMailboxPolicy cmdlet instead).

After updating the policy, run the Get-OWAMailboxPolicy cmdlet to check that the setting is in place for the chosen OWA mailbox policy. Note that the ConditionalAccessFeatures property for the policy reports the set of restrictions for OWA to enforce.

Set-OWAMailboxPolicy -Identity NoOfflineAccess -ConditionalAccessPolicy ReadOnly
Get-OWAMailboxPolicy -Identity NoOfflineAccess | Format-List ConditionalAccess*

ConditionalAccessPolicy   : ReadOnly
ConditionalAccessFeatures : {Offline, AttachmentDirectFileAccessOnPrivateComputersEnabled, AttachmentDirectFileAccessOnPublicComputersEnabled, AttachmentPrintWithoutDownload}

When the ConditionalAccessPolicy setting is ReadOnlyPlusAttachmentsBlocked, the AttachmentWacViewingOnPrivateComputersEnabled and AttachmentWacViewingOnPublicComputersEnabled are added to the set of restrictions.

Use the Set-CASMailbox cmdlet to apply the OWA mailbox policy to a mailbox. It normally takes about 15 minutes for an updated policy to be effective. In the meantime, run Get-CASMailbox to check which mailboxes come within the scope of the policy, just in case some other mailboxes are affected.

Set-CasMailbox -Identity "Marty.King" -OwaMailboxPolicy 'NoOfflineAccess'
Get-CasMailbox -RecipientTypeDetails UserMailbox | Where-Object {$_.OWAMailboxPolicy -eq 'NoOfflineAccess'} | Format-Table DisplayName, OWAMailboxPolicy

Create a Conditional Access Policy to Block OWA Downloads

Figure 1 illustrates the details of the conditional access policy to enforce the blocks specified in the OWA mailbox policy. The session control for the CA policy says: “use app enforced restrictions,” which is the set of restrictions defined in the OWA mailbox policy. The only role conditional access has here is to notify the selected app(s) that they should apply restrictions because the device used for the connection is unmanaged.

The app is Office 365 Exchange Online, the enterprise app used by Exchange Online for many purposes, including OWA (its role in managing hybrid rich coexistence is being replaced by a dedicated tenant app soon).

Testing the Block Download Policy with OWA

To test the policies, I ran OWA on an iPad (an unmanaged device). A banner on messages with attachments informed me that the block on download and printing existed (Figure 2). Microsoft refers to this as the “limited access experience.”

A side-effect of imposing the CA policy is that the light version of OWA is blocked, probably because the light version is so simple that it doesn’t include the necessary smarts to handle the CA policy.

Testing with the New Outlook for Windows

Experience so far of managing the new Outlook is that settings from OWA mailbox policies apply to the Monarch client. Testing confirms that this is also true for conditional access restrictions. Installing and running the new Outlook for Windows on a Windows PC shows that the client picks up the same restriction as applied to OWA (Figure 3).

It’s nice that the restrictions imposed by the OWA mailbox policy work, but it would be nicer if the documentation reflected the fact. I’m sure Microsoft will get around to updating its web pages. In the meantime, to learn more about blocking access to downloads, here’s a Practical365.com article to read.

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

Can Attackers Use Copilot for Microsoft 365 to Help Find Information?

An article by a UK-based security penetration test company titled “Exploiting Copilot AI for SharePoint” drew my attention to see what weaknesses testing had found. I was disappointed. Although the article makes some good points, it doesn’t tell reveal anything new about the potential issues that can arise due to poor protection of information stored in SharePoint Online sites. Let’s discuss the points raised in the article.

A Compromised Account

Copilot for Microsoft 365 always works as a signed in user. Before an attacker can use Copilot for Microsoft 365, they must be able to sign into a licensed user’s account. In other words, that account is compromised. That’s bad for a tenant because any compromise can lead to data loss or other damage, and it’s probably indicative of other problems that attackers can exploit without going near Copilot.

Organizations should protect themselves with strong multifactor authentication (MFA). That message seems to be slowly getting through, and you’d imagine that any tenant willing to invest in Copilot is also willing to protect themselves by insisting that all accounts are protected by MFA.

Seeking Sensitive Information

The authors make a good point that people often store sensitive information in SharePoint Online. Attackers like to search for information about passwords, private keys, and sensitive documents. Copilot undoubtedly makes it much easier for attackers to search, but I don’t think that the default site agents create any vulnerability because these agents are constrained to searching within the sites they belong to.

Custom agents might be more problematic, but that depends on the information accessed by the agents. It also depends on the penetrated user being able to run the custom agents. The big thing to remember here is that Copilot can only access data available to the account being used. Custom agents in the hands of an attacker can’t automagically get to some hidden data. Anyway, organizations should monitor the creation of agents and have some method to approve the use of those agents.

Accessing Password Data

The penetration team reported that they had found an interesting file (an encrypted spreadsheet) that appeared to contain passwords that SharePoint blocked access to because “all methods of opening the file in the browser had been restricted.” This sounds like SharePoint’s block download policy was in operation for the site. However, Copilot was able to fetch and display the passwords stored in the file.

It’s likely that the spreadsheet was “encrypted” using the default Excel protection applied when a user adds a password to a spreadsheet. However, the encryption is no match for Microsoft Search, which can index the information in the file, and that’s what Copilot for Microsoft 365 Chat was able to display (Figure 1).

Excel’s encryption is very poor protection in the era of AI. Sensitivity labels should be used to secure access to sensitive information, specifically labels that do not allow Copilot to extract and display information from files found by searching against Microsoft Search. Even better, use the DLP policy for Microsoft 365 Copilot to completely hide sensitive files against Copilot so that not even the file metadata is indexed.

Alternatively, use Restricted Content Discovery (RCD) to hide complete sites so that casual browsing by attackers (or anyone else looking for “interesting” information). Apart from RCD, Microsoft makes other SharePoint Advanced Management (SAM) features available to Microsoft 365 Copilot tenants. There’s no excuse for failing to use the access control and reporting features to secure sensitive sites.

Copilot for Microsoft 365 is a Superb Seeker

Copilot for Microsoft 365 is superb at finding information stored in SharePoint Online and OneDrive for Business. With good prompting, an attacker with access to a compromised account can retrieve data faster than ever before, and unlike previous methods of trawling through SharePoint files, Copilot access doesn’t leave breadcrumbs like entries in the last files accessed list.

Copilot access can be constrained by making sure that suitable permissions are in place for documents, deploying the DLP policy for Microsoft 365 Copilot, and limiting access to confidential sites through Restricted Content Discovery. The DLP policy and RCD are recent Copilot control mechanisms that I don’t think the authors of the penetration test report considered (even though they refer to blocking agents with RCD). But available mechanisms are worthless unless implemented, and the real value of reports like this is to prompt administrators to use available tools, including MFA to reduce the likelihood of a compromised account.

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.

Combine Copilot Usage Data with User Account Details to Gain Better Insight for Deployments

Discussing the usage data that’s available for Microsoft 365 Copilot (in the Microsoft 365 admin center and via a Graph API), a colleague remarked that it would be much easier to leverage the usage data if it contained the department and job title for each user. The usage data available for any workload is sparse and needs to be enhanced to be more useful.

Knowing what data sources exist within Microsoft 365 and how to combine sources with PowerShell or whatever other method you choose is becoming a valuable skill for tenant administrators. I’ve been down this path before to discuss combining usage data with audit data to figure out user accounts who aren’t using expensive Copilot licenses. Another example is combining Entra ID account information with MFA registration methods to generate a comprehensive view of user authentication settings.

Scripting a Solution

In this instance, the solution is very straightforward. Use a Graph API call (complete with pagination) to download the latest Copilot usage data, Find the set of user accounts with a Microsoft 365 Copilot license and loop through the set to match the user account with usage data. Report what’s found (Figure 1).

Obfuscated Data and Graph Reports

The thing that most people trip over is matching usage data with user accounts. This is impossible if your tenant obfuscates (anonymizes) usage data. This facility has been available since late 2020 and if the obfuscation setting is on in the Microsoft 365 admin center, all usage data, including the data used by the admin center and Graph API requests is “de-identified” by replacing information like user principal names and display names with a system-generated string.

It’s therefore important to check the settings and reverse it if necessary for the duration of the script to make sure that you can download “real” user information. If you don’t, there’s no way of matching a value like FE7CC8C15246EDCCA289C9A4022762F7 with a user principal name like Lotte.Vetler@office365itpros.com.

Fortunately, I had a lot of code to repurpose, so the script wasn’t difficult to write. You can download the complete script from the Office 365 for IT Pros GitHub repository.

Finding Areas for Focus

Getting back to the original question, I assume the idea of including job titles and departments with Copilot usage data is to figure out where to deploy assistance to help people understand how to use Copilot in different apps. You could do something like this to find the departments with Copilot users who have no activity in the report period (90 days).

    Group-Object -Property Department | ForEach-Object {
        [PSCustomObject]@{
            Department = $_.Name
            UserCount  = $_.Group.Count
        }
    }

$GroupedReport | Sort-Object -Property Department | Format-Table -AutoSize

Department               UserCount
----------               ---------
Analysis and Strategy            3
Business Development             1
Core Operations                 57
Editorial                        1
Group HQ                         1
Information Technology           3
Marketing                       22
Planning & Action                1
Project Management               1
Research and Development         1

With this kind of output, the team driving Copilot adoption and use for the organization would be wise to spend some time with the Core Operations and Marketing departments to ask why so many of their users don’t appear to be using Copilot.

As noted above, understanding how to use PowerShell to mix and match data sources to answer questions is a valuable skill. There’s lots of data available in a Microsoft 365 tenant. That data is there to be used!

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.

Finding Exchange Mailbox Audit Data Isn’t So Easy Anymore

From an engineering perspective, Microsoft’s decision to decommission the Search-MailboxAuditLog and New-MailboxAuditLogSearch cmdlets makes a ton of sense. Microsoft 365 apps consume shared services, and the unified audit service ingests the data used by these Exchange Online cmdlets. Why incur the engineering and support expense to keep the old on-premises cmdlets going?

Microsoft posted the news on January 14, 2025, and stopped writing audit log data to mailboxes on March 1, 2025. The cmdlets will disappear at the end of 2025. You might have missed this information because Microsoft posted to the security blog instead of the Exchange EHLO blog, where all the other Exchange-related news appears. Perhaps this is because audit data is related to Microsoft Purview and the topic therefore is in the security space. However, losing cmdlets that might be used in Exchange-related administrative processes is a big deal deserving better awareness.

In 2016, Exchange mailbox audit data was one of the first sources of audit events for the unified audit log. Ever since, mailbox audit data has flowed into the unified audit log and can be found by audit log searches, so what’s the problem?

Searching the Unified Audit Log for Exchange Mailbox Audit Data

Searches of the unified audit log can be performed synchronously using the Search-UnifiedAuditLog cmdlet or asynchronously through the Audit section of the Purview compliance portal or by submitting a job through the Graph AuditLogQuery API. Audit log searches can find mailbox data among the many other forms of workload data ingested on an ongoing basis, and searches can go back 180 days (audit standard) or 365 days (audit premium). It all sounds good.

But people build processes around PowerShell cmdlets, and when a cmdlet disappears, those processes must be redeveloped. In this instance, any script that uses the deprecated cmdlets must be altered, probably to use the Search-UnifiedAuditLog cmdlet. And let’s face it, even its biggest fans (and I’m probably in that category) wouldn’t consider Search-UnifiedAuditLog to be an easy cmdlet to use, and Microsoft has tinkered with the way the cmdlet functions over the years. Thankfully, they’ve retreated from the idea of making high completeness (very slow) searches the norm.

The parameters for audit log searches can be complex to construct, duplicate audit records can be retrieved, and there’s always the need to unpack the JSON structure contained in the AuditData property to find out what actually happened for the auditable event.

Those accustomed to interacting with the AuditData property know that every workload decides what information to include in audit events and how that data is formatted. Extracting properties from AuditData usually isn’t hard, but it’s tiresome to see how many variations Microsoft engineers can come up with when inserting data into audit events.

Apart from the issue of interpreting audit events, there’s also the simple fact that it’s easier to extract audit data for the actions of a single user from their mailbox. Finding the relevant information about mailbox events from the unified audit log is more complicated.

Find Exchange Mailbox Audit Data for a Single Mailbox

The easiest way to find audit records for a specific mailbox with the Search-UnifiedAuditLog cmdlet is to pass the user principal name for the mailbox owner (or, to search multiple mailboxes, a set of user principal names) in the UserIds parameter. Here’s an example that finds the audit records for a mailbox and reduces the set to those belonging to Exchange actions:

$RecordType = "ExchangeAdmin","ExchangeItem","ExchangeItemAggregated","ExchangeItemGroup","ExchangeSearch"
[array]$Records = Search-UnifiedAuditLog -Userids ‘kim.akers@office365itpros.com' -StartDate (Get-Date).AddDays(-1) -EndDate (Get-Date) -Formatted -ResultSize 5000 -SessionCommand ReturnLargeSet
$Records = $Records | Where-Object {$_.RecordType -in $RecordType} | Sort-Object Identity -Unique

Searching based on user principal names finds audit records for actions performed by that user. If you want to find audit records for actions performed by a mailbox delegate, use a free text search for the object identifier of the mailbox owner’s account. The free text search finds references to the mailbox owner in the AuditData property and includes those records in the set returned. Here’s an example of using an account identifier in a free text search. It’s important that the identifier is cast as a string as otherwise the search will fail because it will attempt to use a GUID where the cmdlet expects a string:

[array]$Records = Search-UnifiedAuditLog -Freetext ((Get-ExoMailbox -Identity Tony.Redmond).ExternalDirectoryObjectId -as [string]) -StartDate (Get-Date).AddDays(-90) -EndDate (Get-Date) -Formatted -ResultSize 5000 -SessionCommand ReturnLargeSet
$Records = $Records | Where-Object {$_.RecordType -in $RecordType} | Sort-Object Identity -Unique

The Bottom Line

You might not have been aware of the change to the old cmdlets. They still work (for now), but mailbox audit data generated since March 1, 2025, cannot be retrieved using the cmdlets. In any case, it’s a good idea to check scripts to find any instances where the old cmdlets are used. The bad news is that those scripts must be redeveloped. Good luck!

Permanent Deletion for Message and Other Types of Items from User Mailboxes

On April 1, 2025, Microsoft announced the availability of APIs to permanently delete mailbox items. This news might well have passed you by because the post appeared in the developer blog rather than anything a Microsoft 365 tenant administrator might see.

The APIs are intended to fill in some gaps in Graph API coverage for mailbox items compared to Exchange Web Services (EWS). It’s part of the campaign to remove EWS from Exchange Online by October 2026. An example of where permanent removal of mailbox items is needed is when migrating mailboxes from one tenant to another. After a successful move, the migration utility might clean up by removing items from the source mailbox.

In any case, APIs are now available to permanently delete mail message, mail folder, event, calendar, contact, and contact folder objects.

What Permanent Removal Means

In this context, permanent removal means that no client interface exists to allow the user to recover the message. For example, users can’t use Outlook’s Recover Deleted Items facility to retrieve the deleted items and administrators can’t use the Get-RecoverableItems cmdlet to do likewise (or appear in a report of recoverable items).

The reason why this is so is that when Outlook deletes items in the Deleted Items folder, the items move to the Deletions folder within Recoverable Items. When the API deletes an item, the item moves to the Purges folder. If the item is not subject to a hold, the Managed Folder Assistant will remove it the next item the mailbox is processed. If it is subject to a hold, the item remains in the Purges folder until the hold lapses.

Permanent Removal with the Microsoft Graph API

Two pieces of information are needed to permanently remove a message item using the Graph API: the object identifier for the account that owns the mailbox and the message identifier. Let’s assume that you have a variable containing details of a message:

$Message | Format-List Subject, CreatedDateTime, Id

Subject         : Thank You for Subscribing
CreatedDateTime : 06/05/2022 06:47:28
Id              : AAMkADAzNzBmMzU0LTI3NTItNDQzNy04NzhkLWNmMGU1MzEwYThkNABGAAAAAAB_7ILpFNx8TrktaK8VYWerBwDcIrNcmtpBSZUJ1fXZjZ5iAB_wAYDdAAA3tTkMTDKYRI6zB9VW59QNAAQnaACXAAA=

To delete the item, construct a URI pointing to the message and post the request to the messages endpoint. This example shows where the variables for the user identifier and message identifier are in the URI:

$Uri = ("https://graph.microsoft.com/v1.0/users/{0}/messages/{1}/permanentDelete" -f $UserId, $Message.Id)

$Uri
https://graph.microsoft.com/v1.0/users/eff4cd58-1bb8-4899-94de-795f656b4a18/messages/AAMkADAzNzBmMzU0LTI3NTItNDQzNy04NzhkLWNmMGU1MzEwYThkNABGAAAAAAB_7ILpFNx8TrktaK8VYWerBwDcIrNcmtpBSZUJ1fXZjZ5iAB_wAYDdAAA3tTkMTDKYRI6zB9VW59QNAAQnaACXAAA=/permanentDelete

Invoke-MgGraphRequest -Uri $Uri -Method Post

The Graph API doesn’t ask for confirmation before proceeding to remove the item and it doesn’t provide a status to show that the deletion was successful. The only indication that something happened is found by using the Get-MailboxFolderStatistics cmdlet to see if the items in the Purges folder increase:

Get-MailboxFolderStatistics -FolderScope RecoverableItems -Identity Tony.Redmond | Format-Table Name, ItemsInFolder

Name                                    ItemsInFolder
----                                    -------------
Recoverable Items                                   0
Deletions                                        2135
DiscoveryHolds                                   2543
Purges                                             16
SubstrateHolds                                     12
Versions                                           79

Alternatively, use the MFCMAPI utility to examine the items in the Purges folder. Figure 1 shows that the “Thank you for subscribing” message is in the Purges folder.

Permanent Removal with the Microsoft Graph PowerShell SDK

The Remove-MgUserMessagePermanent cmdlet does the same job as the Graph API request:

Remove-MgUserMessagePermanent -UserId $UserId -MessageId $Message.Id

Once again, there’s no status or confirmation required for the deletion to proceed. The other Microsoft Graph PowerShell SDK cmdlets to permanently remove objects are:

• Remove-MgUserMailFolderPermanent: Remove mail folder
• Remove-MgUserCalendarPermanent: Remove calendar.
• Remove-MgUserEventPermanent: Remove calendar event.
• Remove-MgUserContactPermanent: Remove contact.
• Remove-MgUserContactFolderPermanent: Remove contact folder.

All the cmdlets work in the same way. Deletion is immediate and permanent.

Adding new automation capabilities by extending APIs is always welcome. I just need to find a suitable use case for the new cmdlets.

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.

Ignite Announcement About SAM for Copilot Customers Misinterpreted by Many

At the Ignite 2024 conference, Microsoft announced that “Microsoft 365 Copilot will now include built-in content governance controls and insights provided by SharePoint Advanced Management.” At the time, and still broadly believed, the assumption was that Microsoft would provide customers with Microsoft 365 Copilot licenses with SharePoint Advanced Management (SAM) licenses. Maybe even a single SAM license would be sufficient to license SAM technology alongside Copilot. That’s not the case.

If you’ve been waiting for a SAM license to appear in your tenant, you’ll be disappointed and won’t see SAM listed in the set of tenant subscriptions. Don’t be swayed by the banner in the SharePoint Online admin center to announce that your SharePoint Advanced Management subscription is enabled (Figure 1). It’s not. Access to SAM features is granted through a check enabled in code for the presence of Copilot. The necessary update is now broadly available to customers.

SAM Features for Microsoft 365 Copilot Customers

The facts are laid out in the SAM documentation. Customers with eligible Copilot licenses can use some, but not all, SAM functionality without a SAM license. Here’s the list:

• Site Lifecycle Policy
  • Inactive SharePoint sites policy
  • Site Ownership Policy
• Data Access Governance (DAG) Insights
  • “Everyone Except External Users” (EEEU) insights
  • Sharing Links and Sensitivity Labels
  • PowerShell: Permission state report for SharePoint and OneDrive Sites, and Files
  • Sharing links report
• Site Access Review
• Restricted Content Discovery (RCD – enabled via PowerShell)
• Restricted Access Control (RAC) for SharePoint and OneDrive for Business.
• Recent Admin Actions and Change History
• Block Download Policy
  • SharePoint and OneDrive sites
  • Teams recordings

There’s some good stuff here, particularly Restricted Content Discovery (RCD), the Site Lifecycle Policy to manage inactive sites, and the Block download policy. Every tenant with Microsoft 365 Copilot should consider enabling RCD to block Copilot access to sites containing sensitive Office and PDF files and sites containing old and obsolete material (the digital rot or debris that clutters up so many tenants).

The problem with Copilot reusing sensitive material in its responses is obvious. The issue with Copilot reusing old, obsolete, and potentially misleading content in its responses is equally problematic, especially if human checks don’t catch errors in responses. Copilot doesn’t know when a Word document written ten years ago is outdated and inaccurate. All Copilot sees is words that can be processed and reused.

When SAM is Needed

All of which brings me to a point where a SAM license is required. In my case, I wanted to test the extend SharePoint protections with a default sensitivity label feature. The idea here is to make sure that unlabeled files receive protection when downloaded by applying a sensitivity label with equivalent rights to those enjoyed by site users. Defining a default sensitivity label for a document library already requires an Office 365 E5 license or equivalent. Why this slight extension wanders into the need to have SAM is another example of bizarre Microsoft licensing.

The documentation notes that Copilot can’t currently open files with sensitivity labels applied in this manner. This means that Copilot cannot extract the protected content to use in its responses because it doesn’t have the right to do so. However, Copilot can search the metadata of labeled files and show that metadata to those who perform searches. Restricted Content Discovery is the right way to block Copilot access to files.

Anyway, without a SAM license, I can’t test. Do I want to pay Microsoft for a license for the privilege of testing their software? I don’t think so.

Copilot in Word for iOS

In closing, I attempted to use a new feature in Word for iOS (and Android) to dictate some notes for this article for Copilot to reason over and produce a draft. The feature is covered in MC1060866 (23 April 2025) and deployment has begun, which is why I guess I could use it. The dictation part worked, even if some of my words were misunderstood (Figure 2). But any attempt to have Copilot do some magic failed utterly. I guess that AI can’t help me…

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.

Same DLP Policy for Copilot Used to Block BizChat

On May 1, Microsoft announced that the public preview of the DLP policy for Microsoft 365 Copilot is effective for the Office apps (MC1059677, 21 April 2025, Microsoft 365 roadmap item 423483). The new functionality is an extension of the DLP policy introduced in March 2025. At that time, the policy only covered Microsoft 365 Copilot Chat (BizChat). Its extension to cover the Office apps (desktop and web) is logical, even if the implementation is different. We’ll get to what those differences are shortly.

How the DLP Policy for Copilot Works

As a quick refresher, the DLP policy for Copilot works by checking if a file is assigned a specific sensitivity label. If true, the Copilot functionality built into the app is limited and the content of the file cannot be used in Copilot responses, such as creating a document summary.

Apps are responsible for checking if a DLP policy is active within the tenant and what sensitivity labels are associated with the policy, so the announcement marks the inclusion of the necessary code in the Office apps to check for the DLP policy. I tested with Microsoft 365 Enterprise Apps version 2504 (build 18730.20122).

Like any other DLP policy, the policy can have multiple rules. In this case, rules for the DLP policy for Copilot block access for a sensitivity label, so if you want to block access for multiple sensitivity labels, the DLP policy has a separate rule for each label. If you created the DLP policy for Copilot to use with BizChat, you don’t need to do anything to extend the policy to cover the Office apps.

Using the DLP Policy for Copilot in Word

As an example, I created a Word document and tested that all the Copilot functionality worked as expected. I saved the document and reopened it to force Copilot to generate the automatic summary.

I then applied one of the sensitivity labels covered by a rule in the DLP policy for Copilot and tried out some of the Copilot features. As you can see from Figure 1, the automatic summary was not removed (but the summary cannot be updated), and asking Copilot to explicitly summarize the document fails because “your organization’s policy doesn’t allow it.” However, it looks like Copilot can query the content of the document to answer questions in chat.

In their announcement, Microsoft says that “Copilot actions like summarizing or auto-generating content directly in the canvas are blocked.” They also say that chatting with Copilot is also blocked, but as you can see in Figure 1, Copilot answered a predefined question (“What is the purpose of DLP for M365 Copilot”) quite happily. On the other hand, if you go to the Message Copilot section and input the same question, Copilot refuses to answer. The block on chat worked in the web app but not always in the desktop version of Word (but this is preview software, so some bugs are expected).

Finally, Copilot cannot reference a file protected by one of the sensitivity labels covered by the DLP policy (an action that forces Copilot to extract the content of the referenced document).

Maybe Just Turn Copilot Off

I’ve used Copilot for nearly two years, and I was initially confused by the effect the DLP policy for Copilot has on the Office apps. To me, it would be simpler and more understandable to disable Copilot completely for documents within the scope of the DLP policy. I would remove the Copilot button from the menu bar and make sure that no UI elements that expose any Copilot feature, like the automatic summary appear. Right now, the UI is a confusing mishmash of things that work and stuff that doesn’t that needs to be cleaned up.

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.

Teams Can Have a General Channel Just Like Before

In July 2024, Microsoft announced that team owners would be able to rename the General channel (or local language value) of teams. The idea was that “General” is just too general in nature and that it would be better if team owners could assign a more meaningful name to the first channel created in a team. Once

Now Microsoft has reversed course a tad. Message center notification MC1048628 (updated 9 April 2025) says that team owners can choose General as the name for the first channel. The new channel creation UI even has a button to set the channel name to “General” (Figure 1). The change is already effective in targeted release tenants and will roll out worldwide in mid-May 2025.

The big thing about using General as the default channel name is that the General channel is always listed first in the channels for a team. If you use a different name for the first channel, Teams orders the channel list alphabetically. You can see the effect of renaming the General channel in Figure 2.

Channel Creation Made Easier

MC1053645 (11 April 2025, Microsoft 365 roadmap item 479744) describes another channel-related change that will roll out to targeted release tenants in early May. The option to create a new channel is now present in the New Items menu (Figure 2).

Recent conference appearances by the Teams development group have emphasized that users should create channels rather than new teams. With 1,000 channels available in a team, there’s lots of room to avoid creating new teams with the attendant overhead that comes with a team. The more teams in a tenant, the higher the likelihood for digital debris. That wasn’t such a problem years ago, but digital debris can influence the accuracy and usefulness of AI-generated content, so it’s a real issue now.

No More Code Snippets

In other Teams news related to channels, MC1055554 (15 April 2025) announces the retirement of the code snippets feature in chat and channel conversations starting May 30, 2025. Microsoft is replacing code snippets with code blocks. Type /code in the editor or click on the code block icon in the menu bar to insert a new block, and then select the type of code so that the block displays the code appropriately (Figure 4).

Microsoft believes that code blocks are faster and more efficient. Line numbers aren’t current available in code blocks but will be soon, and code blocks will also be viewable on mobile clients.

You might ask what’s driving the change. I think it’s a matter of Teams dropping an older component that doesn’t probably get much use for a shared component that’s under active development. Microsoft says that the change will allow users to “create, edit, and share code directly in the compose box without needing a title.” That’s true when someone composes a message, but if you want channel or chat members to be able to edit code in a code block, considering using the Loop paragraph component and format it as code (Figure 5).

Posting a Loop component to a channel allows team members to edit the content, so it’s possible to have real-time collaboration to discuss code issues and potential solutions. Loop components posted in this manner are stored in the channel folder in the document library of the SharePoint Online site belonging to the team.

Adieu Classic Teams

Another change that’s coming up is that the classic Teams client will be unavailable after July 1, 2025 (MC1059667, 21 April 2025). Microsoft will block attempted access to Teams with the classic client after that date. It really is time to embrace the new (well, slightly used) Teams client.

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

Monthly Update #119 Now Available for Subscribers to Download

The Office 365 for IT Pros writing team is proud to announce the availability of monthly update #119. Subscribers can download the updated files using the link in the receipt emailed to them when they bought Office 365 for IT Pros (2025 edition). The link always fetches the latest files. For more details about downloading updates, see our FAQ. Details about the changes in update #119 are in our change log.

Automating Microsoft 365 with PowerShell

Updated files are also available for the Automating Microsoft 365 with PowerShell eBook. We posted a note about update #11 a couple of days ago because we try to get this update out before focusing on the big book. Since then, we’ve added some more information, and the current version of the PowerShell book is 11.3.

The earlier post contained some information about bugs in V2.27 of the Microsoft Graph PowerShell SDK. More bugs have been reported since, and a common problem appears to be that the payload used to create or update objects “disappears” when the Graph SDK translates the cmdlet parameters into Graph API requests. There’s a batch of issues listed in the SDK GitHub repository, including a problem assigning licenses to user accounts. Collectively, the bugs make us believe that it’s not a good idea to update to V2.27. Stay with V2.25, which is the last solid release of the Microsoft Graph PowerShell SDK.

Copilot Wave 2 and the M365 Conference

A week ago, Microsoft announced Copilot Wave 2 spring release. The updates include new agents, a new agent store, better personalization, and Copilot notebooks. Having yet another notebook is a depressing thought. Maybe Microsoft could have integrated Copilot better into Loop or OneNote? Just a thought.

Next week, the Microsoft 365 “Community Conference” takes place in Las Vegas, NV. I won’t be there. My experience from last year’s event in Orlando confirmed my feeling that this isn’t a community conference at all. It’s dominated by Microsoft, who spend a lot of money for the privilege of branding, multiple keynotes, and many conference sessions. If it were a community event, there would be a higher percentage of sessions covering the experience of working with today’s products instead of marketing sessions about the future.

The other problem I have with the event is that it doesn’t cover all of Microsoft 365. This is an event deep in SharePoint Online, OneDrive for Business, and Teams, all covered with a rich coating of Copilot for Microsoft 365. There’s room for topics like Microsoft Mesh, Loop, Viva Connections, Power Pages, and Viva Engage, but other parts of Microsoft 365 are excluded because they are not part of the sponsoring business unit. A strong impression is that the conference organizers believe that everyone will write agents and everyone has Copilot for Microsoft 365, and that’s not reality. But organizers will do what sponsors want.

If you attend the conference, don’t expect to hear much about the Microsoft 365 substrate, Exchange Online, Entra ID, Intune, Sentinel, Microsoft Defender, the Microsoft Graph, and PowerShell, all of which play important roles in a Microsoft 365 deployment. Success with SharePoint Online and Teams only happens when tenants are built on a strong and secure foundation, and I think this conference completely misses that point. The organizers will plead that they can only schedule the sessions submitted for consideration. That’s not true. It’s always possible for conferences to find speakers to cover important topics (I’ve done this several times).

I’m sure that the conference attendees will have a fun time in Vegas. It’s always nice to get away from the office to focus on new things. It’s just sad when a major conference purporting to cover Microsoft 365 does such a poor job of covering the essentials.

Back to Writing

Returning to Office 365 for IT Pros, where we do our level best to cover all the important pieces in a Microsoft 365 infrastructure, we’re working on update #120 for the Office 365 for IT Pros eBook, which we plan to make available on June 1, 2025. Have a great May!

Moving Exchange Online Away from Unauthenticated Connections with Reject Send

If your tenant still has devices that send email to Exchange Online, you should pay attention to the April 28 announcement about more control over the Direct Send feature. This step is part of the overall campaign to improve the security of Exchange Online that’s included initiatives like removing support for Exchange Web Services (EWS) and only accepting inbound mail from supported versions of Exchange Server in hybrid configurations.

Direct Send is a method for devices or applications to unauthenticated send email to Exchange Online recipients using an external mail server using an accepted domain for a Microsoft 365 tenant. No mailbox is required, so Direct Send is a relatively painless way to set up an email connection to internal recipients (Exchange Online rejects messages sent to external recipients).

Authenticated Connections Preferred

Because authenticated connections are used, Microsoft would prefer customers to use client SMTP submission (SMTP AUTH) or SMTP relay instead of Direct Send. The announcement says that Reject Send is a new option to disable Direct Send by default. If they don’t need to use Direct Send, tenants should use Reject Send to block Direct Send because it’s a method that could be exploited by spammers.

SMTP AUTH is next on the list for upgrade as it will lose the ability to connect with Basic authentication in September 2025. Devices and apps that use basic auth today, for instance to send email using the PowerShell Send-MailMessage cmdlet, must be upgraded to use OAuth connections or they will lose the ability to send messages via Exchange Online. Authenticating SMTP connections via OAuth is not a matter of changing out cmdlets, so if a tenant hasn’t started that work to make sure that apps and devices continue working after the September deadline, they’re behind the curve and need to accelerate.

The Reject Send Feature

Direct Send email is anonymous (messages don’t come in via a connector). In the past, this didn’t matter so much because the messages came from devices or apps controlled by you and submitted using a domain owned by the organization. Reject Send works by updating the Exchange organization configuration to instruct the transport service to reject any unauthenticated messages submitted by Direct Send.

Reject Send is currently an opt-in feature, so the RejectDirectSend setting in the organization configuration is set to false. To enable Reject Send, connect to Exchange Online PowerShell as an administrator and run the Set-OrganizationConfig cmdlet:

Set-OrganizationConfig -RejectDirectSend $True

Exchange Online organizational settings need time to percolate to all the mailbox servers used by a tenant, so it could take up to 30 minutes before the update is effective across a tenant. Once the block is effective, messages submitted via Direct Send will then a 550 5.7.68 error. Of course, unless someone is checking devices for errors in mail transmission or notices that expected messages don’t arrive, those errors might remain undetected.

Microsoft says that they plan to enable Reject Send by default for new tenants. The logic here is impeccable. If you’ve never used the feature, don’t get the habit. Reject Send is a preview feature to allow customers to test. An issue with forwarding and Sender Rewriting Scheme (SRS) is documented in the announcement, and Microsoft does not provide a date for general availability.

Before Reject Send can reach general availability, Microsoft must deliver the promised “optics” (a report) to give administrators insight into the level of Direct Send traffic within a tenant. Assuming that the report turns up soon and unless big problems are uncovered during the preview, I’d expect Reject Send to be fully available by the end of 2025.

Connectors Required

It’s possible that some existing mail will be affected by enabling Reject Send. If so, that email must be authenticated by routing across a partner mail flow connector.

SMTP AUTH is the Immediate Priority

There’s not much else to say about Reject Send. If you have a test tenant that mimics the operational environment (complete with apps and devices), you should enable Reject Send and see what happens. You could do the same for the production tenant, but only when prepared to track problems with devices and apps. A better idea might be to wait for the promised report to understand the level of Direct Send traffic within the organization.

Given the looming deadline for SMTP AUTH to lose support for basic authentication, this is likely to remain the immediate priority for upgrade. September isn’t that far away, especially when the prime vacation period is in the middle.

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.

Use the Exchange Web Services Usage Report to Track Down the Apps Still Using EWS

On April 22, I wrote about the steps Microsoft is taking to prepare for the removal of Exchange Web Services (EWS) from Exchange Online through the introduction of a dedicated app for hybrid interoperability. Essentially, the new app will take over as the fulcrum for fetching data such as free/busy information from on-premises mailboxes, first using EWS before moving to Graph API requests later this year.

This is an example of Microsoft preparing first-party apps before retiring EWS. Third-party apps running in tenants might also still use EWS. It’s important to check if such apps exist so that contact can made with the app vendor to ascertain their plans for EWS retirement. To help with the process, the reports section of the Microsoft 365 admin center has an EWS usage report (Figure 1).

Validating Apps Listed in the EWS Usage Report

The report details the application identifier, SOAP action (API call) and volume, and the last activity date. Application identifiers make a lot of sense to Microsoft 365 (and more specifically, Entra ID), but they’re hard for humans to understand. Fortunately, it’s easy to resolve the application identifiers for many Microsoft apps by consulting the Verify first-party Microsoft apps in (Entra ID) sign-in reports page. A quick check against the apps reported for my tenant found the following apps:

• Office 365 Exchange Online (00000002-0000-0ff1-ce00-000000000000).
• Office 365 SharePoint Online (00000003-0000-0ff1-ce00-000000000000)
• Teams (1fec8e78-bce4-4aaf-ab1b-5451cc387264).
• Microsoft Office (d3590ed6-52b3-4102-aeff-aad2292ab01c)
• Microsoft Outlook (5d661950-3475-41cd-a2c3-d671a3162bc1)
• Teams Web Chat (5e3ce6c0-2b1f-4285-8d4b-75ee78787346).

None of these are surprising. EWS has long been used for calendar lookups, and Teams uses EWS in its middle tier to communicate with Exchange. The apps listed here probably use EWS to fetch information about the current calendar status for users to display that status in their profile data.

Checking for Other Apps

Two explanations exist if you find an application identifier that isn’t in Microsoft’s list of first-party applications. The app is either owned by Microsoft but didn’t make it onto the list for some reason. The more likely reason is that it’s a third-party or custom-developed app that uses EWS.

You can resolve the application identifier by searching the set of enterprise applications in the Entra admin center or with PowerShell. Figure 2 shows an extract of the set of enterprise apps with Teams in the name. You can’t search by application identifier or even sort the set of apps by application identifier, so finding the right app can be tiresome.

Instead of grappling with the Entra admin center UI, it’s usually faster to search for an enterprise application with PowerShell. In this case, I create an interactive Microsoft Graph PowerShell SDK session with the Application.Read.All scope (permission) and use the Get-MgServicePrincipal cmdlet to look for the application with a specific identifier. Once you know the name, you can find other details by examining the app’s properties through PowerShell or the Entra admin center.

Connect-MgGraph -Scopes Application.Read.All
Get-MgServicePrincipal -Filter "Appid eq '5d661950-3475-41cd-a2c3-d671a3162bc1'" | Select-Object DisplayName, AppId

DisplayName       AppId
-----------       -----
Microsoft Outlook 5d661950-3475-41cd-a2c3-d671a3162bc1

Time Ebbing Away

Microsoft plans to retire EWS from Exchange Online on 1 October 2026. That seems like a long time away, but it’s not if you have to track down the developers of EWS apps built for your organization internally or externally. Unlike other deadlines, Microsoft won’t extend the retirement date for EWS because the API is considered insecure and a prime method for attackers to exfiltrate data from a compromised tenant.

Perhaps your EWS usage report will only contain references to Microsoft first-party apps. If so, you’re all set. If not, it’s time to get moving and either retire or upgrade apps.

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.

Over 300 Pages of Microsoft 365 PowerShell Goodness to Read

The Office 365 for IT Pros writing team are pleased to announce the availability of update 11 for the Automating Microsoft 365 with PowerShell eBook. The eBook is part of the Office 365 for IT Pros (2025 edition) bundle and is also available separately (PDF and EPUB formats) or from Amazon in Kindle and paperback formats. The current version is dated 29 April 2025 and has the version number 11.3.

We typically release an updated version of Automating Microsoft 365 with PowerShell several days before the release of the monthly update of the Office 365 for IT Pros eBook. This approach makes it easier for us to manage the updates for the “big book.” We anticipate that monthly update #119 for Office 365 for IT Pros will be available on May 1.

Subscribers to the Office 365 for IT Pros bundle or to the Automating Microsoft 365 with PowerShell eBook can download the latest files by using the link in the receipt sent to them from Gumroad.com after their original purchase. See our FAQ for more details about how to download updated book files.

New Microsoft Graph PowerShell SDK Version

Microsoft released V2.27 of the Microsoft Graph PowerShell SDK on April 20. This is an important update because it had to address the many woes inflicted on customers with the buggy V2.26 and V2.26.1 releases. Azure Automation runbooks remain an issue (stay with V2.25 if you want to use PowerShell V7.1 or V7.2 runbooks) that will be addressed when Microsoft ships support for PowerShell V7.4 for Azure Automation on June 15, 2025. Two issues must be cleaned up: a clash between the SDK and Exchange Online PowerShell and support for .NET 8. In the interim, V2.27 runs fine with V5.1 runbooks.

License Assignment Bug

After several days of intensive work with V2.27 in interactive and app-only modes, I haven’t noticed any of the obvious flaws that affected its predecessors. Some early cmdlet oddities were cleared up by rebooting my PC. These were likely due to some lingering older components hanging on in memory. Following the reboot, all is well. Then I heard about problems with the Set-MgUserLicense cmdlet (issue #3286) where new licenses cannot be assigned to accounts. It seems like the cmdlet has problems parsing the information passed in the AddLicenses parameter. However, passing the license data in a body parameter works:

$LicenseData = @{
	addLicenses = @(	
	@{
	     disabledPlans = @()
	     skuId = "f30db892-07e9-47e9-837c-80727f46fd3d"
	 }
      )
      removeLicenses = @()
}

Set-MgUserLicense -Userid $User.id -BodyParameter $LicenseData

Speaking of bugs, if you encounter a problem with V2.27, please report details of the issue and steps to reproduce the problem via the GitHub repro for the SDK. Reporting an issue doesn’t take long and it is really helpful to have issues documented. Microsoft engineering monitors the open issues list and does their best to respond to problems that might affect many customers (like the license issue described above). If you don’t report problems, don’t complain when an SDK cmdlet doesn’t work the way you expect it to.

On to The Next Update

The Automating Microsoft 365 with PowerShell eBook is now well over 300 pages. That’s quite a change from the first version published in July 2024. There’s lots to cover in the next update, including a look at the newly-introduced Graph API usage report API. The API is still in beta and only covers certain parts of Graph usage such as Exchange Online and Teams messaging. The output lacks refinement and doesn’t throw any detailed light into how the Graph APIs are used within a Microsoft 365 tenant. Going forward, that situation is likely to change. It will be interesting to see the usage data generated by Microsoft and how that data is used.

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.

Fix Grammar and Spelling Problems with a Single Click

I am indebted to Paul Robichaux for pointing out a notable example of where Copilot for Word could help authors rewrite text to be clearer and more concise. The offending article is in the Microsoft Graph documentation for a topic called “enhanced personalization control overview.” It’s part of a set of controls for Microsoft 365 features such as name pronunciation and user pronouns in an area that’s been under development for several years. The text is turgid, unclear, and difficult to understand (Figure 1).

The Copilot Rewrite

I asked Copilot for Word to make the original text more consise and understandable. Copilot produced this text:

Microsoft 365 Copilot customizes itself for each user, assisting with daily tasks based on their work knowledge. Both tenant administrators and users can manage this personalization using advanced control features.

Discover how Microsoft 365 Copilot enhances personalization, ensures privacy, and provides control through improved settings.

The corrected text is still not good. Human intervention is necessary to explain how Copilot “can become personalized to each user” (original text) or how Copilot “customizes itself for each user” (revision), and so on. It is a stark warning of the danger of accepting AI-generated text without question. Not only can customer communications end up with absolute rubbish, but the danger also exists that AI-generated incorrect and misleading text ends up being stored in a file and reused ad nauseum by Copilot when it generates responses to future user prompts.

You might wonder why the Microsoft writers did not ask Copilot to refine their text. Well, I do not know if they did or not, but it could be that because the text is about a new feature that does not exist, Copilot could not find anything better to say in the Graph or in its LLMs. Remember, generative text depends on what has gone before. Copilot can rehash material it knows about, but it cannot write material about a new topic from scratch.

The Copilot Promise to Fix Grammar and Spelling Errors

Which brings me neatly to message center notification MC1060868 (23 April 2025, Microsoft 365 roadmap item 483954), which promises a new Copilot “fix grammar and spellings” feature that will address all grammar and spelling problems found in text with a single click. General availability of the feature is due in late April 2025 with deployment scheduled to complete worldwide by mid-June 2025.

Microsoft doesn’t say what languages are supported, but I assume that the feature will appear in all the languages supported by Copilot. MC1060868 contains no detail about which Copilot apps will benefit. Copilot for Word is an obvious target, and I assume that Copilot for Outlook will also receive help to tidy up email communications. As to the other apps, I guess we will see after the feature arrives.

It is a logical progression to have a single-pass process to find and remedy common errors in documents. Word has options to check for spelling and grammar errors as user type text into documents. The difference here is that Word suggests and nudges people when it detects potential errors whereas Copilot will go ahead and rewrite text to remove errors. It is then up to the user to decide whether to keep or discard the Copilot rewrite. Overall, Copilot’s one-click solution is a more proactive approach to helping people generate better text.

But is it Possible to Fix Grammar and Spelling with One Click?

That is, if everything works. The history of software designed to help people write better text is littered with dead ends. Does anyone pay much attention to the recommendations of Microsoft Editor? Why do people continue to subscribe to services like Grammarly when Microsoft offers spell and grammar checking in its products. Perhaps we are heading to a new golden age of beautiful text created by humans and enhanced by AI. Maybe, and I am sure the prospect will be welcomed by those who write the Graph documentation. But I am not holding my breath.

Make sure that you’re not surprised about changes that appear inside Microsoft 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Moving from Single-Workload Holds to Microsoft 365 Holds

Many tenants use litigation holds (also known as legal holds) to retain the complete content of Exchange Online mailboxes. The feature has been available since Exchange 2010 and can hold mailbox items (including associated archive mailboxes) indefinitely or for a specified period. The good thing about litigation holds, which is probably why people use them, is that it’s very easy to put one or more mailboxes on hold using PowerShell or the Exchange admin center (Figure 1).

The PowerShell equivalent to set litigation hold on a mailbox is:

Set-Mailbox -Identity Brian.Weakliam -LitigationHoldEnabled $True -LitigationHoldOwner "Tony.Redmond@office365itpros.com" -LitigationHoldDate "21-Apr-2025 16:00" -LitigationHoldDuration Unlimited -RetentionURL "https://office365itpros.com/AllAboutLitigationHold.Html"

While this command lists the set of mailboxes with litigation hold enabled:

Get-ExoMailbox -RecipientTypeDetails UserMailbox -Properties LitigationHoldEnabled, LitigationHoldDate, LitigationHoldDuration, LitigationHoldOwner -Filter {LitigationHoldEnabled -eq $True} -ResultSize Unlimited | Format-Table DisplayName, LitigationHoldDate, LitigationHoldOwner, LitigationHoldDuration

Inactive mailboxes can also be on litigation hold (and the hold might be the reason why Exchange Online retains these mailboxes):

Get-ExoMailbox -InactiveMailbox -Properties LitigationHoldEnabled, LitigationHoldDate, LitigationHoldDuration, LitigationHoldOwner -Filter {LitigationHoldEnabled -eq $True} -ResultSize Unlimited | Format-Table DisplayName, LitigationHoldDate, LitigationHoldOwner, LitigationHoldDuration

To release the litigation hold for a mailbox, set its LitigationHoldEnabled property to $false.

Set-Mailbox -Identity Kim.Akers -LitigationHoldEnabled $False

Or for an inactive mailbox:

Set-Mailbox -InactiveMailbox Dylan.Webb -LitigationHoldEnabled $False

This action clears the other litigation properties. Enabling or removing a litigation hold from a mailbox is usually effective within a few minutes but can take several hours.

The Bad Thing about Litigation Holds

Litigation Holds are easy to apply and manage and are available for all Exchange Online mailboxes. But their big downside is that litigation holds only cover mailbox items. That was an acceptable state when the need to preserve personal information for an employee only extended to email. Today, Microsoft 365 apps store so much information in a user’s OneDrive account that it is imperative to preserve this data when someone leaves.

Within Microsoft 365 today there are many other ways to communicate, including Teams, OneDrive for Business, Microsoft 365 Groups, and Viva Engage. Along with mailboxes, those locations are all covered by Microsoft 365 retention policies, which are the modern alternative to litigation hold.

However, I’m not going to cover retention policies here. Instead, I’m going to throw out a different idea, which is to use an in-place hold imposed by a standard eDiscovery case (available with Office 365 E3 and above or Microsoft E5 compliance licenses). Perhaps the recent GUI overhaul for Purview eDiscovery prompted me to investigate this solution.

Holds are only one part of eDiscovery cases, which also include searches, review sets, and exports covering multiple data sources. In the scenario where an organization wants to keep personal information for employees for a period (perhaps after employees leave), an eDiscovery case might replace litigation holds and deliver the additional benefit of holding OneDrive for Business accounts.

Creating an eDiscovery Case with PowerShell

The eDiscovery case we need is simple. It consists of:

• The case (created with New-ComplianceCase). A container for the case elements, like holds and searches,
• A case hold policy (created with New-CaseHoldPolicy) defines the set of locations (mailboxes and OneDrive for Business accounts) that the hold will apply to.
• A case hold rule associated with the case hold policy (created with New-CaseHoldRule). The rule specifies the KQL query used by the hold. In this case, to create a hold that applies to everything in the mailboxes and OneDrive for Business accounts, the KQL query is empty.

Before running any of these cmdlets, you must connect to Exchange Online and the compliance endpoint, and the account used must have the eDiscovery manager role.

An example script is worth hundreds of words. You can download my example from GitHub.

Delegated Permissions and OneDrive for Business

The script is intended for use with delegated permissions. It would be possible to use app-only mode, but I wanted to illustrate an important an important aspect of dealing with OneDrive for Business accounts.

The Sites.Read.All permission allows the signed-in user to read details of all SharePoint Online sites – but not OneDrive for Business accounts, even if the account is a SharePoint administrator. This is a little strange because the SharePoint administrative interfaces allow access to OneDrive.

The full URL for a OneDrive account is needed to add it to an eDiscovery case hold policy (or a retention policy). This is a value like:

https://office365itpros-my.sharepoint.com/personal/brian_weakliam_office365itpros_com

Even with the Sites.Read.All delegatedpermission, you can’t use the Get-MgUserDrive or Get-MgUserDefaultDrive cmdlets to get the OneDrive URL (you can with the application permission). I therefore use a little trick of retrieving the OneDrive usage report data for the last 90 days and extracting the user principal name and site identifier from the data. The script can use the site identifier with the Get-MgSite cmdlet to find the OneDrive URL. It’s a little complicated, but the code works. It would be nice if the usage report data included the site URL. However, a longstanding problem that Microsoft seems incapable of solving means that the site URL is missing from SharePoint Online and OneDrive usage reports.

Easier Solutions Exist

It would be easier to use the Microsoft Graph PowerShell SDK in app-only mode and have full access to the OneDrive account information, but this is an example of how it’s often possible to get at Microsoft 365 data when it seems to be blocked. It would also be easier to move mailboxes (and their OneDrive accounts) from litigation hold to a retention policy instead of an eDiscovery case, but where’s the fun in always taking the easy route?

If you’re still using litigation holds, the question is why? In 2010, litigation holds were the best we could do in terms of preserving mailbox content. In 2025, we can do better, and there’s many ways to satisfy the need to preserve data, including OneDrive.

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.

OWA Access to Online Archives Ceases on 12 May 2025

The April 17 announcement about the retirement of OWA support for cloud archives in Exchange Server dismayed some people. I received several messages to ask why Microsoft will withdraw support for OWA access to cloud archives from May 12, 2025. Some asked if this was yet another example of Microsoft releasing bad news on the cusp of a holiday weekend. Others asked why Microsoft only gave customers 25 days’ notice. And a few asked if this was the first step to retire Exchange Server (despite the imminent arrival of Exchange Server SE).

A Matter of Money

I wasn’t surprised at the news because it fits in with the current environment around Exchange Server. First, we migration to the cloud is all but finished for organizations that want to use Exchange Online. Even in hybrid organizations most mailboxes are in the cloud with a relatively small percentage still on-premises.

Organizations that wish to stay on-premises and use Exchange Server SE do so for their own reasons. Security over email is one of the primary motivations for staying on-premises, so these organizations probably generate relatively little demand for online archives (archive mailboxes hosted by Exchange Online). Coupled with a reducing set of on-premises mailboxes in hybrid environments, the overall demand for online archives cannot be high.

If Microsoft isn’t generating revenue by selling Microsoft 365 licenses to on-premises organizations to access online archives, they’ll want to reduce engineering and support costs. One way to do that is to reduce the number of clients that can access online archives when the primary mailbox is on-premises, and that’s what’s happening here.

Outlook Classic Continues

Microsoft points out that access to online archives will continue via Outlook classic. They don’t specify what version of Outlook classic is necessary, but we can assume that anyone who accesses an online archive today with Outlook classic can continue to do so after May 12, 2025.

It’s unsurprising that Microsoft chose to retire OWA access. There’s no indication that the new Outlook for Windows (aka OWA on steroids) will support Exchange Server in the future. The New Outlook is very tied to Exchange Online and moving that client to Exchange Server seems like work that Microsoft wouldn’t want to do. Simplifying the version of OWA available to Exchange Server makes that client easier to support and cheaper to maintain.

But if the new Outlook isn’t going to support Exchange Server when Outlook classic support terminates sometime in 2029, that creates the question of what clients will be available to Exchange Server customers after that time. I don’t think a simplified version of OWA will be enough for on-premises users. Unlike the new Outlook, OWA doesn’t support offline access, PSTs, and so on. Microsoft will have to do something to address the client issue for on-premises customers. It would be no surprise if Outlook classic (a version of the perpetual client, not subscription) continued after 2029. It’s a while away before we’re likely to hear about client plans for Exchange Server SE in 2029, but Outlook classic seems like a good bet (“Outlook 2030” perhaps?).

Change Happens

Change is a constant factor in the cloud and trade-offs happen between the introduction of new functionality (some is coming for Exchange Server SE) and the retirement of older underused features. Microsoft says that tenants affected by the change have received message center notification MC1053644 to let them know what’s going on. If you haven’t received the notification and think that your tenant is affected, you should contact exchonpremfeedback[AT]microsoft.com.

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

Change to Dedicated Exchange Hybrid App Paves Way to Graph APIs

I don’t know why Microsoft publishes important information at the start of a holiday weekend when the distraction level is high, but that’s just what they did when making a critical announcement for organizations running hybrid Exchange. As it turns out, the announcement is linked to the April 2025 Exchange Server hotfix update (HU), but I think releasing both pieces of news would have been fine once everyone was back at work after the Easter break.

The announcement outlines how Exchange hybrid configurations are dropping Exchange Web Services (EWS) in a two-phase process beginning with the release of the April 2025 HU. It’s part of the strategy to retire EWS from Exchange Online in October 2026.

Preserving Rich Coexistence

In a hybrid organization, Exchange Online uses EWS for “rich coexistence.” In other words, Exchange Online issues EWS commands to fetch free/busy data, mail tips, and user profile pictures for on-premises mailboxes. The EWS requests to fetch data are made by a first-party Microsoft enterprise app called Office 365 Exchange Online, which is present in every tenant that uses Exchange Online. Requests from Teams to fetch similar data for on-premises mailboxes also flow through the Office 365 Exchange Online app.

Microsoft’s announcement says that the Office 365 Exchange Online app is created by the Hybrid Configuration Wizard (HCW). HCW certainly updates the app’s service principal, but the app itself isn’t tied to HCW. For example, one use of the app is to hold Exchange Online permissions that can be assigned to other service principals, such as when an Azure Automation account needs to run Exchange Online PowerShell cmdlets.

Microsoft wants to remove EWS. However, instead of using another first party enterprise app that’s controlled and managed by Microsoft, tenants are required to create an Entra ID registered app. Like any other Entra ID app, the app (with a display name of ExchangeServerApp-{organization identifier) can hold the Graph permissions needed to access mailbox and other data. Or rather, the app’s service principal can hold the permissions. Microsoft calls this app the “dedicated Exchange hybrid app.”

When first presented with the idea that tenants had to create individual apps, my response was that it should surely be easier for all to have a dedicated first party app where Microsoft manages the app and its permissions. In their text, Microsoft justifies their decision as follows:

Consider the upcoming shift from EWS to Graph API calls: adjustments to the application will be necessary (for example, updating API permissions). A dedicated customer application allows customers to choose when they want to transition from EWS API permissions to Graph API permissions.

The reason why a tenant-specific registered app is used is therefore to allow individual customers to choose when they move from EWS to Graph API. This is valid and I can see how the flexibility to move at the time of a customer’s choosing is useful. It seems like Microsoft is saing that a centrally-managed enterprise app can’t be used because of the requirement to switch permissions from EWS to Graph. However, there’s nothing to stop an enterprise app holding both EWS and Graph permissions for a period after which the EWS permission is removed. That ship has sailed and the registered app is the way forward.

Step One: Switch Apps

The first step in the process requires tenants to apply the April 2025 HU. After updating servers, tenants can run the ConfigureExchangeHybridApplication.ps1 script to switch their configuration from the current setup to the dedicated Exchange hybrid app. The script is run once per organization. After switching, EWS is still used, but it’s routed through the dedicated Exchange hybrid app rather than the Office 365 Exchange Online app.

Microsoft says that they plan to release an updated version of the HCW in the second quarter of 2025 (soon). If a tenant runs the updated HCW, it will switch the apps.

Step Two: Switch to Graph

The second step depends on availability of Graph API support for coexistence with Exchange Server. When the software is available, tenants must apply server updates to enable servers to respond to Graph API requests. Being able to handle Graph requests for mailbox data is not the same as the wider and deeper Graph access available within Microsoft 365.

After upgrading servers, tenants can run the script again to switch the dedicated Exchange hybrid app from EWS permissions (which essentially allow unfettered access to mailboxes) to a set of more granular Graph permissions that limit the app to more precise and restricted access. The elimination of the broad access to mailboxes enjoyed by EWS is one of the primary driving factors behind the desire to retire EWS from Exchange Online. This phase must be completed by 1 October 2026 (Figure 1). If not, rich co-existence will stop working.

Take Your Time

Before doing anything, I suggest you read the announcement, hot fix information, and installation notes for the script. Reviewing the PowerShell code in the script will also help you to understand what it does in different modes.

After applying the April 2025 hotfixes, the next decision is when to switch to the dedicated app. I don’t see any reason why not to switch immediately. The bigger decision is when to switch the app to using Graph permissions rather than EWS. This is likely something that you’ll want to do during a scheduled server maintenance period towards the end of 2025, after making sure that everything works well in a test organization of course.

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.

Leaked Credentials and Sign-in Metrics Make for an Interesting Day

Last Saturday morning was interesting. After barely being able to ingest my first coffee, I noticed that Teams was complaining that it couldn’t sign in. A quick check against the Entra ID sign-in log revealed that the problem was that Teams had blocked the user (me) because of risk detected by the home tenant (Figure 1). In other words, something had happened to make Entra ID consider my account to be at risk.

When unexpected things happen, my go-to source is the audit log. The root of the problem occured at 05:01 UTC when a component called MACE Credential Revocation changed the StsRefreshTokensValidFrom property for my account to set a new date and time from which refresh tokens can be used (thus forcing reauthentication). The action was captured in a Update StsRefreshTokenValidFrom Timestamp event.

MACE Credential Revocation is not something I have encountered before. The MACE part of the name means Microsoft Account Compromise Exchange and it’s part of Entra ID used to distribute leaked credential notifications. It is an Entra ID enterprise app with an application identifier of 7d636ec3-f39c-44f5-8b73-fa28a0e0c5bc. Interestingly, the service principal for the app was created in my tenant at at 19 April 2025 05:00;42 by a process called Microsoft Azure AD Internal – Jit Provisioning. It looks like Microsoft flipped a switch to enable some new Entra ID processing that immediately caused accounts to be flagged with leaked credentials. As I later discovered, it seems like many tenants had the same problem.

Despite my tenant being affected, nothing relating to a problem with Entra ID appeared in the service health dashboard, but I have heard from others who received the following statement from Microsoft support:

On Friday 4/18/25, Microsoft identified that it was internally logging a subset of short-lived user refresh tokens for a small percentage of users, whereas our standard logging process is to only log metadata about such tokens. The internal logging issue was immediately corrected, and the team performed a procedure to invalidate these tokens to protect customers.  As part of the invalidation process, we inadvertently generated alerts in Entra ID Protection indicating the user’s credentials may have been compromised. These alerts were sent between 4/20/25 4AM UTC and 4/20/25 9AM UTC. We have no indication of unauthorized access to these tokens – and if we determine there were any unauthorized access, we will invoke our standard security incident response and communication processes.  

The odd thing is that Microsoft refers to alerts being sent on Sunday (April 20) rather than Saturday (April 19), which is when the problem occurred. The mystery deepens.

Leaked Credentials

Managing risky users with Entra ID Protection is an Entra ID P2 feature. Being able to detect problems by monitoring for different signs of potential compromise is one of the reasons why tenants might consider the Microsoft E5 Security add-on. In my case, risky users is covered by the Microsoft 365 E5 license. Checking the Risky Users section of the Entra admin center, I duly found that my account was in the bad accounts list because of “leaked credentials” (Figure 2).

Leaked credentials aren’t a huge problem for accounts protected by strong multi-factor authentication and are considered a “nonpremium” issue in the list of risk detections. I wanted to find out more and use the link to Microsoft Defender to see if it could throw more light onto the subject (Figure 3).

Remediation is a Password Change

Despite feeling that the warning was a false positive, you shouldn’t take chances with passwords. The easiest way to remediate the risk and unblock the account is to reset the password, so I used the self-service password reset feature to set a new account password (secure reset of a password is always accepted as a remediation). Reporting the detection of risky users and their remediation can be done through PowerShell.

Just one account was affected in my tenant. Others tenants reported that access for multiple accounts was blocked. The evidence to date indicates that Microsoft noticed a problem, took action to fix the problem, and made the problem worse by causing alerts to fire about perfectly good user accounts. In one way, it’s good that this happened over a holiday period when administrators have time and space to fix accounts, but you have to ask how a remediation process can suddenly make Entra ID believe that user accounts suffer from leaked credentials. It’s all very odd.

Success Metrics for Sign-ins

All of which brings me to some interesting metrics that are available through the Graph beta endpoint. All require the Reports.Read.All permission. For instance, the MFA sign in success metrics report “the number of times users successfully completed interactive MFA sign-ins using the Microsoft Entra MFA cloud service during a specified time period.” The metrics can be reported for up to 30 days using intervals of 5, 10, 15, or 30-minute intervals. Each item reported therefore represents the number of activities that occurred in an interval.

For example, here’s the code to extract the MFA sign-in success metrics at 30-minute intervals for the last 29 days.

$StartDate = $StartDate = ((Get-Date).AddDays(-29).ToString("yyyy-MM-ddTHH:mm:ssZ"))
$EndDate = ((Get-Date).ToString("yyyy-MM-ddTHH:mm:ssZ"))
$Uri = ("https://graph.microsoft.com/beta/reports/serviceActivity/getMetricsForMfaSignInSuccess(inclusiveIntervalStartDateTime={0},exclusiveIntervalEndDateTime={1},aggregationIntervalInMinutes=30)" -f $StartDate, $EndDate)
$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get | Select-Object -ExpandProperty Value
$Data

Name                           Value
----                           -----
value                          0
intervalStartDateTime          17/04/2025 11:30:00
value                          0
intervalStartDateTime          17/04/2025 12:00:00
value                          0
intervalStartDateTime          17/04/2025 12:30:00
value                          0
intervalStartDateTime          17/04/2025 13:00:00
value                          0
…

1,390 objects were duly written into the output array. That’s too many to check manually, so I created a quick loop to report the intervals when successful MFA operations occurred:

ForEach ($Item in $Data) {
  If ($Item.Value -as [int] -ne 0) {
     Write-Host ("{0} successful MFA sign-ins during interval starting {1}" -f $Item.Value, $Item.intervalStartDateTime) -ForegroundColor Cyan
  }
}

Remember that these represent operations where a user goes through the full MFA process. If someone authenticates because their credentials haven’t expired, that operation doesn’t count.

Possibly of more interest is the API to get conditional access blocked sign in metrics, or “the number of user sign-in attempts that were blocked by a Conditional Access policy during a specific period.” The command is similar:

$Uri = ("https://graph.microsoft.com/beta/reports/serviceActivity/getMetricsForConditionalAccessBlockedSignIn(inclusiveIntervalStartDateTime={0},exclusiveIntervalEndDateTime={1},aggregationIntervalInMinutes=30)" -f $StartDate, $EndDate)
$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get | Select-Object -ExpandProperty Value

Once again, we need a little help to extract the intervals when something interesting might have happened to guide us where to check in the Entra sign-in log:

  If ($Item.Value -as [int] -ne 0) {
     Write-Host ("{0} Blocked Conditional access sign-ins at {1}" -f $Item.Value, $Item.intervalStartDateTime) -ForegroundColor Red
  }
}

Interestingly, no metrics for blocked conditional access sign-ins are detected in my tenant. I guess the folks who secured a copy of my leaked credentials haven’t tried to use them yet only to find that MFA will block their efforts.

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.

Sponsors Are The People Who Invite Guests to Join a Tenant

Nearly two years ago, Entra ID added the ability to assign sponsors to guest accounts. A sponsor is someone in the tenant who can attest to the need to give an external person a guest account (or so the theory goes). Since then, Entra ID changed its processing so that the person who invites someone to join a tenant as a guest automatically becomes their sponsor less another person is explicitly selected during the invitation process. In most cases, no one will bother changing the sponsor (or know that they can), and the person who issues the invite is the sponsor.

Assessing whether old guest accounts should remain in a tenant is a good practice to perform periodically. It’s easy to create a report about guest accounts that includes details like the date created, last sign in date, days since the last sign in, any groups a guest belongs to, and so on. If you then decide to remove some guest accounts, you might like to flag the decision to the sponsors for those accounts.

Finding Guest Accounts

The Microsoft Graph PowerShell SDK has changed a lot since I originally wrote about sponsors, so here’s some new code to report guests and their sponsors (you can download the script from GitHub).

The first task is to find guest accounts and retrieve their sponsors. This is easily done by running the Get-MgUser cmdlet with a suitable filter and making sure to retrieve and expand the Sponsors property:

Write-Host "Finding guest accounts to analyze..." -ForegroundColor Green
[array]$Guests = Get-MgUser -Filter "userType eq 'Guest'" -All -Property Id, DisplayName, Sponsors, CreatedDateTime, SignInActivity, Mail -ExpandProperty Sponsors | Sort-Object DisplayName
If (!($Guests)) { 
    Write-Host "No guest accounts found." -ForegroundColor Red
}

Reporting Guest Accounts and Their Sponsors

After that, it’s a matter of looping through the guest accounts to extract and report the relevant information. Here’s the code:

Write-Host ("Checking {0} guest accounts..." -f $Guests.Count) -ForegroundColor Green
$Report = [System.Collections.Generic.List[Object]]::new()

ForEach ($Guest in $Guests) {
    $SponsorNames = $null
    If ($Null -eq $Guest.Sponsors.Id) {
        $SponsorNames = "No sponsor assigned"
    } Else {
        $SponsorNames = $Guest.Sponsors.additionalProperties.displayName -join ", "
    }

    $SignInDate = $null
    If ([string]::IsNullOrEmpty($Guest.SignInActivity.LastSuccessfulSignInDateTime)) {
        $SignInDate = "No sign-in activity"
        [int]$DaysSinceSignIn = (New-TimeSpan $Guest.CreatedDateTime).Days
    } Else {
        $SignInDate = Get-Date($Guest.SignInActivity.LastSuccessfulSignInDateTime) -format 'dd-MMM-yyyy HH:mm'  
        [int]$DaysSinceSignIn = (New-TimeSpan $SignInDate).Days
    }

    $ReportLine = [PSCustomObject] @{
        Name                 = $Guest.DisplayName
        Email                = $Guest.Mail
        'Sponsor Names'      = $SponsorNames
        Created              = Get-Date($Guest.CreatedDateTime) -format 'dd-MMM-yyyy HH:mm'
        'Last Sign In'       = $SignInDate
        'Days Since Sign In' = $DaysSinceSignIn.ToString()
    }
    $Report.Add($ReportLine)
}

$Report | Out-GridView -Title "Entra ID Guest Account Sponsors"

The number of days since sign in is calculated from the last successful sign-in date recorded by Entra ID for the account. If this information isn’t available (because the sign-in occurred before Entra introduced the last successful sign-in date property in late 2023), the creation date for the account is used. Figure 1 is an example of the output report.

Some guest accounts don’t have sponsors because they were added to the tenant before Entra ID updated its processes to make the person who invites a guest their sponsor.

Figuring Out Old Guests

Because we compute the number of days since the last sign-in, it’s easy to list the set of guests that haven’t signed in since a set threshold. After that, it’s up to you how to contact the sponsors to ask them what to do with their old guests.

# List all the guest accounts (and their sponsors) that haven't signed in for more than the threshold number of days
$OldGuests = $Report | Where-Object {$_.'Days Since Sign In' -as [int] -gt $Threshold}
Write-Host ""
Write-Host ("The following guest accounts have not signed in for more than {0}} days:" -f $Threshold) -ForegroundColor Red
Write-Host ""
$OldGuests | Format-Table Name, 'Sponsor Names', 'Days Since Sign In', 'Last Sign In' -AutoSize

Tenants don’t have to use the sponsor information if they don’t want to. However, given that Entra ID now populates the sponsor data for new guest accounts, it seems like a pity not to use it.

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.

Part of Revamp of Purview eDiscovery to Embrace a Unified Framework

Microsoft is in the middle of a campaign to modernize the Purview eDiscovery solution. Previously, I wrote about the announcement and the possible impact on tenants and eDiscovery investigators. The big idea here is that Purview eDiscovery is moving to a unified framework covering all types of eDiscovery activities with the functionality available to users being determined by the license they hold. In a nutshell, E3 means standard eDiscovery, and E5 means access to premium eDiscovery.

The nature of these things is that the devil is in the detail, which only comes out as Microsoft introduces changes to implement the grand plan. An example is in message center notification MC1055528 (14 April 2025), which explains a set of component retirements to implement some big changes from May 26, 2025.

Content Searches Presented in an eDiscovery Case

First, the Content Search option in the Classic eDiscovery (i.e., the eDiscovery UI that Microsoft revamped (badly) in 2021) will disappear. Its replacement is a new Content Search option that displays the set of content searches within the new eDiscovery UI. Be aware that the new UI (which is also used with old cases) is very different to what’s available in classic eDiscovery. The query and locations (search targets) are moved over, but the process of running searches and examining samples of results found by searches is very different.

Essentially, there’s one big eDiscovery case (called Content Search) that holds all the content searches. As you can see from Figure 1, I have content searches going back to January 2015. Someday soon I must clean out the old searches.

Note the two little icons above the list of searches. TR is for me, and EM indicates that my account holds the eDiscovery Manager role.

Removal of Classic eDiscovery Option

Today, the eDiscovery section of the Purview compliance portal includes a Classic eDiscovery option. This option is going away and is replaced by the Cases option. Essentially, all the old eDiscovery cases become standard eDiscovery cases in the new framework. The Content Search case that holds all the old content searches is one of the new cases.

Removal of Export Capability from PowerShell Cmdlets

The compliance PowerShell module contains a set of cmdlets to manage eDiscovery content searches and cases. Microsoft says that they will disable (remove) the export-related parameters from the cmdlets that manage content search actions:

• New-ComplianceSearchAction -Export parameter
• Get-ComplianceSearchAction -Export parameter
• Set-ComplianceSearchAction -ChangeExportKey parameter

All other eDiscovery cmdlets are unaffected, so you might ask why Microsoft is focusing on the export feature. I assume that two factors are in play:

1. Microsoft wants to remove content searches eventually. Removing the ability to export the results of content searches with PowerShell forces standard users to export search results via the Purview portal.
2. Different export mechanisms are used. Content searches move the results of full searches (not estimate searches) to a protected location in Azure and exports the data from there using the content download tool. Users must have the correct export key to download data. In the new eDiscovery, the export process creates export packages that are downloaded from the Purview compliance portal.

Removing the ability to export search results via PowerShell might impact some scripts. Going forward, the only way to programmatically control eDiscovery exports is with the eDiscovery Graph API (the reviewSet export API). The downside here is that the Graph API only supports premium eDiscovery cases, so if your license only allows standard eDiscovery, you can’t use the API.

A Potentially Disruptive Change

The takeaway is that processes that use content searches for various kinds of investigations must be revised before Microsoft pulls the plug on the older eDiscovery mechanism on May 26, 2025. The steps to find material through eDiscovery are different, the UI is different, and some of the terms used in the GUI and documentation are different. All in all, this is a big change that will also affect tenant administrators who use content searches for different reasons, like finding SharePoint Online files without retention labels. Prepare for some disruption!

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.

Peeling Away the Layers to Find the Cheapest Auto-Label Option

Last week, I discussed how to use auto-label policies to apply sensitivity labels to old files in SharePoint Online sites to prevent their discovery and use by Microsoft 365 Copilot. The approach works but it’s only viable if a Microsoft 365 tenant has the necessary licenses to support auto-label policies.

Understanding Microsoft licensing is an art form and getting things right is important when a licensing decision might affect everyone in a tenant. In this instance, the requirements for information protection service-side automatic sensitivity labeling from the Purview service descriptions and license guidelines page seem pretty straightforward (Figure 1).

The same information is available in the Microsoft 365 Compliance Licensing Comparison Excel worksheet (also available as a PDF).

Licensing Trainable Classifiers

Purview extends over many different solutions. In my original article, I suggest using a trainable classifier to locate old files, so we need to check that licenses under consideration also cover trainable classifiers. The same page says:

“To auto-apply retention labels using a trainable classifier, the following licenses provide user rights:

• Microsoft 365 E5/A5/G5
• Microsoft 365 E5/A5/G5/F5 Compliance and F5 Security & Compliance
• Microsoft 365 E5/A5/F5/G5 Information Protection and Governance”

Licensing Costs

It seems clear then that the licensing requirement is met by having one of these SKUs (listed in order of cost):

• Microsoft 365 E5 (or Office 365 E5).
• The Microsoft E5 Compliance add-on ($12/user/month)
• The Microsoft E5 Information Protection and Governance add-on ($7/user/month).

Microsoft 365 E5 Information Protection and Governance add-on is a subset of the Microsoft 365 E5 Compliance product. According to this page, the Information Protection and Governance add-in is available for the following base licenses (Figure 2):

Interestingly, although Microsoft 365 Business Premium supports the E5 Security add-on, Microsoft still doesn’t support the E5 Compliance add-on for these customers – but Microsoft 365 Business Premium tenants can buy the Information Protection and Governance add-on. It’s an anomaly.

The takeaway is that if a tenant can restrict its licensing requirements to as tight a set as possible, it might be possible to reduce the overall cost for extra licenses quite considerably.

Who Needs the Licenses?

Microsoft’s general licensing guideline for Purview solutions is that anyone who benefits from a feature must be licensed for that feature. In practical terms, this means that anyone with access to a SharePoint Online site that’s processed by an auto-label policy requires a license. The same rule applies to other forms of auto-labeling, such as defining a default sensitivity label for a document library.

The DIY Option to Sensitivity Labeling

Let’s imagine that you don’t want to pay Microsoft any more licensing fees but still want to apply a sensitivity label to a bunch of old files. It’s possible to do this with a DIY app, but it will still cost because the Graph assignSensitivityLabel API is a metered API and costs $0.00185 each time the API applies a label to a file, or $185 per 100,000 files.

Sensitivity labels can’t process every type of file that’s found in SharePoint Online. The API can only deal with Office documents and PDF files. Older Office documents (.DOC, .XLS, and .PPT files) are unsupported, so some testing is needed to establish exactly what in the target content can be processed.

If you only plan to apply sensitivity labels to a set of known files and don’t need to use advanced capabilities like trainable classifiers to find items like invoices, customer orders, project plans, and so on, then the DIY option could be the right choice. The code to report the files in a SharePoint document library isn’t hard, and once you have a list of files, you can review and trim the set and then use it as input to an app to apply sensitivity labels.

Depending on how many files are to be processed, the DIY

approach can save a lot of money over licensing costs. Apart from having to pay to create, test, deploy, and support the code, the downside is that DIY labeling is a one-off mechanism without the benefits of ongoing automatic labeling or any of the other advanced processing built into Purview. You pay your money and make your choice!

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.

Block for Service Principal-Less Authentication in March 2026

One of the latest announcements from Microsoft engineering groups to improve the overall security of their cloud infrastructure is Entra’s decision to halt service principal-less authentication from March 2026. It’s an example of eradicating old practices that are unacceptable in today’s threat environment.

Service principal-less authentication happens when an enterprise app (aka a multitenant app) is used without a service principal in the host tenant. Enterprise apps are created by Microsoft and other software vendors. The Microsoft Graph Command Line Tools app (used to connect to the Microsoft Graph with PowerShell) is an example of a multitenant app. In this case, the Microsoft Graph Command Line Tools app has a service principal in the host tenant, which the app uses to hold the set of delegated Graph permissions available in interactive PowerShell sessions.

The Lack of a Service Principal

When an enterprise app doesn’t have a service principal, it probably means that the app only needs a basic level of authentication to allow the app to run. Post authentication, the app takes care of whatever processing it needs to do without using tenant-assigned permissions. Microsoft wants to block this kind of authentication saying that “Service principal-less authentication can be abused if the resource applications (i.e. APIs) perform incomplete validations.” Microsoft says that they have verified that validations aren’t vulnerable to service principal-less authentication, but they want to block the route now to avoid the possibility of a gap appearing in the future.

Reading between the lines, Microsoft doesn’t want apps to simply appear in a tenant, have a fairly loose connection to Entra ID, and be able to process data without administrative oversight.

After the block is active from March 2026, Entra ID will not allow enterprise apps to authenticate if they don’t have a matching service principal. It’s therefore wise to check tenants to identify any apps in this category to allow the problem to be mitigated.

Finding Problem Enterprise Apps

In their documentation, Microsoft explains how to use sign-in logs to identify problem enterprise apps. The advice focuses on looking for information through the Service principal sign-ins tab. I didn’t find anything there, but I found some interesting results by scanning sign-in logs for interactive connections. This code looks for sign-ins that have a service principal of ‘00000000-0000-0000-0000-000000000000’ and reports what it finds (this article describes a more comprehensive script to report service principal sign-ins):

$Uri = "https://graph.microsoft.com/beta/auditLogs/signIns?`$filter=servicePrincipalId eq '00000000-0000-0000-0000-000000000000'"
[array]$Data = Invoke-MgGraphRequest -Uri $Uri -Method Get
$Data = $Data.Value
$Data | Group-Object ResourceDisplayName -NoElement | Sort-Object Count | Format-Table Name, Count
 
Name                               Count
----                               -----
Exchange Admin Center                  1
Microsoft 365 App Catalog Services     1
Microsoft Activity Feed Service        1
Microsoft Office 365 Portal            1
OfficeHome                             1
Password Breach Authenticator          1
Microsoft Edge Auth                    3
Account Linking                        5
IrisSelectionFrontDoor                 5
Office365 Shell WCSS-Server            5
                                       6
Augmentation Loop                      6
Microsoft News Feed                   10
Office 365 Exchange Microservices     10
Edge Sync                             14

A bunch of Microsoft apps are in the collection, many of which appear in the Entra documentation explaining how to identify first-party apps. In addition, there’s an odd entry for a nameless app that comes from the Microsoft Services tenant (home tenant identifier f8cdef31-a31e-4b4a-93e4-5f571e91255a with an application identifier of 29d9ed98-a469-4536-ade2-f981bc1d605e). The default domain name for the app is sharepoint.com, so it’s reasonable to conclude that it’s something to do with SharePoint Online.

Figure 1 shows the details of a sign-in for the Office365 Shell WCSS-Server app, generated when I accessed the SharePoint Online admin center.

The Office365 Shell WCSS-Server app is browser code that runs whenever a user navigates to most Microsoft 365 browser apps. The shell, also known as the suite header, is shared code that loads as part of almost all workloads, including SharePoint, OneDrive, Outlook, and Viva Engage. The code is probably performing some internal processing that doesn’t need the tenant to grant permissions, so it doesn’t have a service principal.

Mitigating the Lack of a Service Principal

All of this is very interesting, but Microsoft’s mitigation for service principal-less authentication is for tenants to create a service principal for each of the affected apps. Given that so many Microsoft apps seem to be affected, does this mean that tenant administrators will have to create service principals for these apps?

The answer is no. The Entra ID team confirmed to me that they’ll take care of Microsoft apps and will update the documentation to this effect. The mitigation requirement only arises for third-party enterprise apps. The call to action remains to check if any of these apps exist in your tenant, and if you find some examples, it’s time to contact the app owners to ask them how they plan to function when service principal-less authentication no longer works.

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem, including Entra ID. 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.

.NET Dependencies Stop Microsoft Graph PowerShell SDK Authentication in Runbooks

As anyone who keeps tabs on the Microsoft Graph PowerShell SDK, the V2.26 release was a disaster. Poor testing and other failures let obvious problems escape into customer environments. To be fair to Microsoft, the development group fixed some of the more grievous problems and issued version 2.26.1 a week or so after V2.26 appeared.

Alas, V2.26.1 came with its own set of flaws, notably breaking Azure Automation runbooks that use PowerShell V7.1 and V7.2 because the SDK developers decided to remove support for .NET 6. Cue the infamous “invalid JWT access token” issue (Figure 1).

All in all, the Microsoft Graph PowerShell SDK descended into grand farce, and no one knew what would happen next. The problem only happens for runbooks based on PowerShell V7.1 and V7.2. It doesn’t arise when runbooks use PowerShell V5.1.

Microsoft’s Solution – Azure Automation Support for PowerShell V7.4

On April 10, 2025, Microsoft laid out their plans to clean up the mess. Explaining that the root cause of the problem in V2.26.1 is a component conflict between the Exchange Online PowerShell module and the Microsoft Graph PowerShell SDK that prevents the Connect-MgGraph cmdlet working, Microsoft says that the issue is resolved when Azure Automation is upgraded to support PowerShell V7.4 (based on .NET 8). A preview of PowerShell V7.4 support is available today.

Microsoft doesn’t say when Azure Automation will fully support PowerShell V7.4 support in a generally available version.

Update 18 April: According to notes from a community call, Microsoft expects to release PowerShell 7.4 support for Azure Automation on June 15, 2025.

However, they do say that the next release of the Microsoft Graph PowerShell SDK is “expected later this month.”

Update: Microsoft released V2.27 of the Microsoft Graph PowerShell SDK on April 19, 2025. The new version fixes some of the problems seen in V2.26.1. However, it still has problems with V7.1 and V7.2 Azure Automation runbooks.

Until Microsoft releases PowerShell V7.4 support for Azure Automation, if you have Azure Automation runbooks, stay with Microsoft Graph PowerShell SDK V2.25 or use V2.27 with PowerShell 5.1 runbooks.

Work Remains to be Done

Assuming that Microsoft delivers a new version of the Microsoft Graph PowerShell SDK that delivers “enhanced stability” (couldn’t be worse than the last two versions), “compatibility and performance” and address the many issues reported in the SDK GitHub repository (163 open at present), is that the end of this saga?

I don’t think so. The history of the Microsoft Graph PowerShell SDK is littered with poor quality and buggy releases. The clash with the Exchange Online PowerShell module speaks of a failure within Microsoft to coordinate updates to critical PowerShell modules used by Microsoft 365 customers. Given the closely-connected nature of Microsoft 365, it’s unacceptable for engineering groups to make changes to PowerShell modules without understanding if their updates will impact modules like Teams, SharePoint, and Exchange.

Quality instead of Fast-Paced Releases

Customers need a sustained run of high-quality Microsoft Graph PowerShell SDK releases to rebuild faith. In the past, Microsoft issued new SDK versions on a monthly cadence in an attempt to keep up with changes in Graph APIs. That cadence is too rapid. Stability should be the name of the game from here on with focus on delivering a high-quality quarterly SDK. Lessening the pace will permit the SDK engineers to coordinate better with their peers and burn down the swelling bug list. If people need to use a new Graph API, there’s no need to wait for Microsoft to build an SDK cmdlet because they can always use the API via the Invoke-MgGraphRequest cmdlet.

Over three million downloads now occur for new SDK versions. It’s time that Microsoft treats the Microsoft Graph PowerShell SDK as what it is: a serious piece of the PowerShell framework for Microsoft 365 automation.

Microsoft E5 Security for Microsoft 365 Business Premium Now Available

On April 6, 2025, Microsoft announced that the Microsoft E5 Security add-on is available to Microsoft 365 Business Premium tenants. Microsoft 365 Business Premium is one of the packages for small to medium businesses (up to 300 licensed seats). The E5 Security suite is a bundle of high-end features to improve the security of a tenant. Until now, Microsoft has targeted the add-on at enterprise customers with Office 365 E3 or Microsoft 365 E3 that want the extra security features without upgrading to Office 365 E5 or Microsoft 365 E5. This is the first time that Microsoft has made the add-on available for a small to medium product.

Finding Savings in Software Bundles

The unique selling point for the add-on is that it’s cheaper to buy it than license each of the features separately (Figure 1). Everyone loves a bargain, and saving 57% seems like a true deal.

The truth is that the E5 Security add-on is a bargain if your tenant can use its functionality. Careful assessment of each of the licensed features is necessary to understand where the tenant can gain value. For instance, if the organization currently doesn’t have the capacity to deploy Defender for Endpoint, that wipes $5.20 off the add-on’s value. If nothing can be gained from Entra P2, an extra $9 disappears, and suddenly the saving to license the other three features goes from $16.20 to $2. That’s still a saving of up to $600 monthly/$7,200 annually for a 300-person Business Premium tenant, which is not quite as impressive as the headline. And to get that saving, you must invest $43,200 annually to license the 300 seats.

On the other hand, if Entra P2 stops a tenant being compromised through an account that can be identified as risky or an attacker can be stopped because Defender for Cloud Apps detects a problematic app, then the cost of the E5 Security add-on is more than justified. It all depends on how a tenant can extract value.

The same point is valid for the Microsoft E5 Compliance add-on (also available for $12/month in the U.S.). A bunch of interesting compliance technology is covered by the add-on, but if you don’t want to use features like Insider Risk Management, Communication Compliance, customer lockbox, customer key (for sensitivity labels), and Information Barriers, the value proposition becomes much less attractive.

Playing the Licensing Game

License management is an essential competence for tenant administrators. I don’t mean negotiation of licensing deals with Microsoft. Instead, I’m referring to understanding what licenses are needed for the functionality required by the business, knowing the cheapest way to license that functionality, and keeping track of how licenses are used. Tools like the Microsoft 365 licensing report script can help here. If you don’t want to build your own tools and want an off-the-shelf product to manage licensing, I recommend CoreView license management (the sponsor of the Office 365 for IT Pros eBook).

The higher the individual license cost, the more important it is to track active and ongoing usage. Microsoft 365 Copilot is a good example. It doesn’t make sense to assign $360/year licenses to people who don’t use Copilot, so tracking Copilot usage to ensure that people with licenses use those licenses is important.

Have a Deployment Plan Before Buying Anything

If you need and can use their features, Microsoft 365 add-ins can be great value. I don’t recommend buying these add-ons unless a tenant has a plan to deploy and use the licensed technology to achieve well-defined results. Having something that you cannot use isn’t a great idea and buying expensive software just because it seems like a bargain has never been a great tactic. Small to medium enterprises might not have the expertise to assess the true worth of the functionality bundled in E5 Security add-in. If you’re in that situation, engage an expert to help build your plan.

For more information about using Microsoft E5 security with Microsoft 365 Business Premium, see the Microsoft documentation. The Microsoft E5 Compliance add-on is not available for Business Premium (but that might change).

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 Audit Records to Find Who Creates SharePoint Agents

Another day, another event on the TEC 2025 European Roadshow. This time we were in Paris and just like in London’s discussion about how to protect old confidential files from Copilot access, attendees posed many good questions. Following the discussion about how to manage agents, I was asked how an organization could discover if SharePoint agents are in use. It’s a good question that isn’t answered in Microsoft’s documentation about how to manage agents in SharePoint. Microsoft gives some details about planned administrative features for agents are in an April 8, 2025 blog post, but there’s nothing available today.

I hadn’t thought about the problem up to now. SharePoint agents are limited in scope and don’t seem to pose too many administrative challenges. Each agent exists as a file in a document library with an .agent extension (originally, agents had a .copilot extension). Except for sites marked for Restricted Content Discovery, SharePoint Online sites have a default agent that reasons over the entire site. Site members can create other agents that focus on specific parts of the site. Agents created by site members are available to all site members and can be amended by them.

Approved Agents

To mark agents as being particularly useful, site owners can approve agents to highlight the agents in the agent picker. The files for approved agents are moved to the Site Assets library where they’re stored in the Approved sub-folder of the Copilots folder. Only site owners can edit approved agents. Figure 1 shows the details of an approved agent.

Auditing Agent Creation

The creation and updating of custom SharePoint agents is evidence that people are using agents. Because the agent files are treated like other SharePoint files, audit records are captured in the Microsoft 365 audit log when these actions occur. By interrogating the audit log, we can discover who is creating agents and the sites where agents are used.

Here’s some PowerShell to use the Search-UnifiedAuditLog cmdlet to find SharePoint FileUploaded audit records for files with an .agent extension:

[array]$Records = Search-UnifiedAuditLog -StartDate (Get-Date).AddDays(-30) -EndDate (Get-Date) -Formatted -ObjectIds "*.agent" -Operations FileUploaded -ResultSize 5000 -SessionCommand ReturnLargeset
If ($Records) {
    $Records = $records | Sort-Object Identity -Unique
    Write-Host ("{0} audit records found" -f $Records.Count)
} Else {
    Write-Host "No audit records found"
    Break
}

$AgentReport = [System.Collections.Generic.List[Object]]::new()
ForEach ($Rec in $Records) {
    $AuditData = $Rec.AuditData | ConvertFrom-Json
 
    $ReportLine = [PSCustomObject][Ordered]@{
        TimeStamp       = Get-Date ($AuditData.CreationTime) -format 'dd-MMM-yyyy HH:mm'
        User            = $AuditData.UserId
        Action          = $AuditData.Operation
        SiteURL         = $AuditData.SiteURL
        Agent           = $AuditData.SourceFileName

    }
    $AgentReport.Add($ReportLine)
}
$AgentReport = $AgentReport | Sort-Object {$_.TimeStamp -as [datetime]} -Descending
$AgentReport | Out-GridView -Title "Custom SharePoint Agent Creation"

Write-Host ""
Write-Host "Custom agents created in these SharePoint Online sites"
$AgentReport | Group-Object SiteURL -NoElement | Sort-Object Count -Descending | Format-Table Name, Count
Write-Host ""
Write-Host "Custom agents created by these users"
$AgentReport | Group-Object User -NoElement | Sort-Object Count -Descending | Format-Table Name, Count

Figure 2 shows some sample output seen through the Out-GridView cmdlet.

Some basic statistics are also produced about the sites where custom agents were created and the user accounts which create agents. To track agent usage, you can use the same technique to fetch and analyze FileAccessed audit events.

Microsoft Reports to Come?

Once again, the Microsoft 365 audit log is the source to answer questions. I’m sure that Microsoft will eventually get around to generating better-looking reports about agent creation and activity in the future. The usual course of events is that these kinds of gaps are filled sometime after functionality becomes available. Given that SharePoint agents reached general availability in November 2024, we’re still only finding out what reporting is needed for operational purposes, so it might take a while yet before we see any Microsoft reports.

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.

Combining Auto-Label Policies, Trainable Classifiers, Sensitivity Labels, and DLP to Stop Copilot Accessing Old But Still Confidential Files

I’ve been on the TEC 2025 European Roadshow this week. Monday was London, Tuesday Paris, and Dusseldorf is the final stop on Thursday. These trips sound like they should be great fun, but running events in three major cities over four days takes a brutal amount of effort.

In any case, my topic this week is protecting Microsoft 365 data in the era of AI. During the talk, I recommend that people use features like Restricted Content Discovery, sensitivity labels, and the (preview) DLP policy for Copilot to exert control over confidential and sensitive documents and restrict access to Copilot for Microsoft 365 and Copilot agents.

Find and Protect Old Confidential Material

All of which led to a great question at the London event: “how do I apply sensitivity labels to thousands of old but still confidential material files stored in multiple SharePoint Online sites.” It’s a good example of the kind of practical issue faced by tenant administrators during deployments.

The obvious answer is to use an auto-label policy to apply sensitivity labels that are then blocked by the DLP policy for Copilot. An auto-label policy can find Office documents at rest that don’t have sensitivity labels and apply a chosen label (manually-applied sensitivity labels are never overwritten but a policy can overwrite a lower-priority sensitivity label.

Trainable Classifiers

The issue is to identify the target set of confidential files. This is where a trainable classifier can help. Purview Data Lifecycle Management includes 75-odd built-in trainable classifiers that Microsoft has taught to find different types of documents like business plans and credit reports.

It might be possible to identify old confidential material using a built-in trainable classifier. If not, tenants can create custom trainable classifiers by using machine learning to process a training set of documents unique to the business. The process isn’t difficult, and the hardest part is often to find a suitable set of sample documents to train the classifier with. Running a simulation will quickly tell if machine learning can extract an accurate digital structure from sample documents to use as a classifier.

I have a couple of trainable classifiers in use to auto-label files. To test the process, I selected the default Source Code classifier (Figure 1). Behind the scenes, Purview looks for some matching documents to demonstrate how each of the built-in classifiers work. In this case, Purview had found several items in a projects site where I store files like drafts for blog posts. Some of the matching items had sensitivity labels, others did not. It was a good set to test the theory against.

Creating an Auto-Label Policy

The next step is to create an auto-label policy. Because we want to apply sensitivity labels, the policy is created in the Purview Information Protection solution. The policy settings are very straightforward. Look for files matching the source code trainable classifier in all SharePoint Online sites and apply the Confidential sensitivity label. Figure 2 shows the rule created to find files that match the trainable qualifier.

You can choose to run an auto-label policy in simulation mode before making it active. Even though the trainable classifier shows some sample files that it found, it’s still a good idea to run the simulation, just to be sure. When you’re happy with the results, you can activate the policy to have Purview assign the chosen sensitivity label to the files found by the policy. Once the files are labelled, they’ll be invisible to Copilot for Microsoft 365.

Background Processing Runs Until the Job’s Done

Depending on how many old files need to be protected, the entire process to create a trainable classifier, tweak the classifier until it’s accurate, and run auto-labeling might take several weeks to complete. Most of the work happens in the background at a pace dictated by demands on the service. The auto-label policy will continue to run unless you stop it, once all those old but still valuable files are labelled.

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.

Filter, Refine, and Report File Sharing Events from the Audit Log

A recent article about auditing file sharing activities in Teams generated some questions. The accompanying script searches for FileUploaded events, which have nothing to do with sharing. SharePoint Online captures FileUploaded events when users create new files in SharePoint sites.

In any case, after reading the article, it makes a case to keep an eye on files uploaded to Teams channels because it’s possible that someone might share information that results in a data leak. It’s a tenuous proposal that only makes sense in a weird sort of way. I am not saying that no one has never uploaded a file to a Teams channel that they shouldn’t have. Some mistakes will happen given that people create billions of files in SharePoint Online daily. But the sheer volume of FileUploaded events created in the unified audit log means that a simple report detailing these events is never going to be valuable. Filtering and analysis are required to extract value.

Most file activity logged by SharePoint Online is innocuous. To find value in the audit log, administrators need to know the data they want to find. As an example, it seems like it would be good to know who shares files from SharePoint Online, both through Teams and the SharePoint browser interface, and who they share the files with (internal and external).

Microsoft documents how to use audit data to track sharing activities. There’s lots of good information in that article to help you understand how SharePoint Online generates the content of the audit events generated to track sharing activities.

Finding File Sharing Events in the Audit Log

When I begin to figure out what audit data might be valuable for investigative purposes, I usually use several accounts to perform the activities I’m interested in (in this case, sharing documents), wait about 30 minutes, and then go through the events that turn up in the audit log. Searching the audit log with a command like this returns SharePoint sharing events. Make sure that the start and end dates are limited to the period when the actions of interest occur:

[array]$Records = Search-UnifiedAuditLog -StartDate '2-Apr-2025 19:00' -EndDate (Get-Date) -Formatted -SessionCommand ReturnLargeSet -ResultSize 5000 -RecordType SharepointSharingOperation

Analyzing the audit data revealed that SharingSet events happen to set up a sharing link. UserExpirationChanged events are also found if the sharing link policy sets expiration dates for sharing links. If you cast the audit net wider and look for other events, you’ll also find Send events logged when SharePoint Online sends notification messages to inform people that someone has shared a file with them.

Filtering File Sharing Events

The audit log is a rich source of information that can be overwhelming because of the amount of logged data. When searching for answers, it’s important to focus. In this instance, I extracted only the SharingSet events and then filtered the returned set to remove sharing events that I wasn’t interested in. These events included:

• Sharing for SharePoint embedded applications such as Loop and Outlook Newsletters.
• Sharing performed by the background app@sharepoint app. For instance, when SharePoint Online shares the recording of a Teams meeting (stored in the OneDrive of the meeting organizer) with meeting participants.
• Sharing set operations to adjust SharePoint lists. When a user shares a document, SharePoint Online adjusts the group that controls access to that item within the site, which results in audit events being logged for groups like “Limited access system group for list.” A Microsoft article covers permission levels and explains what these groups mean.

Essentially, the only sharing events I am interested in are those involving member and guest Entra ID accounts (i.e., humans).

The lesson here is that retrieving a set of events from the audit log seldom delivers useful results. It’s usually the first stage in a process to remove unwanted events to focus on the valuable information.

Parsing and Reporting Sharing Audit Events

The next step is to parse the information contained in the remaining audit events to answer the questions who shared what with whom and what level of access did they grant? Most of this information is hidden in plain sight in the AuditData property of audit events. The data must be extracted, cleaned up, and enhanced.

For example, if your organization uses sensitivity labels to protect files (and you should), the audit events note the GUID of the label applied to the shared file and the GUID of the label applied to the host site (container management label). Resolving the GUIDs to label names makes this information more accessible. Knowing that a shared file has a sensitivity that will block unauthorized access is always a nice feeling.

The result is a report of file sharing events (Figure 1) that answers the question of who shared files from SharePoint Online with whom and what access was granted.

In addition, because the script extracts the email addresses of sharees, you can analyze the volume of sharing to external domains:

$AuditReport | Group-Object TargetDomain -NoElement | Sort-Object Count -Descending | Format-Table Name, Count

Name                        Count
----                        -----
microsoft.com                  11
o365maestro.onmicrosoft.com     4
contoso.com                     2
proton.me                       1

Report File Sharing Events to Meet Your Requirements

Like anything published on the internet, the script (available from GitHub) might or might not satisfy your requirements. But it’s PowerShell, so you can change the code to meet your needs. I used the Graph AuditLog Query API to retrieve audit data. The same data is available by running the Search-UnifiedAuditLog cmdlet.

The takeaway is that real value is seldom extracted from audit logs without some additional processing to refine, filter, and interpret the information. Articles that merely extract and report audit data don’t add much value because they don’t tell the full story and reveal the actionable data that administrators need.

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.

Recent Change Opens Door to Malicious Links Viewed in Email Preview

I receive many messages from readers about different aspects of Microsoft 365. To be honest, I usually don’t have much time to devote to these queries unless it’s an interesting topic. Hearing about a Microsoft 365 component that allows administrators to click links that are known to lead to bad destinations certainly fell into that category, especially when the communication comes from an experienced Security Operations (SecOps) practitioner.

Update 14 April, 2025: The Microsoft Defender for Office 365 engineering group reached out to me to acknowledge that clickable links in email preview was a regression that has now been fixed.

Threat Explorer and Message Views

The Threat Explorer is part of Microsoft Defender for Office 365. It’s a tool to help the SecOps team understand the level of threat flowing into a tenant through email. The Explorer has multiple views to allow administrators select different sets of messages such as malicious messages blocked for different reasons. An All Email view is also available to show both bad and good messages delivered to a tenant. Even though it shows “all email,” this view could do with some filtering because it includes messages like public folder hierarchy synchronization traffic.

Figure 1 shows the Threat Explorer listing messages blocked for phishing. The details of the selected message are shown in the right-hand panel. The message purports to come from Charles Schwab. Two of the URLs in the message are for the real Charles Schwab site. The other is planted to bring unsuspecting users to the attacker’s site.

Using Email Entity and Email Preview for Investigations

The Threat Explorer also includes several tools to help SecOps investigate threat. To see more detail about the bad message, an investigator can open the email entity to view more details about the message and any attachments. One of the options that then becomes available in the Take Action menu is to view an email preview. Seeing how a malicious message presents itself to a recipient is invaluable information because it reveals how the attacker sets their trap for the unwary.

In this instance, the malicious message looks as if it could have come from the purported sender (Figure 2). The real links to pages on the Charles Schwab site are mixed in with the links to the attacker’s site (accessed from the Review Now button and Log In link).

Here’s where the strange aspect arises. The links to the attacker’s site are live and can be clicked on to bring the investigator to that site. On the one hand, this seems reasonable because an investigator is doing their job to follow the trail as far as possible. Skilled investigator will protect their workstation against malicious attack and will take great care when accessing bad links.

The problem is not with security investigators. It arises when people who are possibly less skilled in terms of security tools and forensics or less aware of how malware can infect a workstation clicks a live and potentially dangerous link. Clicking a link opens a connection between the workstation and the target site. Because the email preview page uses a https://security.microsoft.com/emailpreview URL, VPN backhauling is often ignored, and the traffic goes direct to the attacker site.

Recent Change Enabled Bad Links in Email Preview

The odd thing is that Microsoft appears to have enabled the ability to use these links only recently. In the past, Defender used two versions of the email preview page: one was static without links; the other showed link details if you hovered over a link but the link was not clickable. Microsoft’s documentation makes no mention of the danger of clicking active links to attacker sites and there’s no trace that I can find of an announcement explaining why Defender now enables malicious links. Given Microsoft’s current focus on tightening security in every product, it just doesn’t make sense to make it easier for people to connect to sites that Defender has (usually correctly) identified as problematic and a potential source of infection.

My correspondent told me that he reported the issue to Microsoft. The support response was that the links are protected by the Safe Links feature and no problems arise if you use a private browsing session or replace Edge with Firefox. It’s a curiously passive position that basically says that it’s OK to keep dangerous stuff around if you take steps to protect yourself’ Safe Links allowed me to click the bad link today. Enough said.

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.

Conditional Access Optimization Agent Keeps a Wary Eye on Connections

All around Microsoft, program managers and executives are seeking opportunities to deploy artificial intelligence in products, preferably if that usage justifies the requirement for an additional license. Some of the resulting ideas are good, like the Facilitator agent for Teams group chats. Others need more time to appreciate the use case, if one exists. The point is that you can expect more AI-powered features (whether Copilot in apps or a variety of agents) to appear in Microsoft 365 applications as time passes.

Entra ID Brings AI to the Table

All of which brings me to New innovations in Microsoft Entra to strengthen AI security and identity protection, published on March 24, 2025, where Alex Simons sets out the case for using AI to increase security and explains how Microsoft is applying AI in Entra ID.

Before I go further, let me know how disappointed I am that many technical conferences focusing on Microsoft 365 ignore or give lip service to Entra ID. The foundation of any successful and secure Microsoft 365 tenant is a well-managed Entra ID instance. It’s regrettable that Entra ID doesn’t receive the attention that it should on the schedules for even some major conferences. For instance, the current session lineup for the “Microsoft 365 Community conference” mentions Entra once and Copilot 46 times. That tells a story, mostly in terms of where Microsoft marketing money is going.

Smarter Policy Management Through the Conditional Access Optimization Agent

In any case, my attention was drawn to the Conditional Access Optimization Agent (now in private preview), which offers “smarter policy management.” Apparently, the agent monitors how an Entra ID tenant processes inbound connections to understand where the connections originate, the resources they access, and the authentication paths used. It picks up details like new user accounts and applications. The agent then puts the information together to figure out if the conditional access policies used by the tenant can be optimized.

I like this idea. It’s a good example of applying artificial intelligence to a bounded set of data with a clear intention (that the tenant can alter with custom instructions). Unlike human administrators, some of whom are well capable of assessing the state of health of conditional access within a tenant, agents work all the time with a relentless focus on their instructions and the data they’ve been given.

The claims advanced in the article seem a little misleading (the agent hardly “protected” 700K sign-ins for the example tenant just by watching and processing connection data, and creating a new group containing 16 users to add to an existing conditional access policy isn’t rocket science either), but it’s possible to see the value that such an agent can bring by relieving administrators of the mundane task of reviewing conditional policy settings and sign-in logs on an ongoing basis to look for potential gaps and anomalies worth investigating.

Security Copilot Brings the AI Smarts

The Conditional Access Optimization Agent is one of six Security Copilot agents unveiled on March 24. Getting Security Copilot (the “proactive problem solver”) on board is where the cost arises. It’s hard to know just how much putting manners on your policies will cost because Security Copilot charges on the basis of Security Compute Units (SCU). Provisioned SCUs cost $4/hour in the U.S., but there’s no information available about how many SCUs the Conditional Access Optimization Agent will consume over a month or however long it takes for the agent to come up with its suggestions.

Organizations that use Security Copilot already probably have a good grasp on costs and can estimate (better than I can) the costs to add extra tasks. One way to look at it is that an experienced consultant who knows conditional access inside out might charge a day or two to review a tenant’s policies. For the purpose of easy maths, let’s say that the bill is $2,000, or 500 SCUs. Looking at the situation like that seems to make using Security Copilot a no-brainer. However, it’s a very black and white example and IT is full of grey. It will be interesting to learn about the real-life experience of operational tenants in terms of both agent output and cost.

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.

No Out-of-the-box Answer for Transfer Meeting Ownership

A problem that’s often faced when tidying up the affairs of ex-employees is what to do about the meetings they organize. Sometimes, no issue arises because the ex-employee doesn’t organize meetings or they have just a few meetings that can be easily canceled. In other instances, the departing individual is the organizer of a many meetings, including recurring meetings, and the meetings have artifacts like Loop-based meeting notes, attendance reports, and so on.

The core issue is that no way exists to transfer the ownership of meetings from one user to another. If this facility existed, it would be easy for someone like an ex-employee’s manager to take over responsibility for future and past meetings. To avoid the problem happening with important company events, some organizations use designated shared mailboxes to schedule and manage these events. It doesn’t matter when someone leaves the organization because the meeting organizer always remains.

The One Calendar

Outlook and Teams share the same calendar. Teams allows meetings to have co-organizers. This feature helps keep scheduled meetings running and preserves past events, but no transfer of ownership occurs. The Outlook equivalent is a delegate with full control over a calendar, but delegation is not ownership.

On the surface, it seems like the software engineering involved in transferring meeting ownership is just a matter of moving calendar events from the old organizer’s calendar to the new organizer’s calendar. However, that simple move hides a lot of complexity when issues like delegation and recurring events are considered. Transferring meeting ownership without affecting access to meeting resources is likely a good chunk of work, which is probably why it hasn’t happened.

A New Take on the Classic Answer to the Transfer Meeting Ownership Question

The classic answer is to cancel all future meetings owned by the ex-employee and have another person reschedule the meetings. You can automate meeting cancellation by running the Remove-CalendarEvents cmdlet, which can cancel events for up to 1,825 days in advance. Meeting participants receive cancellation notifications as normal. It’s an effective way of cleaning up events owned by an ex-employee, provided their mailbox is still online.

And while the mailbox remains online, it’s a good idea to create a report detailing meetings that might need to be rescheduled. The data is easily fetched with the Graph list calendar view API, which fetches the set of calendar events for a mailbox for a specified period.

The Office 365 for IT Pros GitHub repository contains many scripts covering different parts of Microsoft 36. It’s my scripting toolbox when I need some code to solve a problem. In this case, I used code from the room mailboxes statistics report. The original version uses Graph requests. To simplify matters, I modified the code to use Microsoft Graph PowerShell SDK cmdlets. The basic flow is:

• Run the Connect-MgGraph cmdlet to connect an interactive session to the Graph with the Calendars.ReadBasic and User.ReadBasic.All scopes. The script available from GitHub uses delegated permissions with the signed-in account. If you want a script that can read any mailbox, use an app to hold the permissions and authenticate with a certificate so that you can run in app-only mode (see an example here).
• Run the Get-MgUserCalendarView cmdlet to fetch data for the last 180 days (an arbitrary value that can be set to whatever number of days you want).
• Find the set of meetings organized by the user from the data returned in the calendar view.
• Report details of the meeting and generate an Excel worksheet or CSV file as output (depending on if the ImportExcel module is available).

Figure 1 shows selected details for some reported events through the Out-GridView cmdlet.

You can download the complete script from GitHub. The script as written doesn’t report details like meeting body (notes) or attachments. It’s possible to fetch and reuse this data (the script will need the Calendars.Read rather than the Calendars.ReadBasic.All scope to access the meeting body and attachments).

Reschedule to Transfer Meeting Ownership

The remaining work is to review the set of meetings found in the ex-employee’s calendar and decide which meetings need to be rescheduled and who should be the new owner. The rescheduling process is probably going to be manual, but it would be possible to read in event details from the output XLSX or CSV file using the New-MgUserCalendarEvent cmdlet. It’s not worth doing the work if only a few meetings are involved but it might be if a large volume of meetings need to be rescheduled. I’ll leave that work to the reader.

One final point: cleaning up future meetings and possibly rescheduling meetings are points that should be part of a departing employee checklist. It’s best to be proactive.

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.

Restricted Content Discovery Hides SharePoint Content from Copilot and Agents

The problem of poor permission management has surfaced from time to time in the history of SharePoint. The Office Delve app caused the last big upheaval within Microsoft 365 when it demonstrated an uncanny ability to surface sensitive documents to user view. Of course, Delve was never the problem. The issue is due to careless permission assignment, usually at site level.

When Microsoft launched Copilot in March 2023, it soon became apparent that Copilot is even better than Delve at finding and reusing documents, including files that an organization would prefer to remain restricted. Microsoft’s short-term answer was Restricted SharePoint Search, a horrible but expedient solution that works on the basis of an allow list for enterprise search which restricts users to only being able to search approved sites. Copilot always works as the signed in user, so the limits applied to users apply to Copilot to stop the AI using material stored in unapproved sites in its responses.

Restricted Content Discovery (RCD) is the latest solution to control unfettered access to confidential information stored in SharePoint Online sites. RCD is part of the SharePoint Advanced Management (SAM) suite. Microsoft is making SAM available to tenants with Microsoft 365 Copilot licenses via a code update that’s slowly deploying.

How Restricted Content Discovery Works

Restricted Content Delivery works by adding a flag to files stored in designated SharePoint Online sites. When an administrator marks a site for RCD through the SharePoint admin center or PowerShell. Figure 1 shows the “restrict content from Microsoft 365 Copilot” option in the admin center. When a site is selected for RCD, SharePoint sets a site-level property that causes index updates for every file in the site. Although RCD is applied at a site basis, SharePoint indexing happens at the file level, so a fan-out process must find and reindex every file in a site before RCD becomes effective for that site.

The time required to update the index for a site is highly dependent on the number of items in the site. Microsoft says that “for sites with more than 500,000 items, the Restricted Content Discovery update could take more than a week to fully process and reflect in search and Copilot.”

The indexing update does not remove items from the tenant index. If it did, items would be unavailable for eDiscovery searches, auto-label policies for retention and sensitivity labels, and other solutions. Instead, the flag set on files instructs Copilot to ignore those files when it consults the Graph to find matching content to help ground user prompts. The same approach is used by the Data Loss Prevention (DLP) policy to block Copilot access to files assigned specific sensitivity labels.

The block applies to anywhere Copilot for Microsoft 365 can use SharePoint Online files, including Copilot agents. It doesn’t affect how site-level search works, nor does it interfere with other Purview solutions like eDiscovery, content searches, or DLP. However, content from sites enabled for RCD don’t appear in enterprise level searches.

RCD Management with PowerShell

PowerShell can be used to manage RCD for sites. Make sure that you use a recent version of the SharePoint Online management module (I used Microsoft.Online.SharePoint.PowerShell version 16.0.25715.12000). For example, to enable RCD for a site, run the Set-SPOSite cmdlet to set the RestrictContentOrgWideSearch property to $true.

Set-SPOSite -Identity https://office365itpros.sharepoint.com/sites/rabilling -RestrictContentOrgWideSearch $true

To remove RCD from a site, set the value for RestrictContentOrgWideSearch to $false:

Set-SPOSite -Identity https://office365itpros.sharepoint.com/sites/rabilling -RestrictContentOrgWideSearch $false

Much the same reindexing process must occur before files in sites where RCD is disabled after being enabled before files become available to Copilot.

To generate a list of sites with RCD enabled, run the Start-SPORestrictedContentDiscoverabilityReport command to create a job on a queue for processing. The Get-SPORestrictedContentDiscoverabilityReport cmdlet reports the status for the job, which eventually reports “Completed.”

Start-SPORestrictedContentDiscoverabilityReport

Generating the report will take some time. Are you sure you want to proceed?
Continue with this operation?
[Y] Yes  [N] No  [?] Help (default is "Y"): y

RunspaceId           : 1d839c7e-c0bf-4c11-be94-20179f2335e2
Id                   : 02aa91ea-5e12-43de-91a1-a58275d3b201
CreatedDateTimeInUtc : 03/31/2025 16:09:52
Status               : NotStarted

Get-SPORestrictedContentDiscoverabilityReport

RunspaceId           : 1d839c7e-c0bf-4c11-be94-20179f2335e2
Id                   : 02aa91ea-5e12-43de-91a1-a58275d3b201
CreatedDateTimeInUtc : 03/31/2025 17:03:52
Status               : Completed

To download the RCD insights report, run the Get-SPORestrictedContentDiscoverabilityReport cmdlet and pass the GUID (id) for the report. This value is shown in the Get-SPORestrictedContentDiscoverabilityReport output:

Get-SPORestrictedContentDiscoverabilityReport –Action Download –ReportId 02aa91ea-5e12-43de-91a1-a58275d3b201
Report RestrictedContentDiscoverabilityReport_1743437651407.csv downloaded successfully

Microsoft documentation says that “the downloaded report is located on the path where the command was run.” This is incorrect. The file ends up in whatever folder the PowerShell session starts up in. In my case, I ran the job when positioned in c:\temp and the file ended up in c:\windows\system32. The easy fix here is to use a PowerShell profile to define the folder where PowerShell starts up.

The contents of the “insights” report aren’t too exciting (Figure 2) and could be easily generated by looping through sites with PowerShell to find those with the flag set.

Restricted Content Discovery for All

It’s a reasonable guess that any Microsoft 365 tenant that’s interested in Copilot has some sensitive information stored in SharePoint Online sites. If you’re in this situation, you should consider RCD as the front-line method to prevent that information leaking out through Copilot. I’d also deploy the DLP policy to restrict Copilot access as a backup. Between the two lines of defence, it’s unlikely that inadvertent disclosure of confidential data will happen, and that’s a good thing.

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.

Monthly Update #118 for the Office 365 for IT Pros eBook

The Office 365 for IT Pros writing team is delighted to announce the availability of the April 2025 update (monthly update #118) for the Office 365 for IT Pros eBook. Readers can check the update number of the book on the inside front cover. Details of the update are available in our change log.

The Automating Microsoft 365 with PowerShell eBook is updated for April 2025 too. Its current version is 10.1. The new PDF and EPUB files are available to Office 365 for IT Pros subscribers and those who bought a separate subscription for the PowerShell book.

Subscribers can download the updated files from their Gumroad account or by using the download link in the receipt they received by email following their original purchase. The link in the receipt always accesses the latest files. See our FAQ for more information about how to download updates.

Sending Messages to the Wrong Place

There’s been quite a furore about messages being delivered to the wrong person recently. Leaving the politics aside, the situation is a reminder that the same thing could happen in a Microsoft 365 tenant if a user created an Outlook contact group and included someone who shouldn’t receive sensitive or confidential information in the group members. It’s easy to do because Outlook (Figure 1) doesn’t limit membership to a particular type of recipient. The membership of a personal contact group can include existing contacts, people from the address list (GAL), or new contacts.

Administrators have no idea if people use Outlook contact groups because these objects are stored in user mailboxes. When users add contact groups to messages, Outlook expands the memberships to create individual recipients. Exchange Online only sees the individual recipients.

If a message containing sensitive information are delivered to incorrect recipients, senders can attempt to recall the message. However, the recall feature doesn’t work for external recipients. Once a message leaves the tenant, all control is lost.

Protecting Content

Fortunately, Microsoft 365 tenants licensed for Purview information protection can apply sensitivity labels to email and attachments to prevent unauthorized recipients from reading message content. Chapter 19 of Office 365 for IT Pros includes extensive coverage of the rights-management-based encryption used with sensitivity labels. Essentially, if a recipient has not been granted the right to access protected content, they can’t see it. Protection extends to message attachments too.

It’s always embarrassing when confidential material gets into the wrong hands either deliberately or through a user mistake. Sensitivity labels are integrated into all Outlook and Office applications, but their implementation requires substantial planning and deployment effort, including user education. For instance, will label policies require users to apply a sensitivity label to all email or will the focus of protection be on files (messages with protected attachments inherit protection from the attachments)? There’s lots more to think about, and we hope that chapter 19 helps.

On to Update #119

Only two monthly updates remain for Office 365 for IT Pros (2025 edition). We plan to publish #119 for May 2025 and #120 for June 2025 and then move to the 2026 edition with a tentative publication date of July 1, 2025.

Microsoft is currently pouring massive datacenter and software engineering investment into its AI initiatives. Copilot and agents are the obvious signs of that investment within Microsoft 365. Although costly licenses are required to integrate Microsoft 365 data with Copilot, we’re already seeing the introduction of Pay-as-you-go agents as an alternative payment mechanism. It’s easy to imagine how Microsoft might use similar methods to encourage tenants to adopt AI features within applications more broadly. One thing’s for sure: plenty of change remains to play out within Microsoft 365. Our mission to track, analyze, and document how to manage Microsoft 365 tenants will continue.

Use Audit Events to Track Down Retention Label Assignments

A reader of my article about how to write a PowerShell script to report files and folders in a SharePoint Online document library observed that while the report details the retention labels assigned to items, it doesn’t say who assigned the labels. This is absolutely true, and it’s because SharePoint Online doesn’t note details of the last retention label assignment (date, user, etc.) in the information available through the Files Graph API. If the data isn’t available, it cannot be included in a report.

But retention label assignment is an auditable action. Details of assignments are captured by SharePoint Online and ingested into the unified audit log roughly 30 minutes after someone assigns a retention label to an item.

Searching for Retention Label Assignments

It’s easy to search the audit log for the logged events (the “TagApplied” operation is used here; the ComplianceSettingChanged could also be used) and report that information. Here’s some simple code to find the relevant audit events:

[array]$Records = Search-UnifiedAuditLog -Operations TagApplied -StartDate $StartDate -EndDate $EndDate -Formatted -SessionCommand ReturnLargeSet -ResultSize 5000

If ($Records.Count -eq 0) {
    Write-Output "No TagApplied events found in the last 30 days"
    Break
}   Else {
    # Get rid of duplicates
    $Records = $Records | Sort-Object Identity -Unique
    Write-Output ("Processing {0} retention label assignment events..." -f $Records.Count)
}

If the search is likely to return more than 5,000 events, it’s probably best to use the Graph AuditLogQuery API to perform an asynchronous search. Background searches can find hundreds of thousands of audit records if necessary.

The search finds assignment events when labels are applied manually by a user or automatically by an auto-label policy. In many careful scans of the audit log, I cannot find any events captured when files are uploaded to a document library and receive the default retention label configured for that library. The documentation says that events are triggered when retention labels are applied manually or automatically to a document but perhaps default retention labels are omitted.

Parsing the Audit Records

After finding relevant events, the next step is to remove any duplicates and sort the set by date.

$Records = $Records | Sort-Object Identity -Unique
$Records = $Records | Sort-Object {$_.CreationDate -as [datetime]} -Descending

The code then loops through the set to extract details and create a report. The name of the retention label and details of the file such as its name and host site and folder are in the AuditData structure, which must be converted from JSON to a PowerShell object to allow easy extraction of the properties.

The next issue is to find out who assigned the retention label. This is simple when users assign retention labels manually because the audit record stores the user principal name in the UserIds property. It’s less straightforward when auto-label policies are involved because the UserIds property contain the GUID of the retention policy rule that caused the label assignment to occur.

To translate the rule GUID back to a policy name, we need to find the GUID of the policy (because that’s how the rule links to its policy) and then extract the policy name. The code to resolve the rule GUID is not difficult, but it depends on being able to lookup the registered compliance policy rules and policies in the tenant. I use hash tables for this purpose and populate the tables with the Get-RetentionCompliancePolicy and Get-RetentionComplianceRule cmdlets.

Two GUIDs couldn’t be resolved by this method. I assume these represent background processes run by SharePoint Online to apply policies, so I declared the GUIDs in an array:

[array]$SharePointAutoLabelId = 'eba15bfd-c28e-4433-a20e-0278888c5825', 'a405a596-28e7-43c6-8ac7-76e0fc13ee0f'

If the GUIDs are found in audit records, the code reports them as “SharePoint Auto Label process.” One of the two GUIDs (‘eba15bfd-c28e-4433-a20e-0278888c5825’) is involved with the application of retention labels for document versions for cloudy attachments captured by a special policy, so I think it’s reasonable to assume that the other GUID represents some other form of background processing. Figure 1 shows some sample output.

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

Chasing Default Retention Label Assignments

Although using the audit log to answer the question about who assigned retention labels to files is reasonably accurate, I’m unhappy to find that default retention label assignments aren’t audited. Or at least, I can’t find the right audit event to report. I’ve asked Microsoft about the issue and hopefully they can clarify what’s going on.

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.

EX1015484 Issue Causes Duplicate Exchange Online Mail User Objects Linked to Entra ID Guest Accounts

I am indebted to MVP Joe Stocker for sharing information about incident EX1015484 (duration from February 20 7:38AM PST to February 27 5AM PST). The problem as reported by Microsoft (Figure 1) is that when administrators create new Entra ID guest accounts, duplicate objects appear in Exchange Online that prevent email delivery to the guest accounts.

Creating Mail User Objects

Entra ID and Exchange Online use a dual-write mechanism to update objects. Guest accounts originate when external users are added to Teams or Microsoft 365 groups, or when an administrator invites an external user to join the tenant from the Entra admin center.

When Entra ID creates a new guest user account, Exchange Online creates a mail user object. The existence of the mail user object allows guest users to be included in distribution lists. The mail user object has an email address, so email can be sent to the object, and the transport system is able to route messages to the guest account. Exchange Online removes a mail user object automatically following the removal of the guest user account from Entra ID. If the deleted Entra ID account is restored, the mail user object reappears.

Duplicated SMTP Addresses

In the case of EX1015484, it seems like Microsoft shipped a feature update with a bug that created mail user objects with duplicate SMTP email addresses. The Exchange transport system insists that email-enabled objects have unique email addresses because that’s the basis for routing messages to their final destinations.

Apparently, tenants need to contact Microsoft support to remove the duplicate objects. You can’t just remove duplicate mail user objects because of the dual-write mechanism. Entra ID is the directory of record, so any attempts to run Remove-MailUser to delete an object linked to a guest account will fail:

Remove-MailUser -Identity a9f35d52-572e-4438-a129-08d8c00ae88b

Confirm
Are you sure you want to perform this action?
Removing the mail enabled user Identity:"a9f35d52-572e-4438-a129-08d8c00ae88b" will delete the mail enabled user and
the associated Windows Live ID "elifon_contoso.com#EXT#office365itpros.onmicrosoft.com".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
Remove-MailUser: ||An Azure Active Directory call was made to keep object in sync between Azure Active Directory and Exchange Online.
However, it failed. Detailed error message:  Resource 'a9f35d52-572e-4438-a129-08d8c00ae88b' does not exist or one of its queried reference-property objects are not present. DualWrite (Graph) RequestId:
61220f4c-90ea-4fa5-bf1f-c07b5d10c26d The issue may be transient and please retry a couple of minutes later. If issue persists, please see exception members for more information.

Removing the guest accounts from Entra ID and restoring them after a few minutes might well work. I can’t say because the problem didn’t affect any tenant that I have access to.

In any case, Joe posted some PowerShell to find mail-enabled objects with duplicate SMTP addresses:

Connect-ExchangeOnline; Get-Recipient -ResultSize unlimited | Select-Object -ExpandProperty EmailAddresses | Where-Object {$_ -like "smtp:*"} | Group-Object -Property {$_.ToString().ToLower()} | Where-Object {$_.Count -gt 1} | Select-Object @{Name="SMTPAddress";Expression={$_.Name.Substring(5)}}, Count | Sort-Object -Property Count -Descending

The code is faster when a filter is applied to select mail user objects. Here’s my version (updated for Exchange Online Management PowerShell module V3.7.2; if you run V3.7.1, filter against MailUser objects)

Connect-ExchangeOnline; 
Get-ExoRecipient -RecipientTypeDetails GuestMailUser -ResultSize unlimited | Select-Object -ExpandProperty EmailAddresses | Where-Object {$_ -like "smtp:*"} | Group-Object -Property {$_.ToString().ToLower()} | Where-Object {$_.Count -gt 1} | Select-Object @{Name="SMTPAddress";Expression={$_.Name.Substring(5)}}, Count | Sort-Object -Property Count -Descending

I tested the amended code by removing the check for addresses with a count greater than 1, so I am pretty sure that it works. Feel free to improve the code!

Problems Happen

It’s regrettable that EX1015484 happens, but that’s the nature of software. The issue has been resolved, and you will no longer encounter mail user objects with duplicate SMTP addresses in your tenant. It’s worth running the code shown above just in case that the problem hit your tenant and left some bad objects behind.  

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.

Artificial Intelligence and PowerShell for Tenant Administration – An Unlikely Couple?

I’ve been asked by a few people to comment about Lokka, the new creation of Merill Fernando, a program manager in the Microsoft Entra ID group. Lokka is a proof of concept exploring how the combination of AI Large Language Models (LLMs) and the Model Context Protocol (MCP) can bring value to Microsoft 365 administration. In this case, by generating Graph API queries in response to administrator prompts. For example, “How many user accounts belong to the marketing or sales departments.”

Merill’s a very inventive individual whose capacity to invent extends to his eye-catching tweet asking the question if Lokka is the end of PowerShell for Microsoft 365 administrators (Figure 1).

Helping Administrators with Simple Queries and Examples

Of course, the advent of a proof of concept like Lokka doesn’t mean that Microsoft 365 administrators suddenly need to lose all interest in PowerShell. AI tools can certainly be helpful in responding to queries that aren’t covered by the standard admin center GUI. They can also educate administrators by showing them how to use PowerShell to run Graph AI queries.

The Exchange Server 2007 product was the first Microsoft server to embrace PowerShell. One of the brainwaves in that product was how the Exchange Management Center (EMC) console displayed the PowerShell code it executed when it performed actions. Figure 2 shows how the EMC in Exchange Server 2007 displayed the code used to create a new mailbox.

Seeing the PowerShell code in action and being able to copy the commands for reuse helped administrators master basic PowerShell command for managing Exchange servers. Another example is how Merill’s Graph X-Ray tool gives administrators a glimpse into the Graph API requests run to perform some actions in the console.

Artificial Intelligence and PowerShell in the Microsoft 365 Admin Center

The Microsoft 365 admin center already has Copilot assistance that’s added automatically when a tenant buys some Copilot for Microsoft 365 licenses (Figure 3). The implementation is much like a Copilot Chat session where an administrator prompts Copilot for some information and receives a response containing instructions and possibly some PowerShell code. I imagine that the content used by Copilot is a restricted set of documentation, just like you can restrict a Copilot agent to reasoning over certain SharePoint and external web sites when it composes its responses.

The Importance of Training Material

There’s no doubt that we will see increasing use of AI to assist administrators with tasks as time progresses. The assistance will become more comprehensive, intelligent, and useful. However, the usefulness of any generative AI tool is bounded by the material used to create its LLMs. This means that the answers that an administrative agent can give, whether how-to instructions or PowerShell code snippets, depend on text scanned to build the LLM. If an answer exists to a question, the AI can respond. This includes incorrect answers because the LLM doesn’t know if content contained in source material is accurate. And if an answer isn’t available, the AI cannot respond without hallucinating. For example, Copilot has been known to include the names of PowerShell cmdlets that don’t exist in its responses.

The current set of AI tools we have don’t include insight or creativity. They can respond to known problems, but even so, responses are often based on whatever the most common answer is found in its source material. Those answers might be inefficient. Take the code suggested in Copilot’s response in Figure 3.

Get-MgUser | Where Department eq "Sales"

Several problems exist with the answer. First, the syntax is incorrect and won’t work because the piping to the Where-Object cmdlet is wrong (probably because Copilot absorbed an incorrect answer from some source). Second, the Department property is not retrieved by the Get-MgUser cmdlet unless explicitly requested.

Get-MgUser -All -Property Id, Displayname, Department | Where-Object {$_.Department -eq "Sales"}

Third, it’s always better to use a server-side filter to retrieve PowerShell objects. And in the case of user accounts, it’s also a good idea to filter out guest accounts.

Get-MgUser -All -Filter "Department eq 'Sales' and userType eq 'member'"

And even with member accounts selected, you might get some accounts that are used for room or shared mailboxes that you don’t want to process.

The takeaway is that generative AI can only be as good as the material used for its training. The current state of the art is such that AI can’t recognize when its output is incorrect.

PowerShell Still an Essential Tenant Management Skill

Even with the prospect of better, more complete, and more comprehensive AI tooling on the horizon, I still believe that Microsoft 365 administrators should take the time to acquire a working knowledge of PowerShell. For the foreseeable future, AI might well offer help to those who don’t even know how to start using PowerShell to manage a tenant.

Experience to date demonstrates that AI is unlikely to master the creativity that’s often needed to create something like a full-blown tenant licensing report, complete with costs anytime soon. Combining data from multiple sources to deliver a solution requires more ingenuity than running straightforward Graph requests. I await to be proven wrong that artificial intelligence and PowerShell can do more than perform straighforward, mundane tasks. In the interim, using GitHub Copilot to accelerate the development of PowerShell scripts might be the most productive way to use AI to improve Microsoft 365 automation.

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.

Block ChatGPT Access to OneDrive and SharePoint Files

ChatGPT allows people to connect their personal and work OneDrive accounts. Connecting to OneDrive doesn’t mean that ChatGPT can reason over OneDrive files in the same way that Microsoft 365 Copilot can when it generates responses. However, it does mean that users can upload files from OneDrive for Business or any SharePoint Online site that they can access to interact with their content through ChatGPT. Figure 1 shows ChatGPT summarizes the content of a file uploaded from OneDrive for Business.

Of course, people shouldn’t store very confidential and sensitive information in OneDrive for Business accounts, but they do. And the temptation to use ChatGPT is obvious when the price of a Microsoft 365 Copilot license is high, so what can organizations do to stop this behavior.

ChatGPT Cannot Access Protected Files

One way to block ChatGPT access to OneDrive for Business is to encrypt the files with sensitivity labels. ChatGPT cannot process these files even after the owner of the file uploads them to ChatGPT. Sensitivity label encryption is based on rights management, and ChatGPT cannot authenticate with the rights management service to obtain the use license necessary to access files protected with sensitivity labels. That’s a pretty effective way to stop ChatGPT opening the file to copy its contents into memory to reason over the data. Microsoft 365 Copilot Chat faces much the same barrier if the sensitivity label assigned to a file doesn’t grant the EXTRACT usage right to the signed-in user (the new DLP policy for Microsoft 365 Copilot also uses sensitivity labels but blocks access in a different way).

Block Consent for Users

Not every Microsoft 365 tenant uses sensitivity labels, and even users in tenants that do don’t always protect files the way that they should. A more fundamental way to block ChatGPT access to OneDrive is to prevent users from being able to grant consent for apps (Figure 2). Make sure to select the “do not allow user consent” setting or allow consent for “low impact” apps.

If users can grant consent, the first user who attempts to connect their OneDrive for Business account to ChatGPT will create an enterprise app in Entra ID for ChatGPT with permissions to read user data (Figure 3). Note the permission to read items in all site collections. This is what allows the user to select files from SharePoint Online to upload to ChatGPT.

This isn’t an abnormal situation because many app publishers (including Microsoft) create enterprise apps in customer tenants in the same way. However, it’s better to have administrative oversight over requests to create new enterprise apps. When created, the ChatGPT app will have a service principal to hold its permissions. The same application identifier (e0476654-c1d5-430b-ab80-70cbd947616a) is used in all tenants.

$ChatGPTApp = Get-MgServicePrincipal -Filter "displayName eq 'ChatGPT'"
$ChatGPTApp

DisplayName Id                                   AppId                                SignInAudience                     ServicePrincipalType
----------- --                                   -----                                --------------                     --------------------
ChatGPT     db277364-71ae-4fa4-9b02-370699b75a0a e0476654-c1d5-430b-ab80-70cbd947616a AzureADandPersonalMicrosoftAccount Application

App consent events are captured in the audit log and can be checked there.

Track What’s Happening

If the ChatGPT app exists in a tenant, it’s easy to check if anyone is using it by looking for sign-in events in the Entra ID log. Here’s some PowerShell to check the sign-in logs for anyone using the ChatGPT application:

[array]$Logs = Get-MgAuditLogSignIn -Filter "AppDisplayName eq 'ChatGPT'" -All
$Logs | Group-Object UserDisplayName | Sort-Object Count -Descending | Format-Table Name, Count

Name                Count
----                -----
Kim Akers (She/Her)     5
René Artois             4

A more precise version checks for successful sign-ins using the ChatGPT application:

[array]$Logs = Get-MgAuditLogSignIn -Filter "AppDisplayName eq 'ChatGPT' and status/errorCode eq 0" -All

It’s worth emphasizing that stopping the ChatGPT app does not prevent people from being able ot upload local copies of files synchornized from OneDrive for Business or SharePoint Online to their PC. Sensitivity labels are the only way to protect local copies.

Remove the ChatGPT App

If the ChatGPT app is in use, the easiest way to block ChatGPT access to OneDrive for Business is to remove the service principal for its app:

Remove-MgServicePrincipal -ServicePrincipalId $ChatGPTApp.id

Access won’t terminate immediately because ChatGPT sessions might have obtained access tokens that are still valid, but once those tokens expire (within an hour), ChatGPT won’t be able to authenticate with Entra ID because the enterprise app is no longer present in the tenant. Anyone wanting to use ChatGPT to access OneDrive for Business files after that point will need to seek consent to use the app again. And by now, you’ll have blocked that route!

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.

Location Privacy Setting for Teams is Now Separate to Windows

If you wonder why Teams has suddenly started to prompt for approval to use your precise location and location history when you sign into a client, the answer lies in message center notification MC993226 (last updated 7 March 2025). It’s all to do with an update to Microsoft privacy policies governing how apps can use location information. Microsoft refers to this as a “location consent experience” which applies to Windows (running version 24H2 or later) and Mac workstations, but not VDI clients.

Take the example shown in Figure 1. Teams knows that the location setting for the Windows PC permits location information to be shared with IT admins to help troubleshoot issues like network connectivity (Figure 2). Until the change became effective, Teams used the Windows setting, but now Teams has its setting to govern whether it can access location data.

VDI desktops obviously don’t support the same level of precision when it comes to location data, which is why they’re currently excluded from location privacy. For more information about how to manage location sharing in Teams, see the Microsoft support documentation.

Targeted release has started, and general availability is slated for deployment between late March and early April 2025. The update will be available in the commercial and government clouds. Microsoft notes that the new location privacy consent “does not apply to fully managed devices where users are restricted from user granted location access” and that current policies will continue working as before.

Location Privacy is a Per Tenant Choice

Teams displays the location notice for each tenant accessed during a client session. For instance, if you switch from your home tenant to a tenant where you’re a guest member, Teams displays the location notice again. The reason is that the location information gathered by Teams is provided on a tenant basis, so the notice acts as a prompt for the user to disable the information in the Privacy section of the Teams settings app (Figure 3).

Location Data for Teams

MC993226 says that Teams is specifically interested in the SSID and BSSID. The SSID (service set identifier or network name) is the identifier for a Wi-Fi network. The BSSID (Basic service set identifier) is the MAC address of the network access point or Wi-Fi router used by a device to connect to a network.

Teams uses this information for the Call Quality Dashboard to track call quality at the organization level. Knowing someone’s location is also critical for location-based call routing to work. The data is also used for dynamic emergency calling in Teams Phone to allow the location of emergency calls to be identified. If your organization doesn’t have a Teams Phone subscription and a calling plan, you won’t have access to emergency calling. On the surface, if you don’t use Teams Phone, it seems like you don’t need to worry about location privacy.

Microsoft hasn’t given a firm number for Teams Phone users since July 2021 when they said that 80 million people used Teams Phone. However, although Microsoft has been nudging customers to use Teams Phone for years, the reported number doesn’t say how many users have paid calling plans instead of just using Teams Phone for VOIP calls.

Location Privacy is Important

Obviously, Microsoft would like users to consent to sharing location data with Teams as otherwise features won’t work as designed. I don’t think that anyone will complain too much about location data being shared with Teams to measure the quality of calls or to know where someone is when they make an emergency call. Using location data for other purposes, such as knowing the hot desk that someone is working at might be another matter, which is why keeping an eye on location privacy is important.

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.

Auto-Hide Inactive Channels and the New Chat and Channels Interface Just Don’t Work for Some People

It’s hard to create a client user interface that works well on Windows, Mac, and browsers that satisfies the often very different demands which exist in a very large user base (320 million or so, in what’s now a very old official figure). Yet that’s the task that the Teams development group sets itself as it rolls out interface changes. Sometimes, things don’t go to plan.

Solving the Auto-Hide Inactive Channels Mess

Take the plan to auto-hide inactive channels so that old and potentially obsolete channels wouldn’t get in the way of real work. On paper, it sounds like a wonderful idea. Channels do age over time and people do lose interest in what happens in some channels. Manually hiding a bunch of old channels could occupy a rainy Sunday afternoon, but who wants to do that.

The original intention is explained in Microsoft 365 roadmap item 325780, where we discover that “Teams will automatically detect inactive channels you haven’t interacted with in a while, and automatically hide them for you.” Soon after the launch of the feature in July 2024, Microsoft ran into user discontent.

The important word in Microsoft’s description is “automatically.” When software performs an action without human prompting, the results of the processing can be overlooked. In the case of Teams, people reported that important channels disappeared from the Teams and channels list. According to the unexplained algorithm used by Teams, the now-hidden channels appeared inactive and unused, and so liable for hiding. Users could find and unhide channels (Figure 1), but the extra work is a hassle.

The upshot is that Microsoft announced in MC804771 (March 21, 2025) that “Teams will offer users suggestions on channels that are inactive, and the user is prompted to review their inactive channels and hide them only if they choose.” The change to an opt-in model is expected to roll out to general availability “later in 2025.” Let’s hope that Microsoft does a better job this time around.

Moving Away from The New Chat and Channels Experience

Which brings me neatly to the new Teams Chat and Channel experience, trumpeted by Microsoft as being streamlined to help you collaborate more effectively. I’ve used the new interface since its earliest beta release as a new take on how to use channels. After Microsoft released the full version in October 2024, my review led off with “Microsoft’s waffle about the new experience is pure marketing spin.” That note reflected some of my frustration with trying to make the new experience work for me, despite having the opportunity to discuss the matter in depth with some of those responsible for the new interface.

After a further six months of trying, I’ve concluded that I work better with the old experience. I like the separation between chats and Teams. I find it easier to stay on top of current activities and find that I don’t overlook things the way that I do when chats and teams are comingled.

I know others share the same opinion, even if Microsoft’s fabled telemetry tells a different story (but those who construct and control the telemetry get to decide what the story is). I do know of people who love working in the new way, even if it doesn’t work for me. I suspect that the reaction to the new interface is highly individual and greatly influenced by how people work with Teams. As I noted in my review, in some tenants I use chat mostly. In others, it’s channel-based, and in others it’s a combination. I find that chat-centric activities are best in the new experience, but I still decided to revert to the old interface everywhere.

Both the Old and the New

The nice thing is that Teams supports both the old and new experience. In other words, the software respects user choice and doesn’t attempt to force people to do things in the one true way. It’s always better when user choice is respected, especially when changes are introduced in user interfaces. Maybe those responsible for the auto-hide inactive channels feature might have learned that lesson.

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.

Tweaks to Copilot for Outlook Make the Functionality More Accessible

On Tuesday, I reported that I thought the new Facilitator agent in Teams chat is a good example of AI performing a task well. It’s evidence of how the initial rush of deploying AI everywhere to anything that could have a Copilot label applied is moderating into better implementations.

Message center notification MC892651 (last updated 18 March 2025, Microsoft 365 roadmap item 397092) could be regarded as being in the same category. In this case, the UI for Copilot interactions in the Outlook has what Microsoft terms as “major design improvements” for the new Outlook on Windows and Mac desktops, OWA, and Outlook mobile clients. Outlook classic remains unaltered.

Perhaps because it involves major improvements or a wide range of clients, the deployment of the update has been delayed. Microsoft originally intended to have full deployment done by late February 2025. That date is now late April 2025. When this happens, it normally means that Microsoft had to halt the deployment to fix some problems.

No New Functionality in Revamped UI

According to Microsoft, the revamped UI doesn’t include any new functionality. I never saw the ‘rewrite like a poem’ option before (which might have improved some of my email enormously), so the fact that the new layout and navigation makes this option accessible (Figure 1) is proof that the overhaul works.

Of course, things work differently on mobile devices, but the changes seem to make things better there too (Figure 2).

By comparison, the Copilot options in Outlook classic are a tad austere (Figure 3), just like the options were like in the other clients before the change. The changes made in the other clients proves once again that good design is important when it comes to making technology accessible to users.

UI Great, Text Awful

I like the UI changes and think they improve how Copilot for Outlook works. However, the changes do nothing to improve the quality of the written text generated by Copilot, which remains bland and overly effusive to my taste. I guess that’s my personal approach to email shining through because I favor brief to-the-point messages over lengthy missives.

The late Mark Hurd (CEO of HP at the time) once advised me to always put the most important information in a message into the first paragraph so that recipients could quickly review items in their inbox without needing to read long messages on mobile devices (Blackberries and iPAQs then). Technology has moved on, but the advice is still true, especially as so many different forms of mobile devices are now in use. Maybe Copilot for Outlook needs a rewrite in one brief paragraph option.

More Change to Come

Although it sometimes seems much longer, we’re still only two years into the Copilot era. We’ll see more changes like this as Microsoft refines and enhances how Copilot is integrated into apps. Now that they’ve given Outlook a nice new UI, perhaps they’ll do the same for Excel and PowerPoint to make it easier to use Copilot in those apps. Or maybe that’s just me moaning because I’m not as proficient as I should be with those apps.

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.

DLP Policy for Microsoft 365 Copilot to Restrict Access to Sensitive Documents

Ever since the introduction of Microsoft 365 Copilot in March 2023, organizations have struggled to stop the AI consuming confidential or sensitive documents in its responses. Some of the early tools, like Restricted SharePoint Search, were blunt instruments hurried out as responses to customer requests. Microsoft’s current best answer is SharePoint Restricted Content Discovery (RCD), a feature normally licensed through SharePoint Advanced Management (SAM). All tenants with Microsoft 365 Copilot licenses are due to receive access to RCD and the deployment process is ongoing.

Microsoft says that the key use case for RCD is to “prevent accidental discovery of [files stored in] high-risk sites.” RCD works by limiting the ability of end users to search selected sites. By excluding sites from search, RCD prevents Copilot Chat (and agents based on Copilot Chat) from using the files stored in those sites in its responses. It’s still possible for Copilot to use information from a sensitive document if the user has the file opened in an app like Word. At this point, the sensitive content is open in memory and available for Copilot to process.

Blocking files from user access doesn’t stop system functions like eDiscovery working.

Update April 21: MC1059677 announces the extension of DLP protection to Copilot in Office apps (Word, PowerPoint, Outlook, and Excel).

Blocking Access to Individual Files

RCD is a good way to cast a protective net across multiple sites. But what about protecting individual files that might be in sites that aren’t covered by RCD? Until now, the answer has been to use sensitivity labels to stop Copilot Chat using sensitive files to generate its responses. Although sensitivity labels can stop Copilot using the content of protected files, it cannot prevent Copilot finding reference protected files through a metadata search.

Creating a DLP Policy for Microsoft 365 Copilot

A solution to that problem might be coming in the form of a new type of Data Loss Prevention (DLP) policy. The feature is described in message center notification MC937930 (last updated 6 February 2025, Microsoft 365 Roadmap ID 423483). DLP policies are usually used to block external sharing of confidential information, like Teams meeting recordings. Blocking files for internal consumption is a new step.

Essentially, tenants can create a DLP policy to check for specific sensitivity labels and block Copilot Chat (and agent) access to files with those labels. The functionality is now in preview and is scheduled for general availability in June 2025 (complete worldwide by the end of July 2025). Some gaps are always expected in preview code, and the gaps right now include alerts, incident reports, policy simulation, and audit records. In other words, it’s very hard to know when a DLP policy match happens to block access. But testing indicates that the DLP policy works.

The DLP policy for Microsoft 365 Copilot is a special form of policy in that the policy only covers Copilot and no other type of data (Figure 1).

The rules used in a DLP policy for Microsoft 365 Copilot are simple. The policy checks if a file has a specific sensitivity label, and if the sensitivity label is found, DLP executes the action to “prevent Copilot from processing content” (Figure 2). A rule can check for the presence or one or more sensitivity labels. In some respects, it might be easier to create a separate rule for each label.

Testing the DLP Policy for Microsoft 365 Copilot

To test the new DLP policy, I created several documents referring to regulations governing cryptocurrency in Iceland (a topic selected at random because I knew that my tenant was unlikely to store any files relating to the topic). I used Copilot for Word to generate the text for each file and added a reference to a mythical regulation to the text of each document to give Copilot an easy target to find. The first check asked Copilot Chat to find documents relating to cryptocurrency in Iceland with special relevance to the regulation. The sensitivity labels assigned to the documents were not covered by a DLP policy for Microsoft 365 Copilot, and Copilot found all the documents (Figure 3).

After applying sensitivity labels covered by the DLP policy for Microsoft 365 Copilot to two of the three documents, the search was rerun and Copilot found only one document (Figure 4).

I don’t pretend this to be a full test. However, it’s the only way to check preview software that doesn’t generate audit records or other traces to show when DLP policy matches occur to force DLP to execute the defined actions.

New DLP Policy Shows Promise

I’ll look forward to retesting the DLP Policy for Microsoft 365 Copilot after the software reaches GA and the full array of auditing and reporting options are available. Auto-label policies can only apply sensitivity labels to Office files and PDFs, and I suspect that this limitation won’t be lifted. That’s a pity because it stops the DLP policy being able to control access to items like the .MP4 files used for Teams Meeting Recordings (transcripts).

The nice thing is that users see no trace of a sensitive document show up in Microsoft 365 Copilot Chat. Unlike basic sensitivity label protection, which allows Copilot Chat to show metadata found in its searches, the DLP policy is silent. And that’s just the way you’d want it to be when dealing with sensitive data.

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.

The Microsoft 365 Admin Center Makes It Easy to Remove Domains

I’ve been cleaning up the set of accepted domains configured for my Microsoft 365 tenant. After we launched the Office 365 for IT Pros eBook, I acquired several domains like Office365ExchangeBook.com that seemed to be relevant to the book. Years later and the office365itpros.com domain persists with a large legacy of published articles and scripts. No real advantage has been gained from the other domains, so the decision was taken to drop the unwanted domains and remove them from Microsoft 365.

Removing a domain is easier than adding a domain. Go to the Domains section (under Settings), select the unwanted domain, and select Remove domain from the menu. This method works for vanity domains (the type that you pay domain registrars to own) but not for fallback or service domains used for MOERA addresses.

When you use the Microsoft 365 admin center to remove a domain, the portal thoughtfully shows the mail-enabled objects that will be affected by the removal (Figure 1). You can then remove any proxy addresses assigned to the highlighted objects that use the domains.

The Problem of PowerShell

But sometimes you might remove a domain with the Remove-AcceptedDomain cmdlet and so lose the benefit of the checks performed by the Microsoft 365 admin center. This is fair enough because if you make changes to a tenant configuration through PowerShell, you should understand the consequences of the action. I wish I did…

If you forget to adjust email addresses for objects affected by the domain removal, you’ll see errors like this when attempting to update an address:

Set-UnifiedGroup -Identity c38ef1e1-1957-4e5f-bcde-1eae7bb234f3 -PrimarySmtpAddress 'Soccer.Fans@office365itpros.com'
Set-UnifiedGroup: ||You can't use the domain Office365ExchangeBook.com because it's not an accepted domain for your organization.

Quite reasonably, the cmdlet complains that it can’t update the primary SMTP address for the Microsoft 365 group because it’s detected an invalid entry in the set of proxy addresses. To correct the issue, we need to find all the mail-enabled objects that has primary or proxy addresses that use the removed domain and remove or replace the offending addresses.

The PowerShell Solution

You can download the script I used from the Office 365 for IT Pros GitHub repository. Essentially, the script breaks down into three parts. First, the script retrieves the current set of accepted domains and identifies the default domain:

[array]$Domains = Get-AcceptedDomain 
$PrimaryDomain = $Domains | Where-Object { $_.Default -eq $true } | Select-Object -ExpandProperty DomainName
[array]$Domains = $Domains | Select-Object -ExpandProperty DomainName

Second, the script checks mailboxes, Microsoft 365 groups, distribution groups, and dynamic distribution groups to find instances where proxy addresses don’t belong to an accepted domain. The details of the affected objects are recorded in a list. Here’s how the script deals with mailboxes:

Write-Host "Checking mailboxes..."
[array]$Mailboxes = Get-ExoMailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox, SharedMailbox, RoomMailbox, EquipmentMailbox, discoveryMailbox

ForEach ($Mailbox in $Mailboxes) {
    $ExternalAddresses = $Mailbox.EmailAddresses | Where-Object { $_ -like "SMTP:*" -and ($_.Split(':')[1].Split('@')[1] -notin $Domains) }
    If ($ExternalAddresses) {
        $ReportLine = [PSCustomObject][Ordered]@{
            DisplayName             = $Mailbox.DisplayName
            PrimarySmtpAddress      = $Mailbox.PrimarySmtpAddress
            EmailAddresses          = $ExternalAddresses -join ", "
            Type                    = "mailbox"
            Identity                = $Mailbox.Alias
        }
        $Report.Add($ReportLine)
    }
}

Finally, each of the objects found by checking proxy addresses against accepted domains is processed to remove any bad proxy addresses and assign new primary SMTP addresses where necessary.

Not Perfect Code

I don’t pretend that this script is perfect code. All I can say is that it did the job for me and cleaned up primary and proxy addresses for my tenant and might therefore be useful to others in the same situation. What this experience goes to prove is that sometimes executing clean-up operations is better done through the GUI where you can take advantage of the work done by engineers to anticipate what needs to be done after adjustments are made to a tenant.

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.

Facilitator Agent Extracts Value from Teams Chat

In an article last month, I discussed why Microsoft 365 Copilot works better for some people than it does for others. The article is based on a blog by Abram Jackson, a program manager working on Microsoft 365 Copilot, and one of the points he makes is that AI fails when it doesn’t have the right data to process. This is why Copilot is so good at summarizing a bounded set of data such as a Teams meeting transcript or email thread and less good at other tasks.

Which brings me to a new bounded AI use in the Teams Facilitator “collaborative communication” agent (see message center notification MC1017117, last updated 10 March 2025, Microsoft 365 roadmap item 476811). The agent has been available in targeted release and is heading for general availability in April 2025. Facilitator is available for meetings and chats, but here I focus on chats because this is an area where AI hasn’t ventured before. According to Microsoft, “the Facilitator creates and maintains an up-to-date summary of important information as the conversation happens, including key decisions, actions items, and open questions to resolve.”

The administrator documentation and user documentation and doesn’t need to be repeating here. Essentially, you’ll need a Microsoft 365 Copilot license to use Facilitator (otherwise known as AI Notes). Note generation is supported for English now with support for more languages in the pipeline.

Control over  who can use Facilitator is exerted by allowing people access to the Facilitator app in the Teams admin center. Microsoft says that after general availability, the app is enabled by default and can be used in chats by enabling the AI Notes option (click the icon to the right of the Copilot icon). Let’s see what happens.

Using AI Notes in a Chat

When a chat starts, it’s an empty thread and there’s nothing for AI to process. In fact, AI cannot process information until it has sufficient data to understand what’s happening. This is what’s happening in Figure 1. Facilitator is enabled for the chat but only three messages are in the thread and that’s not enough.

This isn’t a problem because the intention behind Facilitator is that it will help chat participants understand what’s been discussed in a thread. It’s easy to understand the conversation after three messages. It’s much more difficult to do so after a hundred messages in a fast-moving debate. The same situation occurs for Microsoft 365 Copilot in a Teams meeting where a certain amount of data must accumulate in the meeting transcript before Copilot becomes active.

As the chat develops, Facilitator begins to generate notes (Figure 2) to capture the major points raised in the chat, any decisions made, and any questions that remain unanswered. Facilitator updates the notes displayed in the pane periodically and highlights new information that a chat participant hasn’t seen. Like other Copilot implementations, reference numbers allow users to access the source for a note.

At the end of the chat, any of the chat participants can ask Facilitator a question by using an @Faciliator mention and entering the question (Figure 3).

Alternatively, a participant with access to the AI Notes can copy the notes and paste them into the chat. This is a good way to share AI Notes with chat participants who don’t have a Microsoft 365 Copilot license as those people cannot enable and view AI Notes for the chat.

External Participants Turn Off Facilitator

The Facilitator agent can’t be used in chats that involve external participants (guest users or external federated chats). This is likely because no mechanism is available in a chat to allow people to grant consent for their messages to be processed by an agent. When people join a meeting, they have the chance to grant consent for transcription, and it’s the transcript that’s used by Microsoft 365 Copilot to summarize the meeting or answer questions about the proceedings.

Facilitator is a Nice Tool to Have

I like Facilitator very much. It’s an example of focused application of AI LLMs to reason over a bounded set of data to generate results that works well in practice. Facilitator is not enough to justify the full price of a Microsoft 365 Copilot license, but it is step in the right direction and is a sign that we’re moving away from what some call the “party tricks” of Copilot to the implementation of some really useful tools.

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.

Report Message and Report Phishing Deemed Unsafe by Microsoft

Message center notification MC1030003 (12 March 2025) brings news that the built-in Report button (Figure 1) is available for all Outlook clients (from these versions on). The older Report Message and Report Phishing add-ins are now in maintenance mode. Although they continue to work, Microsoft recommends that the add-ins should be removed before the time comes when Microsoft retires and finally removes the now-obsolete add-ins.

Microsoft cites many benefits for the new Report button, including support for reporting email delivered to shared mailboxes, better localization, and the ability to report messages from different places, like the preview window. My favorite is that users can’t report their own messages as junk because Outlook disables the Report button for messages sent by the mailbox owner. For now, this feature only seems to work in OWA and the new Outlook and sometimes it doesn’t work, but it’s certainly a good thing.

If users don’t see the Report button, it could be that the user reported settings in the Microsoft Defender portal need to be adjusted. These settings control whether users can submit messages suspected to be junk email or phishing attempts to Microsoft for analysis.

Some organizations don’t permit people to report email because they don’t want Microsoft personnel to be able to read the reported messages. That’s certainly a valid perspective, but phishing techniques evolve on an ongoing basis and a reported message could disclose a new technique that allows Exchange Online Protection to detect and block dangerous content. Overall, I think it’s best to allow users to report bad email.

Unsafe Add-ins

Rather alarmingly, the FAQ for the built-in Report button says that “there are security issues with the add-in which makes them unsafe for the organization” without saying or even hinting what those issues might be. The FAQ also says that the add-ins “can’t architecturally support functionality that customers keep asking for.” Again, no further information is given to back up the claim. It’s more likely that the problem is that these add-ins are COM-based. Microsoft is dumping this technology as it moves forward with the new Outlook for Windows.

Checking the Report Add-ins

Unless good reason exists not to use built-in client functionality, it’s best to use it rather than add-ins. Given the profusion of integrated apps that could appear in tenants due to Copilot agents, administrators are likely to be busy managing those apps. Getting rid of a few obsolete add-ins won’t ease the agent burden, but it’s step in the right direction.

Taking my own advice to heart, I checked in the Integrated apps section of the Microsoft 365 admin center to see if the Report Message and Report Phishing add-ins were still in use. As you can see from Figure 2, just one active user was detected.

The download option creates a CSV file that gives some details about the app and when it was used, but it doesn’t point to who is using the app. The app properties might be configured to allow access to the add-in to specific users or groups, and that could give a clue to who might be using it. But you’re out of luck if the app is configured for tenant-wide access.

Removing an Add-in

It’s always best to let users know that a change in coming. Microsoft says that people prefer the single Report button. In any case, changing from the add-in to the built-in report button shouldn’t prove too difficult for anyone, so I went ahead and removed the add-in from the set of Integrated apps (Figure 3).

It takes some time for a change like this to make its way to clients. Microsoft documentation says that it can take up to 24 hours before a newly deployed app appears in a client. The same applies to app deletions. My experience is that it can take longer before all clients receive updates. However, removed add-ins should disappear in a couple of days.

I’m glad to report that the removal of the old Report Phishing add-in from my tenant went according to plan. No squawking from annoyed users has happened so far. Maybe they haven’t noticed the change yet.

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-Fashioned Identity Client Jettisoned for OAuth

Message center notification MC1028318 (March 11, 2025) says that the SharePoint Online PowerShell module will replace the IDCRL authentication protocol with OAuth (modern authentication). Microsoft says that the replacement is “part of our ongoing efforts to enhance security and adopt modern authentication practices.”

Some might ask why it’s taken so long for Microsoft to make the decision to switch the module to OAuth. Microsoft has not given the SharePoint Online PowerShell module much tender loving care over the last few years. For instance, the module hasn’t been upgraded to PowerShell 7 and remains an outlier in this respect within the set of PowerShell modules used within Microsoft 365.

It’s not as if an adequate Graph-based replacement exists. The SharePoint Settings Graph API appeared in mid-2022 and hasn’t made much progress since. It’s just one of the reasons why the SharePoint PnP module is so popular.

The Identity Client Run Time Library

IDCRL is the Identity Client Run Time Library. It’s a very old authentication protocol that was used by products like Lync 2010 Server to authenticate with Exchange Online and Lync Online. IDCRL was also used by the Office desktop apps. Microsoft replaced IDCRL in the Microsoft 365 Apps for enterprise in September 2020 (MC222132).

More pertinently, SharePoint Online used IDCRL for authentication until recently, including with CSOM-based applications.

Upgrade in Modules Released after March 28, 2025

Microsoft issues new versions of the Microsoft.Online.SharePoint.PowerShell module regularly, mostly to add cmdlets or parameters needed to manage features like intelligent versioning. In this case, the change to OAuth is effective for modules released after March 28, 2025 (versions higher than 16.0.25814.12000).

You can download the latest version of the SharePoint Online management module from the PowerShell gallery (Figure 1). Once installed, the Connect-SPOService cmdlet automatically uses modern authentication (also called “modern TLS protocols”) instead of IDCRL. Although the implementation is designed not to affect how scripts work, you might see warning messages because Microsoft will deprecate the ModernAuth parameter in the future (the parameter is now obsolete).

Although I accept Microsoft’s statement that the upgrade to OAuth-based authentication should not affect scripts, it’s always wise to test and verify in case the specific use of the module in a tenant is an edge case that Microsoft doesn’t test. Given some of the recent problems with other PowerShell modules, testing an updated module before putting it into production is always wise.

One Small Step Forward

Given Microsoft’s focus on removing outdated authentication protocols from across Microsoft 365 workloads, it’s surprising that the SharePoint Online management PowerShell module is only now being updated. It’s well behind the modules to manage other major workloads like Exchange and Teams. But then again, as I keep on saying, the signs over the last few years is that Microsoft really doesn’t devote too much attention to the SharePoint Online management module, and that’s a real pity.

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.

Client-Side Limitation or Licensing Limitation?

Microsoft launched the new message recall feature for Exchange Online in October 2022 and shipped the code in early 2023. I duly wrote about the feature and noted the restriction for email protected by sensitivity labels. The EHLO blog describing message recall says:

Does recall work for encrypted email?

Message Recall within Classic Outlook is not available for messages encrypted with OME or using MIP labels. When attempting to recall these messages, the recall option will be greyed out in Classic Outlook and unavailable. This is a client-side limitation and is by design. To recall these messages, access your mailbox using OWA or the New Outlook for Windows, and recall your message from there.

Microsoft subsequently revamped the new message recall in August 2024. Nothing more was said about sensitivity labels. All we know is that a client-side limitation stops Outlook classic being able to recall protected messages while OWA and the new Outlook can both recall protected messages with ease (Figure 1).

Having the Right License is Always Important

Roll forward to message center notification MC882266 (last updated 23 October 2024, Microsoft 365 roadmap item 413431) where we discover that a component called Microsoft Purview Information Protection Advanced Message Encryption lies at the heart of the matter. According to the notification, user accounts must have a Microsoft 365 E5 or Office 365 E5 license to be able to recall encrypted email from their Sent Items folder. The same limitations that the mailbox must be in Exchange Online and that recall is only possible for messages sent to recipients within the same organization exist.

Notice that there’s no mention of client-side limitations. When such limitations are mentioned, it implies that some software problem exists within a client that prevents the client from being able to do something. Outlook classic is perfectly capable of working with sensitivity labels that encrypt messages.

In fact, Outlook classic is the most capable client in terms of working with encrypted messages because it can operate offline, including the ability to issue message recall requests for unprotected email by selecting a message and using the option in the File menu (Figure 2). The recall option isn’t available if the selected message has a sensitivity label with encryption.

Recall requests are kept in the Outbox folder until a network connection is available. Synchronization then occurs to send the recall request to Exchange Online for processing.

The ability of Outlook classic to work offline almost as well as when online is where the real issue might lie. OWA and the new Outlook are both designed to work online and that’s how they usually work. It’s therefore easy for the clients to check the licensing status of the signed in user, specifically to check that the account holds the Azure Information Protection Premium P2 service plan that’s included in the Microsoft 365 E5 and Office 365 E5 products. Outlook classic would need additional code to check user licensing when online so that it could work offline, much like the client stores rights management use licenses to allow it to work with protected messages when offline.

It can be argued that the limitation exists both in the client (can’t check a license unless Outlook classic is online) and licensing (can’t recall protected messages unless the right license is available), so the somewhat torturous text MC882266 is accurate without being clear.

Message Recall in Outlook Mobile

Meanwhile, message center notification MC1025213 (7 March 2025, Microsoft 365 roadmap item 471444) announces that Outlook for iOS and Android can recall messages. The option is available from the […] menu after selecting a message (Figure 3).  Outlook mobile clients cannot recall protected messages.

In Case of Protected Recall, Look for OWA

I’m not sure how many people will want to recall encrypted messages. If you find yourself in this situation, it’s easy to fire up OWA or the New Outlook and issue the recall request. Of course, the added time required to remember to use a different client and perform the message recall might mean that the recipient has read the text, but that’s a risk you must take.

Keep up to date with developments like the new Outlook by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Use ECS to Send Outlook Newsletters to Thousands of External Recipients

After writing about the new Outlook Newsletters app last week, I was asked if any workaround existed to allow newsletters to be sent to external recipients. If you only need to send a newsletter to a few external recipients, the easy answer is to create an Exchange Online mail contact for each recipient. Assuming that a distribution list is used to distribute a newsletter, the mail contacts can be added to the distribution list membership and so receive their copy when the Exchange transport service expands the membership to dispatch the newsletter to its final destinations.

This approach works for any external SMTP address, defined as an SMTP address that doesn’t belong to one of the accepted domains registered for the tenant. I often use the technique to capture copies of messages sent to distribution lists as posts in a Teams channel. Figure 1 shows an example of such a mail contact. Note that the contact is hidden from address books to prevent its discovery by users who browse the GAL.

Scaling Up to Cope with External Recipients

However, adding individual mail contacts for external recipients is not a method that’s easy to scale up. You can automate the process with PowerShell by using the New-MailContact cmdlet to create mail contacts and the Add-DistributionGroupMember cmdlet to add mail contacts to a distribution list, but that’s probably too much trouble for the delivered value.

Besides, using distribution lists to send messages to large numbers of external recipients will run foul of the new tenant external recipient rate limit (delayed for implementation until 1 May 2025), not to mention the individual mailbox external recipient rate limit that’s due for implementation in October 2025. A better solution is required.

Sending an Outlook Newsletter with Azure Email Communication Services

Azure Email Communication Services (ECS) is a pay-as-you-go service based on Exchange Online that’s expressly intended to process external email sent at high volumes, like newsletters directed at customers. The problem is that Outlook Newsletters use “regular” Exchange Online and have no connection to ECS, so we need a way to bridge the gap.

My solution, imperfect and manual as it is, goes like this:

• Create and send an Outlook newsletter as normal.
• Open the copy of the newsletter in the Sent Items folder of the author’s mailbox (or the copy received by any recipient).
• Copy the HTML body and paste it into a Word document. Make sure to select the keep source formatting option to remain the layout. The result should look something like the document shown in Figure 2.

Save the Word document as a web page (HTML file). The output HTML file should contain all the formatting instructions and pictures for the newsletter.

If you look at the script referenced in the article about ECS, you’ll see that the setup necessary to send a message through ECS using PowerShell is very similar to sending a message with the Microsoft Graph PowerShell SDK. Essentially, you create and populate a message structure before submitting it to ECS to be sent. Part of the message structure is the message body, which can be formatted as HTML.

When I worked with ECS last year, I discovered that ECS was very sensitive to the HTML in a message structure and refused to process HTML generated from Word. That issue seems to have gone away because I was able to load the HTML for the Outlook newsletter into a string variable like this:

[string]$HtmlContent = Get-Content Newsletter.htm

Next, I amended the script code to change the message subject and use the HTML content loaded in from the newsletter and used the code to send newsletters to several hundred email addresses as a test. Here’s the code that does the work.

[int]$i = 0
Write-Host "Processing messages... "
ForEach ($Recipient in $RecipientList.Email) {
    # Construct the TO addresses for the message
    [array]$ToRecipientAddress = Get-MessageRecipients -ListOfAddresses $Recipient
    $i++
    Write-Host ("Sending email to {0} ({1}/{2})" -f $Recipient, $i, $RecipientList.count)

    # Build a hash table containing the settings for the message
    $Email = @{
         # The sender's email address
        senderAddress = $senderAddress
        # Create a unique identifier for this message
        headers = @{
            id = ("{0}-{1}" -f (Get-Date -format s), $ToRecipientAddress.address)
        }
       
        # The content of the email, including the subject and HTML body
        content = @{
            subject   = "Office 365 for IT February 2025 Articles"
            html      = $HtmlContent
        }
        # The recipients of the email
        recipients = @{
            to = $ToRecipientAddress
            bcc = @(
               @{
                   address     = "o365itprosrenewals@office365itpros.com"
                   displayname = "Office 365 for IT Pros Support"
                }
            )
        }
        # The reply-to addresses for the email - doesn't have to be the same as the sender address
        ReplyTo = @(
            @{
                address     = "o365itprosrenewals@office365itpros.com"
                displayName = "Office 365 for IT Pros Support"
            }
        )
        userEngagementTrackingDisabled = $false
    }

    # Convert the email settings structure to JSON
    $EmailSettings = $Email | ConvertTo-Json -Depth 10
    $MailStatus = $null
    # Define the URI to post to when sending a message with ECS. 
    # The same URI is used for all messages. The body of the message dictates who receives the email
    $Uri = ("https://{0}/emails:send?api-version=2023-03-31" -f $CommunicationEndpoint)
    # Submit the message to the Email Communication service
    try {
        $MailStatus = Invoke-RestMethod -Uri $uri -Method Post -Headers $headers -Body $EmailSettings -UseBasicParsing
    }
      catch {
        Write-Host ("Failed to send email to {0}" -f $Recipient)
     }
   }
   Start-Sleep -Seconds 2
   $Recipient = $null
}

Combine Different Components to Solve a Problem

The results aren’t perfect. Some email clients complain that the messages contain trackers (used by Outlook Newsletters to track the number of recipients that open newsletters. Some clients can’t display the inline graphics (Outlook classic does the best job). Tweaking of the HTML before it is processed by ECS might fix these problems. It’s worth noting that we’re dealing with preview software sending messages through an unsupported route, so some difficulties are to be expected.

Even though this is a use that Microsoft doesn’t support, it seems possible to use Outlook Newsletters for what it’s good at (creating nice-looking newsletters) and send the output to as many external recipients as you want through ECS. Given the imminent limitation for external recipient traffic being imposed by Exchange Online, using ECS might just be a solution for those who depend on being able to send high volumes of email to customers. ECS is harder to set up than simply sending messages from Outlook, and its traffic costs money, but ECS does get the job done.

After Microsoft ships Outlook Newsletters, they might support the use of ECS. It seems like a sensible next step!

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.

Attendance Report Retention Policy Already in Force

Microsoft decision (announced in message center notification MC1022529 on March 4, 2025) to implement a retention policy for meeting attendance reports is interesting on multiple levels. The title of the notification is misleading because this is a new rather than an updated retention policy.

The attendance report retention policy is in force now and means that “all meeting attendance reports will be stored for one year after meeting end date to align with the Microsoft privacy policy.” I don’t see any specific mention of meeting attendance reports in Microsoft’s privacy policy, but I’m sure it’s covered somewhere. At least, it is to the satisfaction of Microsoft’s lawyers.

The term “retention policy” can confuse because it usually refers to the policies managed by Microsoft Purview data lifecycle management, aka Microsoft 365 retention policies. Teams chats and channel conversations can be managed by Microsoft 365 retention policies, but in this case, the retention policies are specific to Teams, just like the retention applied to Teams meeting recordings.

Attendance Report Basics

Attendance reports are available to meeting organizers. They can also be accessed programmatically using Graph APIs. In the case of meeting recordings, Microsoft research discovered that very few recordings were viewed more than 60 days after an event. It seems likely that exactly the same case pertains for attendance reports.

I doubt that many organizers go back and check the attendance for long-finished meetings. Certainly, organizers possibly review the attendance report for some meetings, but I don’t think this is common practice. Those who do can see details like the time meeting attendees joined and left the meeting, and if they reacted during the event (Figure 1).

Clicking on an attendee reveals details of that person’s “engagement” with the meetings (Figure 2). Some are less effusive during calls and dislike using reactions to express their view on proceedings. Others are more demonstrative. It’s all very much a personal choice, as is enabling cameras during calls.

Downloading Attendance Report Data

The download option for attendance reports preserves the attendance report data in a CSV file. If you want to preserve information about meetings held before November 1, 2024, you have until late August 2025 to download that data. That’s curious, because a one-year retention policy implies that these reports should be available for a full year. For instance, the attendance reports for meetings held in October 2024 should be available until October 2025, and so on. Tenants can’t change the retention period, alter the retention period, or influence when retention jobs run to remove attendance reports.

My assumption is that Microsoft began stamping attendance reports with retention dates on or around November 1, 2024, and took the decision to run a one-time clean-up of older attendance reports on some unspecified date in late August 2025. Attendance reports have been around for several years. Microsoft discarded the old format in February 2021 and have been tweaking the current format ever since. The one-time cleanup operation will set a baseline for ongoing retention in the future.

No Option to Avoid

Microsoft 365 tenant can’t avoid the new attendance report retention policy. The justification for the new policy is Microsoft’s privacy policy and it’s probably a justifiable course of action considering the probability that people will want to go back and view old attendance data years after an event. Besides, organizers can preserve attendance data if they need to, so there’s not much to complain about.

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

New 3,000 Threshold for Dynamic Distribution Groups in April 2025

Fresh from its decision to impose a tenant-wide external recipient run rate (now delayed until May 2025), Microsoft announced another restriction for Exchange Online on March 5, 2025 by limiting the number of dynamic distribution groups (DDGs) in a tenant to 3000 (message center notification MC1024399). Once the limit is reached, no further dynamic distribution groups can be created until some have been removed. Microsoft plans to introduce the restriction in early April 2025.

To discover how many dynamic distribution groups are in a tenant, run this PowerShell command:

(Get-DynamicDistributionGroup).count

A Surprising Move

It’s a surprising move. Dynamic distribution groups require service resources to resolve recipient filters to individual recipients when messages pass through the transport pipeline. Microsoft announced “modern” DDGs in December 2021 (rolled out in mid-2022) to save resources and reduce the time required to process list expansion by calculating list membership on a scheduled basis in the background rather than on-demand.

Dynamic distribution groups support both precanned and custom recipient filters, and expansion of some complex custom filters is likely quite demanding. Recently, Microsoft fixed a bug in wildcard support in DDGs that affected custom filter resolution for many customers. No hint was given then or earlier that tenants might be using too many DDGs. I suspect that very few tenants surpass the new 3,000 limit.

Entra ID supports a much higher 15,000 limit shared between dynamic Microsoft 365 groups and dynamic administrative units. Both the dynamic Entra ID object types require Entra P1 licenses whereas dynamic distribution groups are covered in the standard Exchange Online license. Dynamic distribution groups are not Entra ID objects and do not synchronize from Exchange Online to Entra ID. Nevertheless, it seems odd that Exchange Online should choose a much lower limit than pertains for dynamic Microsoft 365 groups. Conspiracy theorists will no doubt conclude that the new limit is yet another not-so-subtle hint from Microsoft that they’d prefer if customers use Microsoft 365 groups instead of distribution groups.

The actual answer might be that this is a simple check to stop people abusing dynamic distribution lists. Many components that consume service resources are limited in one way or another. This could just be another example of Microsoft introducing a threshold to impose an upper limit on the resources DDGs can consume.

Checking for Inactive Dynamic Distribution Groups

If your tenant is near the new limit, you might want to check for inactive Dynamic distribution groups. The easiest way to do this is using the report available in the Reports section of the Exchange admin center (Figure 1). As you can see, all 27 of the DDGs in my tenant are unused, probably because so much of my recent work has focused on Microsoft 365 Groups and Teams.

The report supports filtering for 7, 30, and 90 days and a custom start date (within the last 80 days). The information shown in the report comes from message tracing data (which goes back a maximum of 90 days). If you want more control over the reported data, you can use the technique explained in this article to run historical message trace reports and analyze that data with PowerShell (the article explains how to do this for normal distribution groups, be sure to change the reference to the Get-DistributionGroup cmdlet to Get-DynamicDistributionGroup).

Time to Trim Dynamic Distribution Groups

I don’t have knowledge about any abuse that might have driven Microsoft to clamp down on dynamic distribution groups, Given that it is very easy to build a recipient filter that addresses everyone in the tenant, it’s understandable that abuse could occur in the form of a significant increase in email volume generated when such a DDG is used. In the past, this might have caused an email storm, but Microsoft built checks for email storms into Exchange Online several years ago.

In any case, the limit will come into effect in early April 2025. Before then, it’s time to check the set of dynamic distribution groups with the aim of trimming unused DDGs. And if you can’t get the number of DDGs under the limit, consider converting them to dynamic Microsoft 365 groups.

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.

Outlook Users Never Realized the Desperate Need for Colored Folder Icons

The announcement in message center notification MC993229 (31 January, 2025), Microsoft 365 roadmap item 472921) that the new Outlook (or as it’s referred to in the announcement, “the new Microsoft Outlook for Windows desktop” and OWA are allowing users to personalize folder icon colors is in the category of “why” features. Apparently, the idea is to make it easier for people “to visually differentiate and personalize folders.” The feature is available in targeted release tenants and will be generally available worldwide during March 2025.

I don’t want to pour cold water on innovation, but the thought did go through my mind that the Outlook classic desktop client has survived and prospered since 1997 without different colored folder icons. The same is true for OWA, introduced around the same time, and seemingly unaffected by monocolor folder icons.

Using Outlook Colored Folder Icons

But now we have colored folder icons and the world is a better place. At least, it might be if you’re not color blind (like me) and have difficulties differentiating between nuanced shades. In the spirit of adventure, I resolved to bring a dash of color into my email life and set out to update some folders.

The first thing to note is that you can leave Outlook alone and it will use automatic colors. In other words, Outlook chooses how to present the folder icon. I’m not quite sure what color is used, but it’s functional and never caused me a moment’s worry until now, mostly because I never thought about choosing a new color for folder icons.

In Figure 1, the Archive folder is selected, and its folder icon is colored silver, one of the options in the folder icon palette. Some of the other folders have new colors too. Whether this makes those folders more recognizable or visually differentiated is in the eyes of the beholder.

To reveal the option to choose a new color for a folder icon, click the […] folder menu alongside its name. To produce the screen shot shown in Figure 1, I selected the folder menu for the Sent Items folder. As you can see, Sent Items still uses the automatic default chosen by Outlook. To update the folder icon color, choose one of the available selection like cranberry, light teal, or lime (note to self, who would have thought that I would ever write about applying lime as a color to any Outlook component?).

In any case, it all works, and you can spend a few minutes colorizing your folder icons.

Filers versus Pilers

I don’t know what impetus pushed the Outlook team to introduce colored folder icons at this point in the product’s development. It seems like many users eschew the use of folders apart from the default set because they depend on search to find items of interest when necessary. Piling items into a small set of folders is a habit encouraged by reliable search, something that took Outlook a long time to acquire.

I’m a filer in that I use folders to organize information. I’m not as diligent about filing as I once was in the days when search worked intermittently. Smaller mailbox quotas meant that it was sometimes necessary to clear out lots of items to make space for new email. Large mailbox quotas and retention processing have largely taken care of the need to delete items from mailboxes manually. I guess we need to fill the time once spent removing unwanted debris from mailboxes with other activities, like choosing colors for folder icons.

But Seriously

Some will criticize the Outlook developers for spending valuable engineering time implementing features like folder icon colors. If Microsoft is really serious about convincing the curmudgeons who use Outlook classic to move to the new client before support ceases for Outlook classic in 2029, shouldn’t they be solving the major pain points that stop people switching? Of course, Microsoft should deliver solutions like solid PST support (due imminently according to MC966639), but assigning a bunch of extra engineers to work on the pain points might not create solutions any faster. Which is why the engineers need to be kept occupied by pushing forward the frontiers of information technology with colored folder icons.

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.

Now Possible to Include iOS Build Numbers in ActiveSync Device Access Rules to Allow Access for Devices Running Specific Builds

I last looked at Exchange Online Mobile Device management in June 2023, when I wrote about reporting devices that synchronize with Exchange mailboxes using ActiveSync. At the time, I said that not many changes had recently occurred in Exchange Mobile Device Management. After all, Microsoft wants customers to use Intune, and Exchange Mobile Device Management is very much the runt in the Microsoft device management litter.

Which brings me to message center notification MC916298 (23 October 2024) and now fully available in tenants worldwide. It’s the first change in ActiveSync Device Access rules that I can remember since Microsoft updated rules to support Outlook for iOS and Android after its Acompli acquisition in late 2014. The best articles about how to configure device access rules still date from that period. Exchange ActiveSync is not an area of high change.

Query Strings and iOS Build Numbers (or Build Strings)

The change is that Apple iOS build information is now supported in the query string used to check the O/S version on mobile devices attempting to connect to Exchange Online mailboxes. MC916298 says “build number,” but Apple uses alphabetic identifiers like 22D72 (Figure 1).

Leaving semantics aside, the point is that organizations can create ActiveSync device access rules based on the information reported by iOS devices. For example, this code creates an access rule that allows IOS devices running iOS 18.3.1 22D72:

New-ActiveSyncDeviceAccessRule -AccessLevel Allow -Characteristic DeviceOS -QueryString "iOS 18.3.1 22D72"

To block iOS devices with a specific build, change the access level to Block.

I guess that the new capability exists to allow tenants to insist that iOS devices use a specific build for whatever reason that they might have. It’s just another level of granularity to detect devices.

Testing a Block Using iOS Build Numbers

The documentation for the New-ActiveSyncDeviceAccessRule cmdlet hasn’t been updated recently (it features examples blocking iOS devices running 6.1.1), so don’t expect much additional information from that source. However, I can guarantee that the access rule shown above works. I know this because I removed all the other access rules from my tenant and created one that was slightly different to the one shown above (IOS 18.4.1 rather than iOS 18.3.1). After a pause of about 15 minutes for the rule changes to replicate and become effective, the access rule blocked any attempt by Outlook for iOS to synchronize with mailboxes (Figure 2).

Users of non-compliant iOS devices also received email to tell them that their devices couldn’t connect and was blocked from synchronizing with Exchange Online (Figure 3). Interestingly, the blocked devices have never shown up in the quarantined device list in the Exchange admin center.

After being shouted at by several users who were unhappy that their email wouldn’t synchronize, I deleted the incorrect access rule and replaced it with the proper version. Within 15 minutes, email flowed again and all was well.

Time to Check Device Access Rules

Apart from playing with IOS build numbers, the exercise in testing device access rules was useful because it forced me to clean out the old and obsolete device access rules that had accumulated in my tenant. There was a time when these rules were critical. Given the dominance of Outlook for iOS and Android, I suspect that many tenants have just one rule (to allow access to those clients. Defining more sophisticated access rules are only needed to control clients that use the Exchange ActiveSync protocol for everything, like the native Apple mail app. Oh well, on to the next thing.

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.

Outlook Newsletters App for Outlook and OWA

Message center notifications MC1009916 (19 February 2025, Microsoft 365 roadmap item 328282) describes the new Outlook Newsletters solution, designed to create and send high-quality internal newsletters. The app is rolling out now in preview to targeted tenants. Standard tenants are likely to see Outlook Newsletters before the end of March 2025. General availability is scheduled for August 2025.

Outlook Newsletters is an app constructed from components drawn from the Microsoft 365 software toolbox like SharePoint Embedded, Microsoft Designer, Outlook reactions, comments, and so on. It’s a good example of how to combine available components with new code to create new apps.

Enabling Outlook Newsletters

Outlook Newsletters is an opt-in solution, meaning that it must be enabled before it appears in the menu bar for the new Outlook for Windows or OWA. Enablement is through settings in the OWA mailbox policies applied to mailboxes. Three policy settings are available (the administrator documentation is sparse and likely to be overhauled before general release):

• OutlookNewslettersAccessLevel: defines the access level a mailbox has to Outlook Newsletters. To create and send newsletters, this setting must be ReadWrite. Users with ReadOnly access can open the Newsletters app but can’t create or send newsletters. The default is no value, which equates to NoAccess.
• OutlookNewslettersReactions: Set to DefaultOn to make it the default that newsletters allow recipients to react in the same way as they react to normal Outlook email. Reactions can only be posted by internal recipients.
• OutlookNewslettersShowMore: Set to DefaultOn to make it the default for newsletters to display other newsletters at the bottom of a message. The idea is that recipients might find newsletters to subscribe to.

For example, this command allows any mailbox with the scope of the OWAFullAccess policy to have read write access to the Newsletters app with the other features enabled by default.

Set-OwaMailboxPolicy -Identity OWAFullAccess -OutlookNewslettersReactions DefaultOn -OutlookNewslettersAccessLevel ReadWrite -OutlookNewslettersShowMore DefaultOn

After updating the mailbox policy, it will take between 15 and 30 minutes before the Newsletters app becomes available to users in the Outlook menu bar. Alternatively, users can open the app using the direct link.

Quick Tour of Outlook Newsletters

The user documentation for Outlook Newsletters is available online and doesn’t need to be repeated here. Instead, I’ll describe how I created and sent a newsletter in just a few minutes.

After opening the app, you can choose to create a newsletter or group page. A group page is recommended when a newsletter has multiple contributors and multiple newsletters will be created with common branding, so that’s what I created (Figure 1). I added a heading and some common settings shared by all the newsletters associated with the group page.

Next, create a newsletter by selecting one of the out-of-the-box templates or a blank template. I used the basic template, which seemed like a good starting point to create a newsletter to circulate details of blog posts published over the last month.

Creating the content of a newsletter is a matter of editing the elements contained in sections. A template contains prepopulated sections to make the task easier, but you can add or remove elements as you like to create the desired effect. In my case, I extracted snippets and links for blog posts and combined them with images to highlight each article. Suitable images can be uploaded or generated using Microsoft Designer.

Draft newsletters and comments are stored in SharePoint Embedded containers and are visible through the SharePoint admin center (Figure 3) and PowerShell. Unhappily, an application name isn’t registered for the containers used by Outlook Newsletters. No doubt this is a detail that Microsoft will clean up before GA. Because of the dependency on SharePoint Embedded, those who create newsletters need a SharePoint Online license.

When the newsletter is complete, it’s ready for sending. This process involves creating a HTML format body part and combining it with message properties like the message title and recipients (Figure 4) before sending the message from the author’s mailbox, much like you’d do with Graph APIs.

Only known recipients can receive newsletters. A known recipient is an emailable object known to Exchange Online, including distribution lists, Microsoft 365 groups, individual mailboxes, mail user objects for guest accounts, and mail contacts.

You can enter an SMTP address, but Outlook drops these addresses if they don’t match with a known recipient when it sends the message. The golden rule is that to send a newsletter to an external address, the address must belong to a known recipient. This isn’t a big deal because it’s easy to create a mail contact for an external recipient, even for something like the email address for a team channel.

When sent, copies of the newsletter are normal messages in recipient mailboxes. After it is sent, the newsletter remains available for editing in the Newsletters app. If you make some changes and send another version, everyone in the recipient list receives a new copy.

Lots to Like

There’s lots to like about the Outlook newsletters app. The output generated looks well, basic analytics are included, newsletters support subscribe and unsubscribe options, messages can be sent from one mailbox with replies going back to a different mailbox, and so on. It’s definitely an app that people who send internal communications can find value.

Although it’s possible to send newsletters externally, restrictions like the new tenant-wide external recipient limit in Exchange Online constrain sending high volume communications, even if you add all the external email address as mail contacts. Used properly for internal communications, Outlook newsletters have the potential to be very successful.

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.

Microsoft Graph PowerShell SDK Problems Means that Reputation Won’t be Easily Fixed

On February 25, 2025, I described how bugs in V2.26 of the Microsoft Graph PowerShell SDK made the software unusable. Late the same day, Microsoft pushed out V2.26.1. After a week’s testing, the signs are that the new version solved some of the problems seen in V2.26. However, bugs are still present in V2.26.1, including licensing failires and a nasty “invalid JWT access token” issue encountered when running the Connect-MgGraph cmdlet in an Azure Automation runbook. This error means that Connect-MgGraph failed to authenticate with Entra ID to secure an access token to allow the runbook to access data. It’s a pretty fundamental problem that’s accompanied by other issues reported on the Microsoft Graph PowerShell SDK GitHub issues page.

Given the current state, my advice is to stay on V2.25 until we know that a solid newer version of the Microsoft Graph PowerShell SDK is available.

On the surface, progress in squashing bugs is happening, and we can carry on using the SDK to generate automation solutions for Entra ID and Microsoft 365 as normal. Alas, that’s not a great plan At least, if Microsoft continues to develop the Microsoft Graph PowerShell SDK as before, exactly the same problems will appear in future versions. Lack of testing and poor communication will lead to more bugs and heightened customer dissatisfaction as Microsoft replays what happened with V2.14, V2.17/18, and now V2.26.

The Question of Testing to find Microsoft Graph PowerShell SDK Problems

Customers who experienced problems after installing V2.26 can justifiably ask what testing happens during the release cycle for a new version of the Microsoft Graph PowerShell SDK. I’m sure that some testing happens. The problem is that the testing has proven ineffective at picking up problems with heavily-used cmdlets like New-MgGroupMember and Send-MgUserMail, both of which were obviously flawed in V2.26.

It’s hard to test PowerShell cmdlets. Your use of a cmdlet might not be the way I use a cmdlet (the flexibility of PowerShell can be its own worst enemy at times). One method might be to test each cmdlet using the examples in the documentation. This sounds feasible, but it’s not. First, not all cmdlets have documented examples. Second, when examples exist, the code invariably reflects the simplest use of the cmdlet. For instance, the Send-MgUserMail cmdlet would have passed a test in V2.26 in terms of being able to send a simple message; its problems were revealed with moderately complex HTML body parts and attachments.

Third, there are just too many cmdlets to test. For V2.26.1, the number is 39,878 cmdlets (11,445 production (V1.0) and 28,433 beta). The SDK spans 38 sub-modules for the production cmdlets and 43 for beta cmdlets. These numbers grow over time as new Graph APIs appear.

Remember that the Microsoft Graph PowerShell SDK cmdlets are created by the Autorest process, which reads the Graph API schema and metadata to discover the resources and methods used to access data. The result is a cmdlet for every API. Some cmdlets or their documentation are flawed due to errors in the Graph metadata.

The challenge is to improve the quality of SDK cmdlets and documentation by making sure that the foundation (metadata) is right, and the cmdlets work the way that they should for every release. Developers don’t like surprises, and they especially don’t like when code that works with one version fails in another.

The Need for Crystal Clear Communication about Microsoft Graph PowerShell SDK Problems

The engineering group for the Microsoft Graph PowerShell SDK needs to improve its communication dramatically. Apart from some brief release notes (probably not read by many people), the bomb that lay within V2.26 was not discussed. The bomb was the impact on Azure Automation runbook due to the retirement of support for .NET6 and .NET7.

The release notes for V2.26.1 are equally terse. It’s possible to understand that the SDK rolled back to support .NET6 to address the Azure Automation issue, but not even the full changelog adds much value for anyone who’s not a professional developer, familiar with the SDK structure, and knows how to manage GitHub repositories.

The thing that seems to be forgotten is that many Microsoft 365 tenant administrators use the Microsoft Graph PowerShell SDK. Usage of the SDK is going up due to the imminent retirement of the MSOL and Azure AD modules.

V2.25 of the Microsoft Graph PowerShell SDK clocked up 3.6 million downloads compared to 1.18 million for V2.24. These are higher download numbers than for the Exchange Online management, Teams, SharePoint Online, or Entra modules and should be enough to prove the popularity of the SDK.

Tenant administrators are not developers. Most will have a passing knowledge of GitHub, and few will be able to trace the development of a new version through a GitHub changelog. What’s needed is clear, concise, and explicit explanations of what has changed in a new version, what impact this might have on existing code (if any), and any steps a tenant administrator must take to ensure that their code will continue to work.

It’s not too much to ask for people who create code that’s used by millions of people to communicate clearly with their audience. The temptation to use GitHub to generate release notes from change logs might be overpowering, but it’s simply not good enough. Context is everything, and bald statements that such and such a component was updated to fix bug number 3133 is never going to be an example of good communication.

Learning from Coping with Many Microsoft Graph PowerShell SDK Problems

I hope Microsoft learns from the V2.26 fiasco. It was a debacle created from their own making due to perfectly avoidable circumstances. To their credit, the SDK developers scrambled quickly to fix problems and get V2.26.1 out the door, but that’s still no reason for inflicting so much heartache on what should be their most fervent admirers.

There’s no doubt that the Microsoft Graph PowerShell SDK is a great tool for Microsoft 365 automation, like creating SharePoint pages from an RSS feed (just one example). Being able to interact with multiple workloads through a single SDK makes the pain somewhat bearable, except when it happens frequently. Trust in the PowerShell SDK was degraded by the V2.26 experience. I hope we see progress to allow SDK fans to build that trust back again.

Need some assistance to write great 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.

Subscribers Can Download Files for Monthly Update #117 Now

The Office 365 for IT Pros author team is delighted to announce the availability of the March 2025 update for the Office 365 for IT Pros (2025 edition) eBook. This is monthly update #117. Readers can check the update number of the book on the inside front cover. Details of the update are available in our change log.

This update also includes update #9 for the Automating Microsoft 365 with PowerShell book, the most complete and comprehensive coverage of using PowerShell to create solutions based on Microsoft 365 data. Despite the recent quality problems for the Microsoft Graph PowerShell SDK, we still have strong faith in the usefulness of the PowerShell SDK and the ability it gives tenant administrators to access and use data across a wide range of workloads.

Subscribers can download the updated files from their Gumroad account or by using the download link in the receipt they received by email following their original purchase. The link in the receipt always accesses the latest files. See our FAQ for more information about how to download updates.

The Demise of Skype

The flux within the Microsoft ecosystem was dramatically illustrated by last Friday’s announcement that Microsoft will close down the Skype service on May 5, 2025. While the only impact on Microsoft 365 tenants will be the retirement of Skype interoperability with Teams (MC1019985, 28 February 2025), the demise of Skype is a sign of the ruthlessness that can happen when large corporations seek savings to invest elsewhere. Anything that doesn’t generate a good return is likely to be canned, which is what happened with Viva Goals late last year.

On a personal level, I don’t think I shall miss Skype too much. The app is installed on my PC and phone, but I don’t think I have made a Skype call in a year or more. Microsoft wants people to move to Teams personal (aka Teams for free), which I also have. However, I don’t use Teams personal for calling either because of the ubiquity of WhatsApp and the easy availability of low-cost data eSIMs around the world.

Some have pointed to the $8.5 billion price paid for Skype in 2011 and wondered if Microsoft got value for the purchase. I think that they did. The challenges of scaling up Teams to deal with the demand for online meetings when the pandemic happened were huge, and the experience of running the Skype backend was invaluable (according to Rish Tandon, who ran Teams engineering at the time). It can be argued that the pandemic made Teams and propelled its development to a point where it now supports 320 million monthly active users (the latest figure from October 2023). Without the success of Teams, would the Microsoft cloud now be at an annualized run rate of $163.6 billion? In that light, the investment in Skype seems like a rounding error.

Microsoft 365 Security for IT Pros

We are often asked about updates for the Microsoft 365 Security for IT Pros eBook. The facts are that we have nothing to do with this book. After sharing some of our processes and procedures to help the author team get up and running for the original edition in 2020, we have had no interaction with the book since. The latest edition appeared in 2023 and it seems like some difficulties have occurred in keeping the material updated.

We understand the book update challenge very well because publishing a monthly update takes a lot of time and effort. Muscle memory makes the task a little easier after 117 updates, but it’s still not as easy as some might think.

On to Update #118

Heading into March, we have started work on update #118. This will be the ninth update for Office 365 for IT Pros (2025 Edition), so it’s time to start thinking about the next edition. We typically publish a new edition on July 1 each year and I don’t anticipate any change to that cadence. But the writing team will get together at the Microsoft HQ in late March for the annual MVP summit and I am sure we’ll have a chat about the next version then. Stay tuned!

Stay updated with developments across the Microsoft 365 ecosystem by subscribing to the Office 365 for IT Pros eBook. We do the research to make sure that our readers understand the technology. The Office 365 book package includes the Automating Microsoft 365 with PowerShell eBook.

On Demand Classification Processes Cold Files to Find Sensitive or Confidential Information

Message center notification MC1013459 (21 February 2025) announces that Microsoft will introduce a new Information Protection service to find and classify “historical data in SharePoint Online and OneDrive for Business,” or as Microsoft 365 roadmap item 475062 says “scan cold files.”

The idea seems to be that tenants might have a bunch of files in SharePoint and OneDrive that have never been scanned or not been scanned in some time. Purview solutions like Data Loss Prevention (DLP) and Information Protection (sensitivity labels) tend to operate against active files created and edited by users. Cold files gather the digital equivalent of dust and might never be accessed, and it’s possible that those files contain many types of sensitive data.

Closing the gap by finding and classifying the information discovered in “cold files” is what the new On Demand Classification service is all about. By processing historical data, an organization can make sure that the files present in the tenant are classified appropriately. Once classified, policies can be automatically invoked to apply actions like assigning sensitivity or retention labels to files.

Preview of On Demand Classification in March 2025

Perhaps because trainable classifiers are an important method for tenants to find information that’s specific to their business, On Demand Classification is available through the classifiers section of the Purview DLP solution.

Microsoft expects to begin the deployment of a preview version of the code to targeted release tenants in late March 2025 with the goal of attaining general availability in mid-June 2025. Dates have been known to slip in the past, especially with new services, so treat these dates with caution.

Pay As You Go On Demand Classification

The On Demand Classification service is an example of the kind of new functionality that Microsoft bundles into its Office 365 E5 and Microsoft 365 E5 products to tempt customers to upgrade. That’s not the situation in this case. On Demand Classification is the first Purview Pay-as-you-go (PAYG) service.

PAYG is not unknown in Microsoft 365. SharePoint Online has PAYG services like Microsoft 365 Backup, Microsoft 365 Archive, and Document Translation, all of which require customers to have an Azure subscription attached to a valid credit card to pay for metered resource consumption. Other examples include the Graph API to apply sensitivity labels programmatically to Office documents and PDF files in SharePoint Online and OneDrive for Business and the export APIs for Teams and Exchange Online.

The case can be made that all the PAYG offerings are optional and not mainline services. They fill niches that not every Microsoft 365 customer wants or needs. It would be possible to include these services in the Microsoft 365 E5 product, but likely at an increased cost for everyone. Overall, it seems fairer for Microsoft to do the software engineering to create the solutions and realize a return by selling metered services to customers that need these capabilities.

No Details about Service Limitations

Microsoft hasn’t released any details about potential service limitations like the 100,000 items per day maximum an auto-label policy (sensitivity labels) can process within a tenant. We don’t know what kind of cold file types can be processed or if specific policy-invoked actions are restricted to certain types. The screenshot released by Microsoft (Figure 1) doesn’t give any insight into how long a scan might take or how long the subsequent processing might require.

All will be revealed when we get the software to test sometime in March 2025. Of course, some historic data must be found for On Demand Classification to process, but I’m sure that I have some old articles or book files hanging around that deserve to be heated up.

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.

Opens Access to UDP-Protected Files to Search, eDiscovery, and DLP – but not Copilot

Originally announced in preview in an August 1, 2023 technical community post, message center notification MC1013467 (21 February 2025) contains the good news that SharePoint Online will deploy support for sensitivity labels with user-defined permissions (UDP) in mid-March 2025. The reason why this development is important is that SharePoint Online support for UDP enables support for these files in content searches, Purview eDiscovery, and Purview Data Loss Prevention (DLP).

Configuring Permissions for Sensitivity Labels

Most sensitivity labels that protect files with rights-management based encryption use permissions configured by administrators. Permissions are formed by a set of usage rights that dictate what level of access an authenticated user has to a file. The same permissions apply to all files that receive a label with preconfigured access.

User-defined permissions allow file owners to assign different permissions for different files. To allow this to happen, administrators must configure a sensitivity label to support UDP (Figure 1).

After the label is published to make it available to users, they can assign the label and configure permissions for files (Figure 2). UDP labels are visible in Office web applications but can only be set by Office desktop applications.

Clicking more options reveals additional controls for a user to assign to protect a file, including an expiration date (which doesn’t pick up the date format configured for the workstation) for the permissions, a contact email address to request additional permissions, and whether a user must be online to validate their permission before they can open a file. The last option, to access content programmatically, allows Word and Excel to run code within a protected document.

Support for Microsoft Search

The initial SharePoint support for UDP-protected files previewed in August 2023 was limited. The big issue remained that files with UDP labels stored in SharePoint Online or OneDrive for Business couldn’t be indexed by Microsoft Search because Search had no way to gain access to file content (metadata for UDP-protected files is always indexed). This is important because Microsoft Search is an essential component for other services such as eDiscovery. In a nutshell, no indexing meant that UDP-protected files were invisible outside SharePoint Online.

The news announced in MC1013467 addresses the problem, but in a very focused manner. Although the number of UDP-protected files stored in SharePoint Online is likely a very small percentage of the billions of new files created daily, there’s no way that a trawl across all sites to find and process UDP-protected files could work in a practical sense.

To solve the problem, SharePoint Online processes newly-created UDP-protected files from mid-March 2025 to make their content accessible to Microsoft Search. Once indexed by Search, the file content is available to other Microsoft 365 workloads like eDiscovery. During the indexing process, SharePoint interprets the permissions assigned to a file by the author to ensure that those with relevant permissions can engage in co-authoring. In addition, SharePoint Online and the Office apps need permission to access the file before the autosave feature can work. It takes a little time to process a new file after it is uploaded to SharePoint Online. Microsoft reckons on ten minutes, but I have experienced longer delays before features like autosave work.

Older files stored in sites remain inaccessible to SharePoint Online until the next time they are edited. At this point, SharePoint processes the file content to make it searchable. Over time, the idea is that the number of inaccessible UDP-protected files will gradually decrease, and the problem will go away. Once a file is processed by Search, it becomes available to content searches, eDiscovery, and DLP.

Even when UDP-protected files are processed by Microsoft Search, MC1013467 says that “files with labels configured for user-defined permissions will continue to not be available for Microsoft 365 Copilot processing.” In other words, although Search can find UDP-protected files, Copilot still does not have the necessary permissions to load content from those files to use when generating responses to user prompts.

No Big Change for Users in the Immediate Future

From a user perspective, the update for how SharePoint Online processes UDP-protected files won’t mean dramatic change in the immediate future. UDP sensitivity labels might become more popular and widespread, but that’s a process that needs time because it must be factored in the organization’s information protection policy, which is probably currently based on preconfigured permissions. Administrators will need time to absorb the news and figure out how and if UDP-protected files bring value to the business before they create and publish UPD labels.

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.

No Microsoft 365 Archive Fee to Reactivate Sites After March 31, 2025

In a February 20, 2025 announcement, Microsoft said that they will remove reactivation fees for archived SharePoint Online sites. Some tenants will see the reduction in fees in early March and the change will roll out gradually worldwide for completion by the end of March 2025.

When Microsoft launched Microsoft 365 Archive, they charged $0.60 per GB to reactivate a site by moving its content from “cold” (long-term, archived) storage to “hot” (online, immediately-accessible) storage. Reactivation is immediate for sites archived within the last week, while sites archived for longer take approximately 24 hours to come back online.

Following the removal of the site reactivation fee, Microsoft will only charge the ongoing monthly storage cost of $0.05/GB. Storage fees don’t apply when they can be offset against the tenant’s unused SharePoint Online storage quota, so depending on how many sites they archive and how much content exists in those sites, some organizations might be able to use Microsoft 365 Archive for free.

A restriction does apply in that reactivated sites cannot be moved back into the archive for four months after reactivation. Microsoft says that the restriction is there to stop constant movement in and out of archive storage.

Keep Material Online but Prevent Copilot Access

One of the nice things about archiving sites is that it makes site content inaccessible for Microsoft 365 Copilot. There’s nothing worse than having AI-generated results being polluted by old, obsolete, and probably misleading information, and even if steps are taken to stop Copilot using content in its responses, Copilot can still find and use document library metadata because it exists in Microsoft Search.

I can’t think of a downside to moving old sites into the archive if you want to keep the material stored in the sites. Archived sites are still accessible for eDiscovery, the storage costs are a lot lower than hot online SharePoint storage, and now you can reactivate archived sites free when necessary.

Archived OneDrive Accounts

But you won’t be able to reactivate archived OneDrive for Business accounts free of charge because Microsoft excludes these objects from the removal of reactivation fees. The big idea behind automatically archiving unlicensed OneDrive for Business accounts is to force organizations to do something with accounts that might have been around for ten years or more. The unlicensed OneDrive accounts occupy valuable online storage and because Microsoft encourages the use of OneDrive for Business to hold all manner of files from Teams meeting recordings to PowerShell modules, a significant amount of storage can be occupied.

Microsoft released a report to help tenant administrators decide how to deal with unlicensed OneDrive for Business accounts in August 2024. By now, administrators should have a good handle on the unlicensed accounts within the tenant and know whether they will let automatic archiving happen (and be willing to pay the ongoing storage fees) or take action to remove the unlicensed accounts.

According to recently-revised Microsoft documentation, unlicensed accounts fall into two categories: those unlicensed before February 17, 2025, and those unlicensed afterward. The first batch includes all the historically unlicensed accounts. By April 25, 2025, these accounts will be in read-only mode to prepare them to move into the archive. This process will happen in the background and the unlicensed accounts will be archived by May 16, 2025, including the set shown in Figure 1. Once archived, tenants must pay to reactivate unlicensed OneDrive for Business accounts.

OneDrive for Business accounts that become unlicensed now are placed into read-only mode sixty days after they become unlicensed (for instance, the owning user account is deleted but the OneDrive data is kept by a retention policy, or the user account loses its license to allow them to use OneDrive for Business).

Thirty-three days afterward (93 days after the removal of the license), SharePoint Online will either move to the OneDrive account into the archive or into the recycle bin. Movement into the archive happens when a retention policy applies to the owner’s account.

Lower Fees are Always Appreciated

It’s good that Microsoft has removed the site reactivation fee. While not a lot in the overall scheme of things, getting rid of fees always encourage more use of facilities, and using Microsoft 365 Archive to store old material that the organization cannot remove is a good tactic. Some might question why the same logic doesn’t apply to archived OneDrive for Business accounts. That’s for Microsoft to answer, but I bet that they just want to get people used to the idea of paying to keep old OneDrive content online before they move on charges.

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.

Graph SDK V2.26 Issues Make the Software Unusable

The Microsoft Graph PowerShell SDK is becoming increasingly popular. With over 3.5 million downloads of the previous version, a new release was bound to be a major event., especially after a three-month delay since Microsoft released V2.25 on November 21, 2024 (the SDK usually follows a monthly release cadence). V2.26 duly arrived five days ago.

Alas, you should avoid and not install V2.26. The release is buggy, exhibits little evidence of being tested before launch, and creates huge operational problems for Azure Automation-based runbooks.

The Cracks Appear

I installed V2.26 soon after it appeared in the PowerShell Gallery. I have a large number of PowerShell scripts and runbooks based on the Microsoft Graph PowerShell SDK and it didn’t take long before cracks appeared. For example, HTML messages generated by the Send-MgUserMail cmdlet didn’t display property in multiple email clients, including Outlook classic, the new Outlook, OWA, and Proton (Figure 1).

Another issue was that the Send-MgUserMail cmdlet failed to process attachments. The script I published last week to show how to add and send multiple attachments with Outlook messages failed spectacularly. Many production scripts use Send-MgUserMail to generate and send HTML formatted messages, so this issue was a big problem for a new release.

To be fair to Microsoft, they quickly fixed the two Send-MgUserMail issues. However, these weren’t the only problems. For instance, the New-MgGroupMember cmdlet failed because of an “invalid URL format” generated by an odd value appended to the request URI created for the POST request to add a new group member.

As is my norm, I reported the issues as I encountered problems (anyone who finds a problem with the Microsoft Graph PowerShell SDK, can report the issue online). After a couple of hours, it was evident that V2.26 was in bad shape and practically unusable.

The Big Issue

Discovering several Priority 1 issues in a short period is bad enough; finding that V2.26 had dropped support for .NET6 and .NET7 without warning delivered the coup de grace. This news is a bullet point in the Microsoft Graph PowerShell SDK release notes, which is nice if you read that information and understand the full consequences of the removal. Microsoft delivered no context for the change and no commentary as to what might be the effect.

Issue #3151 was the first report that came in to advise that Azure Automation runbooks had stopped working with V2.26. As you might recall, before Microsoft Graph PowerShell SDK cmdlets can be used with Azure Automation, the modules containing the cmdlets must be loaded as resources into the automation account. You can then create runbooks based on a specific PowerShell version and use the cmdlets in those runbooks.

Azure Automation supports runbooks based on PowerShell V5.1, V7.1. and V7.2. Sometimes a module only supports V5.1 (the SharePoint Online management module is an example), but usually it’s recommended to use PowerShell 7. The problem introduced with the new version of the SDK is that PowerShell V7.1 and V7.2 don’t use .NET 8. Because the SDK dropped support for .NET6 (which reached end of support in November 2024) and .NET7 (which reached end of support in May 2024), Azure Automation and the Microsoft Graph PowerShell SDK are now at odds with each other.

To demonstrate, I created a new automation account and loaded the Microsoft.Graph.Authentication module into the account (Figure 2). This module is the foundation of the Microsoft Graph PowerShell SDK because all other modules have a dependency on it. Note that the runtime version is PowerShell 7.2.

Next, I created a very simple runbook to sign into the Graph using a managed identity (Figure 3). The only processing performed by the runbook is to sign in and report the authentication context.

When I ran the runbook, it failed because the runbook couldn’t load an assembly it needed to run the Connect-MgGraph cmdlet. This isn’t surprising because PowerShell 7.2 is looking for a file that it doesn’t support or isn’t available.

Stay with V2.25

You won’t have a problem if automation accounts keep on using V2.25. You will have problems if you upgrade automation accounts to use the V2.26 modules or create new automation accounts and load the V2.26 modules (which is what Azure Automation offers) as account resources. Some workarounds have been suggested, such as using the Azure Runtime Environment, but that’s a preview feature and I don’t recommend using it in production. You’re safer by leaving the V2.25 modules in place and not attempting to upgrade.

A Big Mess

It’s obvious that V2.26 of the Microsoft Graph PowerShell SDK is a big mess. It’s not the only fiasco in SDK history as previous problems were experienced in V2.14 and V2.17/V2.18 in 2024. It’s obvious that Microsoft didn’t test this release thoroughly before pushing it out the door. It’s also clear that Microsoft failed to appreciate or communicate the impact of removing support for .NET6 and .NET7 on Azure Automation. I don’t recall seeing a support article that clearly outlines how V2.26 affects Azure Automation that might convince customers to pause upgrading to V2.26.

Although the two .NET releases are retired, PowerShell in Azure Automation hasn’t moved on to support PowerShell V7.5. Perhaps that’s because the Azure Automation development team know that dropping support for PowerShell V7.1 and V7.2 might break many production runbooks. Still, that’s an internal issue for Microsoft to work out between the development groups. Customers shouldn’t have to experience the downside of the lack of coordination and planning that obviously exists within the world’s largest software company.

If you’re one of the 150,000 who downloaded V2.26 SDK, it’s time to bin it and revert to V2.25. At least that version works.

Update February 26: Microsoft has released V2.26.1 of the Microsoft Graph PowerShell SDK to fix some of the known bugs found in V2.26. I would not be in a rush to download and install this release until the situation around bugs and fixes clarifies.

Update: V2.26.1 has proven unreliable. Do not upgrade to this release.

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.

Free Downloads of Office 365 for IT Pros Pop Up Around the Internet

Ever since electronic copies of books have existed, people have posted illegal copies of books on websites across the internet. The copies are illegal because they infringe the copyright holder’s rights and are not paid for. In the past, publishers took most of the loss caused by unpaid copies. With the gradual spread of self-publication, which is what we do for the Office 365 for IT Pros and the Automating Microsoft 365 with PowerShell eBooks, the loss falls directly on authors.

Figure 1 shows a typical example of an illegal copy of the PDF for the 2023 edition available for download from a site called Dokumen.Pub, which is apparently based in Canada.

To some publishers, tolerating some illegal copies is part of the cost of doing business. To others, it’s an affront to the work done to create the content. We’re in the middle. We don’t have the time to expend a lot of effort searching for and attempting to remove illegal copies, but when we do, we like the administrators of the hosting sites to remove the illegal copies quickly.

Tracking Down Free Downloads of Office 365 for IT Pros

Most of the time, we are told about illegal copies. Occasionally, we search for illegal copies. Either way, when we find an illegal copy, we contact the site administrator and try to make a Digital Millennium Copyright Act (DMCA) notification to let the administrators know that infringing material exists on their site. Usually, sites make this process easy by providing an online form to allow a copyright holder to assert their ownership of content.

After that, it’s a matter of waiting. Some sites take copyright infringement very seriously. They respond within a day and take down the illegal copy without a quibble. In other cases, sites like Scribd.com refer the DMCA notification for review by an internal copyright abuse team, and the process takes much longer. It’s right and fair that complaints should be reviewed and dealt with fairly, but from our perspective, it seems like reviews could be completed faster. In any case, it is what it is. Figure 2 shows an illegal copy of the 2023 edition that was available for download on Scribd.com (now removed).

Just a word of warning: some download sites are vectors for malware. If you download files from these sites, you might receive more than you expect.

What Can Be Done About Illegal Downloads of Office 365 for IT Pros

The answer is precisely nothing. The internet has some dark corners where people do stuff that they shouldn’t. This is just a mild example. The best defense that we have is our monthly updates. Take the illegal PDF shown in Figure 2. The downloadable file is for update #86. The current version of the book is #116 and we are working on monthly update #117. A bunch of stuff has changed in Microsoft 365 over the last 30 months, none of which is covered in the illegal material. Another thing that’s noticeable is that none of the PDFs available online have the stamped email address of the original purchaser. This could be because the person who uploaded the file removed the stamped address, or it could be because Gumroad failed to stamp some PDFs in the past. As we noted last month, we believe that the issues with PDF stamping are now resolved. Whether the stamps will make any difference remains to be seen.

All we can do is ask anyone who’s considering uploading a PDF is to please reconsider and ask yourself why you propose to share intellectual material that doesn’t belong to you. It’s not like you help anyone. Some might learn something from outdated material, but the content will eventually age out or be taken down.

Keep Authors Interested

What those who upload book PDFs really do is remove the desire of the authors to continue working on a project. If our work is not respected and deemed essentially to be worth nothing, then we’ll stop producing our eBooks. If something is worthwhile, you should pay for it. And we think that there’s enough value in our books to justify a fair payment, especially considering our commitment to continually update the books to add new content, remove old material, and address any issues that people find.

We publish free information for all to learn from on this site and we share a bunch of PowerShell scripts in our GitHub repository to help people master PowerShell for Microsoft 365. But the site and the repository exist to support the books. If the book publishing project ceases, everything stops, and that would be a bad thing.

Don’t be a bad guy. Keep authors interested in generating great content by respecting copyright and intellectual property. Support us by subscribing to Office 365 for IT Pros and get two great books that are updated monthly! And if you come across any illegal downloads of Office 365 for IT Pros, please let us know (post a comment here), and we’ll take care of the paperwork.

Microsoft Clamps Down on EWSEnabled Tenant Setting to Enable Exchange Web Services

Exchange Web Services (EWS) is scheduled for retirement on October 1, 2026. Although October 2026 is still 19 months away, retiring an API that was heavily used at one time requires time and patience to expunge every trace of the API. Microsoft has already removed EWS from clients like Outlook for Mac and is working through the steps to remove EWS from its other applications.

Independent software developers have received clear directions that they should replace EWS with the Microsoft Graph. The acknowledged gaps in functionality that currently exist in the Microsoft Graph are being closed, with the latest example being the introduction of the Exchange mailbox import-export API (see MVP Glen Scales’ commentary on the new API).

Now Microsoft is preparing for the final removal by clamping down on the organization setting which controls whether EWS is enabled or disabled within a tenant. In a February 20, 2025 post, Microsoft says that the organization-level EWSEnabled flag will play a more significant role than it has done in the past. The change is being made to make it easier for Microsoft to disable EWS across Microsoft 365.

Enabling EWS for a Mailbox

In the past, it was sufficient for administrators to set the EWSEnabled flag for a mailbox to $true to allow the mailbox to use EWS in apps and clients. This condition existed because the mailbox setting has precedence over the setting in the Exchange Online organization configuration and, by default, the organization setting is null.

Get-OrganizationConfig | Select-Object EWSEnabled

EwsConfig
---------

The only time administrators set the organization-level EWSEnabled setting is if they wanted to block EWS throughout the tenant. Usually, this need didn’t arise because it was sufficient to set EWSEnabled to $true on the mailboxes that needed access to EWS. For instance, because EWSEnabled is $true for the James Ryan mailbox, that mailbox can use EWS even though the organization setting is null.

Get-CasMailbox -Identity James.Ryan | Select-Object EWSEnabled

EwsEnabled
----------
      True

The Big Change

What’s changing is that Exchange Online will only permit a mailbox to use EWS if both the organization and mailbox settings are $true. The old situation where the default null value at the organization level is sufficient to allow access is no longer in force. Tenants that want to use EWS to the bitter end must now explicitly enable EWS in the Exchange Online organization configuration:

Set-OrganizationConfig -EWSEnabled $true

You can see where Microsoft is going. By forcing the relatively small number of tenants to explicitly allow EWS by updating the organization configuration, Microsoft is preparing for the big turn-off when they will update the organization configuration to set EWSEnabled to $False and block any further changes to the setting. It’s an elegant and effective way of making sure that the turnoff happens on October 1, 2026.

Problems might arise for tenants that have the organization configuration set to $false already and still have a small number of mailboxes enabled for EWS. The precedence enjoyed by the mailbox setting allows these mailboxes to access EWS, but once Microsoft removes the precedence, those mailboxes will lose the ability to use EWS.

The solution is to update the organizational setting back to $true. It might seem counterintuitive to allow EWS for the tenant, but the existing access setting for mailboxes will then kick in and only those mailboxes enabled for EWS can continue making EWS API requests.

Check Mailboxes Enabled for EWS

Given that we’re on the final glidepath to the retirement of EWS, it’s a good idea to validate that the set of mailboxes enabled for EWS declines over time. That way you’ll know if the dependency on EWS within the organization is reducing and understand why some mailboxes continue to need EWS. To help, I put together an Azure automation runbook that looks for EWS-enabled mailboxes and emails the details using Exchange High Volume Email (HVE). The email (Figure 1) serves as a nagging reminder for tenant administrators to minimize the set of mailboxes enabled for EWS. Using Azure Automation means that it’s easy to schedule the job to run weekly (or whatever period makes sense) as the clock ticks down to October 1, 2026.

You can download the code from the Office 365 for IT Pros GitHub repository. See this article for more details about running Exchange Online PowerShell in Azure Automation, and this article about using HVE in Azure Automation.

I chose HVE rather than using the Send-MgUserMail cmdlet from the Microsoft Graph PowerShell SDK because there’s an odd bug that stops the latest version of Exchange Online PowerShell module working in version 7.2 runbooks. My Graph setup is based on PowerShell 7, so mixing and matching Exchange Online and the Graph SDK doesn’t work as smoothly as it should for now. Microsoft is aware of the issue. I believe it will be fixed in the next release.

You don’t need to use Azure Automation as a standard script will do the job too. It just seems to make sense to me to have Azure Automation run the job without human intervention. After all, I might forget to check…

I Can’t Wait for Agentic Experiences to Make Copilot Useful

We’re all on a journey to understand how to use artificial intelligence effectively to improve systems, lives, and human existence. If you pay for the necessary licenses, Copilot is everywhere within the Microsoft 365 ecosystem, both as helpers deployed in desktop apps like Word, Teams, and PowerPoint, and the possibility of custom agents for tenants to develop and deploy, albeit without the necessary tools to manage potentially thousands of agents created by citizen developers.

According to Microsoft CEO Satya Nadella, Microsoft wants to make it as simple for people to create agents than it is to create an Excel worksheet, which might mean the creation of the “highly customized agentic experiences” referred to in Microsoft 365 center notification MC985480 (January 22). I don’t quite know that phrase means, and the clarifying text that said it “means you can design unique prompts, connect to any LLM, and integrate these custom agents with Microsoft 365 Copilot” wasn’t much help either. When I asked Copilot, it struggled with the concept too (Figure 1). In any case, I’m sure that we’ll all be happy in our highly customized agentic world when it arrives.

Why Today’s AI Falls Short of its Hype

All of which brings me to a thoughtful article in the Tomorrow’s Blueprint blog entitled “Why Others Think AI Is a Miracle But You Think It’s Useless.” The author is Microsoft product manager Abram Jackson, now deeply involved in the development of Microsoft 365 Copilot. The core of the article is an assertion that:

“Today’s AI falls short of its hype for many due to three big reasons:

• It often doesn’t have the data it needs to work with
• Defining tasks precisely is very difficult
• There’s little AI can do other than give you text or images.”

Abram knows much more about AI than I do. I reckon that he has captured the problems faced by many organizations as they consider how to extract value from a potentially massive investment in Copilot licenses.

Without access to data, Copilot can do nothing. The magic of Microsoft 365 Copilot, if some exists, is the Microsoft Graph, or access to the documents, emails, and Teams messages stored within Microsoft 365. Yet the legacy of some older Microsoft decisions around collaboration strategy forced organizations to restrict SharePoint Search to stop Copilot revealing information to anyone who asked. As it turns out, it is hard to stop Copilot using data because even document metadata can reveal secrets.

I like the way Abram discusses the issue of defining tasks. Math works because the answer is either right or wrong. Copilot works very well when given well-defined tasks to do, like summarizing a meeting transcript or extracting tasks for people to consider. The same goes for scanning an email thread or summarizing a Word document. Generating text is less satisfactory unless the user is very precise in their prompt and grounds Copilot with some suitable input, like documents to work from. The promise of early demos where Copilot generated project reports and other material in the blink of an eye is never attained where loose prompting gives the AI free rein to indulge itself.

How People Need to Use AI

The summary is that to extract value from AI (and Microsoft 365 Copilot in particular), users must:

Understand if a task is valuable and not prone to hallucinations. Asking Copilot for Word to scan a document and decide if it is well-structured and how make improvements is valuable for many people who aren’t natural writers. Asking Copilot for Word to generate the initial document introduces the possibility of hallucinations.

Work to define the task precisely: Asking Copilot to do something very precisely with clear boundaries and guidelines will generate much better results than dashing off a quick prompt. Grounding a prompt with some relevant information, like several pertinent documents will always help Copilot to generate better information.

Translate the result generated by the AI into the form you need it to be. For chat, the introduction of Copilot pages has proven useful because it allows users to easily capture the output generated by Copilot for reuse. But will the slides generated by Copilot for PowerPoint be the type you need? Or can Copilot for Excel really perform the computations you want? Of course, they can, but only with practice and perseverance on the part of the human.

As Abram says, this approach “isn’t natural and it is time-consuming.” It comes about because Copilot is essentially an eager assistant that wants to work but will do stupid things unless you tell it precisely what to do and how to do it. Expanding on the example shown in Figure 1, adding context and direction to the prompt gives Copilot the chance to deliver a much better answer. Prompts can now be up to 128,000 characters, so there’s lots of room for comprehensive instructions.

The Bing Conundrum

One last point about data being available for Copilot to work with. I’m not sure about Abram’s statement that “hallucination is largely a solved problem for Microsoft Copilot.” I see odd stuff generated all the time. Abram justifies his claim by saying that “Copilot is trained to only respond with information it has been able to find through search.”

Copilot depends on Bing and Bing isn’t very good at searching. Take this website. Despite the ease in which Google has indexed and searched all my articles for years, Bing stubbornly refused to touch the site. I only discovered this fact when creating some declarative agents that used office365itpros.com as a source. Since then, the best efforts of WordPress support and my own attempts to navigate the online Bing webmaster advice have only just persuaded Bing to start indexing some pages. Some of the blocks are quite silly. One problem that caused Bing to refuse to index pages was the lack of an alt tag for a graphic in a sidebar.

If Copilot had better search facilities, it could generate better answers because it has better data to work with.

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.

When You Want to Add Attachments to Email

Many examples exist to show how to send a single attachment with an email using the Send-MgUserMail cmdlet from the Microsoft Graph PowerShell SDK. Microsoft’s documentation covers how to send a single attachment but is mute on how to process a batch of attachments. This is understandable because the need to send multiple attachments for a single message from PowerShell isn’t probably of huge importance when it comes to programmatically creating and sending email.

With that thought in mind, I set out to create some sample code to illustrate the principle behind adding multiple attachments to a message sent with the Send-MgUserMail cmdlet.

An Array of Attachments

The essential points to remember are:

• To include one or more attachments in a message, the attachment key must be present in the hash table that describes the message. The associated value is an array of attachments.
• Each attachment is represented by a hash table in the attachments array.
• The hash table for an attachment describes its odata type, file name, content type, and the base64-encoded content for the file.

Thus, the hash table for an attachment looks like this:

$AttachmentDetails = @{
        "@odata.type" = "#microsoft.graph.fileAttachment"
        Name = $File
        ContentType = $ContentType
        ContentBytes = $ConvertedContent
}

Adding Multiple Attachments

The first step is to find some files to attach. This code looks for files in a specified folder and checks the total file size to make sure that adding all the files as attachments won’t exceed 140 MB. The documented maximum message size for Exchange Online is 150 MB, but there’s always some overhead incurred from encoding, the message body, message properties, and so on.

$AttachmentsFolder = "c:\Temp\Attachments"
[array]$InputAttachments = Get-ChildItem -Path $AttachmentsFolder
If (!($InputAttachments)) {
    Write-Host "No attachments found in $AttachmentsFolder"
    Break
}   
$FileSizeThreshold = 146800640 # 140 MB in bytes
$TotalFileSize = ($InputAttachments | Measure-Object -Sum Length).Sum
$FoundSizeMB = [math]::Round($TotalFileSize / 1MB, 2)
If ($TotalFileSize -gt $FileSizeThreshold) {
    Write-Host ("Total size of attachments is {1} MB. Maximum size for an Outlook message is 140 MB. Please remove some attachments and try again." -f $TotalFileSize, $FoundSizeMB)
    Break
}

To prevent problems, the code won’t process the attachments if their total size is more than 140 MB and will report an error like this:

Total size of attachments is 182.14 MB. Maximum size for an Outlook message is 140 MB. Please remove some attachments and try again.

This avoids the problem when an attempt is made to send a message with oversized attachments, the Send-MgUserMail cmdlet will report:

Error sending message: [ErrorMessageSizeExceeded] : The message exceeds the maximum supported size., Cannot save changes made to an item to store.

The failure could occur because the mailbox that’s sending the message isn’t capable of handling such a large email. By default, Exchange Online enterprise mailboxes can send messages of up to 150 MB and receive messages of up to 125 MB (why the two values are different is debatable). To change these values for a mailbox, run the Set-Mailbox cmdlet:

Set-Mailbox -Identity Jane.Smith@office365itpros.com -MaxReceiveSize 150MB -MaxSendSize 150MB

Populating the Attachments Array

To populate the attachments array, the code creates a base64-encoded form of the file content and attempts to figure out the most appropriate content type. This is an optional property and Microsoft 365 can decide which format is best if you omit the property.

$FullFileName = $AttachmentsFolder + "\" + $File
$ConvertedContent = [Convert]::ToBase64String([IO.File]::ReadAllBytes($FullFileName))
$FileExtension = [System.IO.Path]::GetExtension($FullFileName) 
Switch ($FileExtension) {
    ".pdf" {
        $ContentType = "application/pdf"
    }
    ".docx" {
        $ContentType = "application/vnd.openxmlformats-officedocument.wordprocessingml.document"
    }
    ".xlsx" {
        $ContentType = "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
    }   
    ".pptx" {
        $ContentType = "application/vnd.openxmlformats-officedocument.presentationml.presentation"
    }   
    ".jpg" {
        $ContentType = "image/jpeg"
    }   
      ".png" {
       $ContentType = "image/png"
    }   
       default {
       $ContentType = "application/octet-stream"
    }
}

After processing an attachment, the code creates the hash table referred to earlier and adds it to the attachment array:

$MsgAttachments += $AttachmentDetails

The attachment array then becomes part of the message structure:

$Message = @{}
$Message.Add('subject', $MsgSubject)
$Message.Add('toRecipients', $MsgTo)
$Message.Add('body', $MsgBody)
$Message.Add('attachments', $MsgAttachments)

The final step is to call Send-MgUserMail to send the message. If everything works, it will arrive at its destination complete with a set of attachments (Figure 1).

Get the Structure Right and Everything Flows

Dealing with attachments through the Microsoft Graph PowerShell SDK is straightforward once you understand the structures used and how they are populated. It would be nice if the SDK cmdlet documentation covered this kind of thing better, but they don’t, so here we are.

You can download the script I used from the Office 365 for IT Pros GitHub repository. This article describes another example of using the Send-MgUserMail cmdlet.

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.

Updated EPUB and PDF Files Available for Download

The Automating Microsoft 365 with PowerShell eBook is now at update #9. This is the March 2025 update. We release monthly updates for the PowerShell eBook around the middle of the preceding month to allow us the time to concentrate on preparing the monthly update for Office 365 for IT Pros.

The updated EPUB and PDF files are available to:

• People who bought Automating Microsoft 365 with PowerShell on its own.
• Subscribers to the Office 365 for IT Pros (2025 edition) eBook.

Please use the download link in the receipt emailed after your purchase to access the updated files. Alternatively, you can get the updated files through your Gumroad.com account. The update number (and month) is shown at the bottom of each page.

Continual Expansion of Content

The original version of Automating Microsoft 365 with PowerShell spanned about 120 pages. The book is now 300 pages (more in the paperback edition because it includes an index). When we removed the PowerShell chapter from the Office 365 for IT Pros eBook, we always knew that there was much more to say about using PowerShell with Microsoft 365. Over the last eight updates, we’ve added a ton of examples, mostly covering the use of Microsoft Graph PowerShell SDK cmdlets with workloads like Entra ID, Exchange Online, SharePoint Online, and Teams.

Update #9 continues the trend with new content covering topics like using the Sites.Selected Graph permission to control access to SharePoint Online sites, how to upload files to SharePoint Online, sending multiple attachments with Exchange Online, and using an upload session to process very large attachments. There are many other changes, rewrites, and enhancements scattered across the book, including a complete rewrite of our coverage of using Microsoft 365 PowerShell with Azure Automation.

Price, Price, Price

To reflect the increased value of the content included in Automating Microsoft 365 with PowerShell, we’ve increased the price from $12.95 to $14.95. Other books covering the use of PowerShell with Microsoft 365 are priced significantly higher, so we think that even the new price represents incredible value. We’re confident that no other book covers the number and variety of fully-worked out examples of how to use PowerShell to get work done with Microsoft 365.

We also increased the price of the paperback edition to $19.95. This is simply a function of the increased page count driving the cost we pay Amazon to print each copy on an on-demand. There’s nothing to stop anyone printing off the PDF version if you want a paper copy. The only issue you’ll run into is that the many hyperlinks (over 200 at the last count) we include in the book become unusable when printed. To get around the issue, we substitute plain-text links in the content of the paperback edition.

Subscribers of Office 365 for IT Pros don’t have to pay any extra for their copies of Automating Microsoft 365 with PowerShell.

Onto Update #10

Work has already started on update #10. We’re waiting for Microsoft to release a new version of the Microsoft Graph PowerShell SDK. V2.25 has been around for about three months now, which is much longer than the usual monthly release cadence (Figure 1).

I don’t know why Microsoft has delayed the release of V2.26. It’s certainly not to deal with the problem related to plain-text passwords reported last week. No doubt we will hear in time. In the meanwhile, the interesting thing about the information shown in Figure 1 is the dramatic usage growth for the SDK from 1.18 million downloads of V2.24 to 3.49 million downloads for V2.25. That’s probably indicative of an uptick in interest as tenants work to get off the soon-to-retire MSOL and Azure AD modules. Maybe all those folks upgrading scripts to use the Graph SDK could do with a good book?

Event Alert Policies Retired from March 25, 2025 but Activity Alerts Stay

Publish bad news on Friday is the advice for anyone who wants the news to create less of a fuss. Publishing the news late on Friday before a holiday the following Monday (U.S. Presidents’ Day) might do an even better job of suppressing criticism. Some will consider the announcement in Message center notification MC1006620 (15 February 2025) that “Purview will retire the event alerts capability within the Purview Audit solution on March 24, 2025” to be bad news. It all depends on whether you use alerts based on audit events to learn when something happens in a tenant.

Activity Alerts Remain Unaffected

An earlier version of this article reported on the retirement of activity alerts. As it turns out, my reading of the situation was incorrect. All I can plead is that the wording of MC1006620 obscured the true intent, which is that Microsoft plans to remove the ability to create event alert policies from the Purview Audit solution because this capability duplicates what’s already available in the Data Loss Prevention solution. Alert policies remain unaffected by the change and it’s still possible to create and manage activity alerts in PowerShell even if Microsoft’s position is that “Activity alerts have been effectively replaced by alert policies.”

Microsoft introduced activity alerts and alert policies soon after the introduction of the unified audit log in July 2015. The idea is simple. The audit log holds some extraordinarily valuable information about what happens in a tenant, but a busy tenant can generate hundreds of thousands of audit events daily. Human administrators don’t have the time to keep on checking if events of interest (for whatever reason) show up in the audit log. Computers are very good at checking data, and activity alerts are predefined checks against new audit events as workloads ingest data into the audit log. If an event of interest is found, Purview sends email to administrators to tell them about the event (Figure 1).

Using the Get-ActivityAlert cmdlet to review the activity alerts configured in my tenant reveals that I haven’t done much with these alerts for some time. However, the descriptions give you an idea about the kind of operations activity alerts can monitor.

Get-ActivityAlert | Format-Table Description, WhenCreated

Description                                                         WhenCreated
-----------                                                         -----------
This alert fires when ATP for SharePoint detects malware in a file. 21/12/2017 18:29:50
When a group is deleted...                                          04/04/2018 18:39:25
Creation of a new Team                                              27/07/2019 16:07:12
Fire when a team is deleted                                         28/01/2020 11:02:09
Any modification of chapter 19                                      14/12/2016 14:41:28
An alert to monitor the Send As and Send on Behalf of actions       14/12/2016 14:41:31
Alert for add user events                                           17/10/2016 11:57:23
Checking for excessive downloads                                    30/05/2016 00:03:29
All document check in events                                        30/05/2016 00:03:29

Better Tools to Analyze Audit Events Exist

Although useful (and still in use), a case can be made that activity alerts have passed their sell-by-date. The unified audit log holds an increasing amount of data generated by workloads from Entra ID to SharePoint Online to Teams to Purview. Better tools exist to allow tenant administrators to monitor events of interest, including connecting Office 365 data to Microsoft Sentinel where the data can be analyzed along with information gleaned from other sources. Many organizations run background jobs to extract audit events from the unified audit log for ingestion into an external SIEM. There’s even a Splunk add-on to extract audit data for Microsoft 365. And if you want to involve AI, there’s Security Copilot to consider.

And if off-the-shelf software isn’t available, PowerShell can be used to extract and analyze audit events using either the Search-UnifiedAuditLog cmdlet or the AuditLogQuery Graph API. The signs are that Microsoft wants customers to use asynchronous Graph-based audit searches because these searches absorb fewer resources. Removing the monitoring of new audit events to be able to generate audit alerts seems to be another attempt to restrict the resources consumed by audit activity.

Using either the cmdlet or Graph query, the same kind of processing to find and email alerts for audit events of interest is easily done using a combination of PowerShell and scheduled Azure Automation jobs.

Confusion with DLP Alerts

Data Loss Prevention (DLP) policies can also signal alerts when policy rules detect violations. MC1006620 confuses the issue slightly by reassuring tenants that DLP alerts are unaffected by the retirement of audit-based activity alerts.

In any case, as noted above, a range of options exist to monitor audit events and signal alerts if something of interest is discovered.

Make sure that you’re not surprised about changes that appear inside Microsoft 365 applications by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers stay informed.

Graph SDK Plain Text Passwords are Unacceptable in Today’s Threat Climate

Many PowerShell developers are all too aware that time is running out for the Azure AD and MSOL modules. Microsoft will retire the MSOL module in April 2025 and the Azure AD module in Q3 2025. The result is that a lot of work is going on to upgrade scripts to replace MSOL and Azure AD cmdlets with equivalents from the Microsoft Graph PowerShell SDK or Entra module.

Microsoft launched the Entra module in June 2024 and made its V1.0 release generally available in January 2025. The Entra module is built on top of the Microsoft Graph PowerShell SDK. The major difference is that the Entra module comes with a set of hand-crafted cmdlets intended to mimic how Azure AD cmdlets work. I say hand-crafted because Microsoft engineers upgrade the automatically-generated versions created for the SDK to add support for features like piping.

The AutoRest process, which generates the SDK cmdlets, uses the metadata of the underlying Graph APIs to guide what it generates. That metadata is not constructed with PowerShell in mind, which is why the SDK cmdlets can be difficult to work with at times. For instance, the SDK cmdlets don’t support piping, which is a fundamental PowerShell feature. Output from SDK cmdlets is often a set of identifiers rather than human-understandable objects, and so on.

You could ask why Microsoft doesn’t intervene to add support for piping, make cmdlet output more useful, and address the other SDK foibles. One reason is the sheer number of Graph APIs that end up as SDK cmdlets.

[array]$Command = Get-Command -Module Microsoft.Graph*
$Command.count
42474

The 42,474 cmdlets are broken down into 15,259 V1.0 and 27,215 beta cmdlets. Updating all the cmdlets in V2.25 of the Microsoft Graph PowerShell SDK would take enormous effort. The number of cmdlets grows with each version of the SDK to reflect newly-added Graph APIs. The automatic generation process would need to change (and testing of the generated cmdlets). Whether the world’s largest software company should do this is an argument that’s been going on for years.

All of which brings me to issue 3119 reported in the SDK’s GitHub repository reported by MVP Aleksandar Nikolić, a well-known PowerShell expert. The problem report is terse and accurate:

The Update-MgUserPassword command’s parameters, -CurrentPassword and -NewPassword, expect a string value instead of a SecureString value.

Using Graph SDK Plain Text Passwords to Update User Accounts

The Update-MgUserPassword cmdlet is designed to allow users to change their own password. For instance, this code updates the user who’s signed into an SDK interactive session.

$User = Get-MgUser -UserId (Get-MgContext).Account

Update-MgUserPassword -UserId $User.Id -NewPassword "P@sswOrD" -CurrentPassword "Galway2020!!!"

If an administrator is changing someone’s password, they should use the Update-MgUser cmdlet.

$NewPasswordProfile = @{}
$NewPasswordProfile["Password"]= "$!FDGmso13@"

Update-MgUser -UserId $User.Id -PasswordProfile $NewPassword

Notice that in both cases, the password is in clear text. I don’t know how many tenants have coded solutions to allow users to change their own passwords and use the Update-MgUserPassword cmdlet, but I know that many have processes to change user passwords with Update-MgUser, so that’s the more serious problem.

By comparison, the equivalent cmdlets from the now-deprecated modules both take SecureString values when changing passwords.

$NewPassword | ConvertTo-SecureString -AsPlainText -Force
Set-MsolUserPassword -UserPrincipalName $userPrincipalName -NewPassword $NewPassword -ForceChangePassword $true
Set-AzureADUserPassword -ObjectId $User.Id" -Password $NewPassword

Using Secure Strings for Password Changes

Microsoft defines a SecureString as “text that should be kept confidential.” In terms of security, Microsoft says that A SecureString “provides more data protection than a string.” It seems like the right kind of protection passwords should have.

You might consider that there’s nothing much wrong here because the passwords are available to those who set them. However, it’s possible to have a script generate a password for an account and store it as a SecureString in a repository like Azure Key Vault, and have a different script read the password and use it to update an account. This method means that no password ever appears in plain text.

The Solution to Graph SDK Plain Text Passwords

The initial response from the SDK development team was that they follow the documentation for the underlying user: ChangePassword Graph API, which defines the input values in the request body strings. Referring back to the Graph API seems like a dereliction of duty. If everyone did that, we’d never see any improvements in software. Switching to support SecureString input for the SDK cmdlets is the right thing to do, even if it might break some existing scripts. That’s an acceptable cost to pay for better security.

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.

Custom Columns are One Part of the Mystery of SharePoint Search

Understanding how SharePoint Online search works is one of the learning curves faced by many Microsoft 365 tenant administrators. Because search is so important to SharePoint, this topic is well-covered ground for people who worked with SharePoint Server (on-premises). The magic that melds managed properties, crawled properties, mapping, custom cpolumns, indexes, and so on into search doesn’t hold any mysteries.

Things are different for those who come to SharePoint because of its core role within Microsoft 365. SharePoint Online is not the center of an ecosystem like SharePoint Server is. Like Exchange Online delivers email services, the cloud version of SharePoint takes on a completely different role as the provider of document management services to other workloads, like Teams. The different role doesn’t make search any less important. People still want to find files quickly and easily but competing demands from across Microsoft 365 mean that administrators sometimes pay less attention to the finer details of search. After all, search just works in the cloud…

Generally, SharePoint search does just work. Sometimes complexities do exist, like finding out how to find files with a specific sensitivity label. Although users mightn’t want to look for labelled files, administrators might need this knowledge to find labelled files in eDiscovery searches, and that’s why some knowledge about how search works is a good skill to acquire, even for non-SharePoint people. In my case, it helped me to maximize the advantage of creating a custom column for a site.

Creating a Custom Column

SharePoint Online is basically a big Azure SQL application based on a database holding many lists (tables). The lists hold data in items with the information for each item stored in columns (fields). SharePoint allows site administrators to define new custom columns at a site or library level. I use this feature to track the topic areas for articles I publish on different sites.

In general, defining custom columns at site level is recommended because the custom columns can then be used in any library. Figure 1 shows the properties of a custom site column called RAInfo.

After creating the site custom column, use the Add from existing site columns option in Library settings to add the column to a document library. Once the column is added to a library, it can be added to the view that exposes file metadata and edited there (or updated programmatically using a Graph API or SDK cmdlet).

Remaining in library settings, go to Indexed columns and add the new custom column as an index. SharePoint libraries support up to 20 indices.

Using Custom Columns

One of the nice things about custom columns is that SharePoint supports their use in filters. In Figure 2 we see that the filter picker shows the values entered for files in the RAInfo custom column. Selecting the desired values for the RAInfo column helps SharePoint to find and display files that meet the filter criteria. Of course, filtering only works if users remember to enter the necessary information for files.

Users can also input a custom column value (for instance, “RA001”) into the search box to search the library for matching files. Because the custom column is part of the document metadata, SharePoint search can use it to find files.

Making Custom Columns More Searchable

The search against document metadata finds matches against any property containing the value. A further step is required to allow searches against the custom column be more specific.

When you create a custom site column, SharePoint Online creates a managed property named using the form CustomColumnName + “OWSText.” In this case, the managed property is called “RAInfoOWSText.” SharePoint also creates a crawled property with the name OWS_Q_TEXT_CustomColumnName, or OWS_Q_TEXT_RAInfo in our case. The crawled property is what SharePoint search extracts from a site.

To allow search to use the managed property, it’s critical to map the managed property to the crawled property and wait for indexing to complete. Once indexing is complete, you can input RAInfoOWSText:RA001 into the search box. This command instructs SharePoint to search against the RAInfoOWSText managed property.

Not everyone will appreciate working with what seems to be odd column names. To solve the problem, go to Site Information, then View all site settings, and select the Search schema. You can now create an alias for the custom column, hopefully giving the column a name that makes more sense to regular users. In Figure 3, I’ve assigned RAInfo as the alias for the RAInforOWSText managed property.

Adding an alias to disguise some of the complexities of SharePoint search is a small but useful step to take. Now users can input search terms like RAInfo:RA003 (Figure 4) into the search box instead of RAInfoOWSText:RA003 and find the same information.

Take Your Time

One thing that you’ll discover when tweaking SharePoint search is that it takes hours and sometimes days for changes to become active in a site. Users need to populate values in the custom column and search needs to index those values, including respecting the changes that you might have made like adding an alias for a managed property. You can force the issue somewhat by requesting a reindex of the document library (in library advanced settings), but SharePoint Online can’t be rushed too much.

Take your time and everything will work in the end. At least, it did for me.

Update Multiple Entra ID Accounts in a Single Action

It’s perhaps a natural assumption that administrative consoles like the Entra admin center perform actions against singular objects. However, that’s not the case because the Entra admin center now boasts an upgraded edit menu which supports operations against multiple user accounts (Figure 1). As indicated by the admin center, the update is currently in preview.

The older bulk operations menu has options for bulk create, bulk invite, and bulk delete.

No Notification from Entra

The disappointing thing is that Microsoft 365 administrators might struggle to discover interesting news like this because the Entra development group don’t post notifications to the Microsoft 365 message center. Hearing about changes might depend on fortuitously seeing a message in a social media feed or reading an article like this. It’s odd that Entra doesn’t take advantage of posting notifications in the Microsoft 365 message center because Microsoft 365 is a significant workload for Entra ID that generates large amounts of revenue through premium licenses.

The only documentation for bulk Entra ID updates that I can find refer to the bulk operations menu and says “Bulk operations in the Microsoft Entra admin portal could time out and fail on large tenants. This limitation is a known issue due to scaling limitations.”

The recommended workaround is to use the Microsoft Graph PowerShell SDK. That’s certainly a good idea if you want to process large numbers of accounts. It takes a little while to master user account management with the Graph SDK, but once you understand the basic mechanism, everything clicks into place and scripting account management isn’t a challenge.

What You Can do to Update Multiple Entra ID Accounts

Using the options in the edit menu is easy. Select some accounts (which can be a mixture of member and guest accounts), and choose one of the supported actions to update multiple Entra ID accounts:

• Edit properties (Figure 2). Only certain properties can be edited.
• Add manager. Every account should have a manager
• Add sponsors. Account sponsorship is really intended for guest accounts. A flaw in the implementation means that the UI doesn’t reveal if the chosen accounts already have sponsors. There also doesn’t seem to be a way to cancel sponsor assignment if you decide not to select a sponsor. The perils of preview software…
• Add as members of a group.
• Add to administrative unit.
• Edit account status. This option changes the accountEnabled property for the selected accounts from Enabled to Disabled or vice versa.
• Revoke sessions with a forced sign-out. Affected user accounts must reauthenticate to reconnect.

As you might expect, any change made to a user account is captured in an individual audit record and is discoverable by searching the Entra ID audit log (Figure 3) or the unified audit log (after ingestion).

Update Multiple Entra ID Accounts is Goodness

The new edit menu option is an example of a change that’s surprising because it hasn’t appeared before now. Making changes to multiple accounts at one time is a great way to speed up administration. It avoids the need to use PowerShell to process one-off changes for small groups of users. However, I’d always use PowerShell for anything more complex because of the extra control it affords.

After all, the nice thing about PowerShell is that you get to choose how to implement functionality without waiting for Microsoft to add options to an admin center. Then again, good things come to those who wait…

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.

Enforcing Strong MFA Through Protected Actions Might Block Bad Actors

A January 25, 2025 blog about how attackers leverage the User.DeleteRestore.All Graph permission attracted my attention. The idea advanced is that if attackers can wreak havoc if they can secure the User.DeleteRestore.All permission. There’s no doubt that this assertion is correct. Attackers being able to permanently remove soft-deleted user accounts from the Entra ID recycle bin is enough to give any tenant administrator a severe headache.

Protected actions might offer some protection against attacker destruction. When I first covered this capability in May 2023, it was early days for the feature. Essentially, a protected action is associated with a conditional access policy through an authentication context so that any attempt to perform the protected access invokes the conditions set in the policy. For instance, the condition could be that the user must authenticate themselves with a strong phishing-resistant authentication method like a FIDO2 key or passkey.

The idea here is that the attacker might not be able to satisfy the authentication challenge with the required strong method and is therefore blocked from performing the protected action. That theory falls down if the attacker has gained sufficient control over the tenant to update conditional access policies (unless you block update access to conditional access policies with a protected action).

Creating a CA Policy for Protected Actions

Microsoft’s documentation for adding a protected action is straightforward. To add a protected action to guard against unexpected removal of soft-deleted user accounts, create a conditional access policy for Entra ID to invoke when a connection attempts to us an authentication context (basically, when something happens – like accessing a sensitive SharePoint Online site). The CA policy (Figure 1) is very simple and associates an authentication context with strong authentication. You could add other policy requirements to grant access to make it harder for attackers. For instance, require the use of a compliant device.

The magic comes when you link the authentication context with one or more permissions. The set of supported permissions for protected actions has grown over time and includes microsoft.directory/deletedItems/delete, the permission to permanently delete objects from Entra ID. Deleted user accounts normally remain in a soft-deleted state in the Entra ID recycle bin for 30 days following deletion. Soft-deleted means that the accounts are recoverable. However, if the account is removed from the recycle bin, it is hard-deleted and irrecoverable.

To link the authentication context, go to the Roles & admins section under Identity in the Entra admin center and select Protected actions. Find the authentication context to link, select the permission, and save (Figure 2).

You can’t link a protected action to multiple authentication contexts. If you make a mistake and link the protected action to the wrong authentication context, you must remove the protected action and add it to the correct authentication context.

Testing the Protected Action

To test the effectiveness of the protected action, you need an account that holds an administrative role that would normally allow the holder to permanently remove soft-deleted user accounts that doesn’t meet the requirements of the CA policy. I used an account holding the Global administrator role that used SMS to satisfy an MFA challenge. Entra ID doesn’t consider SMS to be an authentication strength that meets the criteria of passwordless MFA, so any attempt by this global administrator to remove a soft-deleted account fails (Figure 3).

The block also works if an attempt is made to remove an account using the Graph Permanently delete an item API or the Remove-MgDirectoryDeletedItem cmdlet from the Microsoft Graph PowerShell SDK.

Get-MgDirectoryDeletedItemAsUser | Format-Table Id, displayname

Id                                   DisplayName
--                                   -----------
63699f2f-a46a-4e99-a068-47a773f9af11 Annie Colonna
f13e62ff-b43c-44e7-a821-48db196b84d9 Cathy Lin
889bad5f-d7f7-4731-bf07-af2894f345b2 Joanne Crispa

Remove-MgDirectoryDeletedItem -DirectoryObjectId f13e62ff-b43c-44e7-a821-48db196b84d9

Remove-MgDirectoryDeletedItem_Delete: Operation requires conditional access and client does not support it. Client must be configured to support conditional access claims challenges to proceed.

Insisting on Stringent Conditions is Sometimes Good

Any organization that has deployed conditional access policies should consider using protected actions. The necessary policies are easy to implement, and it makes sense to insist on stringent conditions before destructive actions like permanent removal of user accounts are possible.

The only issue I encountered during testing was that Entra ID didn’t respect the disabling of the CA policy used for protected actions. No matter what, the policy remained in force until I removed the protected action. It’s possible that the underlying cause was a timing issue generated by multiple changes to settings over a short period and that everything would have worked more smoothly if I was more patient. In any case, the issue shouldn’t be a problem in practical terms because it’s highly unlikely that anyone will disable and enable a CA policy to turn protected actions off and on several times in quick succession, but it’s definitely something that the developers should investigate.

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.

Exchange Online PowerShell Assumes Administrators Run Its Cmdlets

My last primer article in the Azure Automation series covered how to send email using the Exchange Online High-Volume Email (HVE) facility. HVE is still in preview (Microsoft is targeting September 2025 for general availability) but it still does a nice job of sending email from scheduled automation jobs.

This article discusses how to create and execute Azure Automation Exchange runbooks using PowerShell cmdlets from the Exchange Online management module. Unlike HVE, which doesn’t require any Exchange cmdlets, Automation accounts that use the Exchange module in their jobs need some special configuration. This is because the Exchange module assumes that anyone running its cmdlets is an Exchange administrator. There’s no concept of least privilege implemented in the module: once a process loads the module, it can act like a human administrator.

Loading Exchange Online PowerShell into an Automation Account

At least, an app can be all-powerful for Exchange if it meets three conditions. First, it can load the Exchange Online management module. For Azure automation accounts, this means that module is loaded as a resource into the account (Figure 1).

At the time of writing, Exchange Online PowerShell only supports PowerShell V5.1 for automation runbooks, so be sure to install that version of the module. Due to module dependencies, you must install the PackageManagement and PowerShellGet modules (loaded jn that order) before installing the Exchange Online module.

Assigning Exchange Online Permissions and Roles for the Automation Account

Second, the service principal for the app must be assigned the Exchange administrator RBAC role. For Azure Automation, this means the service principal for the automation account. The assignment can be done through the Entra admin center (Figure 2) or with PowerShell. Make sure that you select the correct automation account from the set of enterprise applications listed in the picker.

Third, the app must be assigned the Exchange.ManageAsApp permission. This is not a Microsoft Graph permission. It is an Office 365 Exchange Online permission designed to allow apps to act as administrators. The assignment can only be made through PowerShell. Here’s how to do the job with the Microsoft Graph PowerShell SDK:

$ExoApp = Get-MgServicePrincipal -Filter "AppId eq '00000002-0000-0ff1-ce00-000000000000'"
$TargetSP = Get-MgServicePrincipal -filter "displayname eq 'M365Automation'"
$Role = $ExoApp.AppRoles | Where-Object {$_.DisplayName -eq "Manage Exchange As Application"}
$AppRoleAssignment = @{}
$AppRoleAssignment.Add("PrincipalId",$TargetSP.Id)
$AppRoleAssignment.Add("ResourceId",$ExoApp.Id)
$AppRoleAssignment.Add("AppRoleId",$Role.Id)

$RoleAssignment = New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $TargetSP.Id -BodyParameter $AppRoleAssignment
If ($RoleAssignment.AppRoleId) {
  Write-Host ("{0} permission granted to {1}" -f $Role.Value, $TargetSP.DisplayName)
}

Creating a Runbook to use Exchange Online Cmdlets

With the three prerequisites in place, you can create a runbook. To test that everything works as expected, create a V5.1 PowerShell runbook with the following code (replace the organization name with your tenant):

Connect-ExchangeOnline -ManagedIdentity -Organization Office365itpros.com
(Get-OrganizationConfig).DisplayName

Save the runbook and use the test pane to execute it. The output should be the display name for your organization. If that’s all you see, you can go ahead and build out the runbook with code to do more useful work.

As a demonstration, I took the script to report missing properties for user mailboxes and copied it into the runbook. The only changes that I made were:

• Remove the code that checks for an active connection to Exchange Online at the start of the script and replace it with the Connect-ExchangeOnline -ManagedIdentity command.
• Remove the Clear-Host cmdlet (Azure Automation doesn’t have a host to clear).
• Replace the Write-Host cmdlet with Write-Output (Azure Automation outputs everything together (a stream) at the end of a job).
• Remove the code to output the results as an CSV file at the end of the script.

Figure 3 shows the output of the runbook in the test pane. Everything works and we know that there are some mailboxes with missing properties that should be addressed.

Azure Automation can create an output file on the headless server where the runbook executes, but the question is then how to copy the file to somewhere more accessible later. The easy answer is to use HVE to send the file as an email attachment or to include the data in the body of a message. Something more complicated, like creating a file in a SharePoint Online site, will require more effort.

Not So Difficult

Running Exchange Online scripts in Azure Automation isn’t difficult once the initial setup for the automation account is in place. Some tweaking of the script code is probably necessary, but it’s not difficult to make the changes and will become second nature after a while. If you need to run jobs that process large numbers of Exchange objects (like mailboxes), Azure Automation is an excellent platform choice.

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.