New Way to Run DLP Diagnostics Through GUI Instead of PowerShell

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

Four DLP Diagnostics

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

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

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

Testing the DLP Diagnostics

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

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

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

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

The Value of Data Loss Prevention

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

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

Monthly Fee for Guest Accounts That Use ID Governance Features

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

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

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

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

DIY Inactive Guest Reviews

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

Coding a Report of Likely Costs

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

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

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

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

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

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

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

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

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

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

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

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

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

No Great Insight from Azure Billing

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

Learn more about how the Microsoft 365 applications really work on an ongoing basis by subscribing to the Office 365 for IT Pros eBook. Our monthly updates keep subscribers informed about what’s important across the Office 365 ecosystem.

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

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

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

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

Dropping OWA

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

Updating S/MIME Settings

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

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

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

Set-SMIMEConfig -NoSignOnReply $false

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

Sites that Duplicate Message Center Notifications are Useless

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

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

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

Removing Members from Groups Can be Complicated

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

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

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

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

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

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

Why Things are More Complicated with Microsoft 365 Groups

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

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

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

Code to Remove Members from Microsoft 365 Groups

The logic for removing a group member is therefore:

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

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

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

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

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

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

Removing Members from Groups Requires Knowledge

The question about removing group memberships is a great example of why it’s important to understand the technology and how Microsoft 365 really works before attempting to automate operations. Many blogs give partial answers. Without knowledge, you can’t fill in the gaps to create a complete answer, which is why we have the Office 365 for IT Pros eBook including the companion Automating Microsoft 365 PowerShell eBook.

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

Better Use of Number Matching and a Refined First Run Experience

The developers of the Microsoft Authenticator app have certainly been busy recently. Following on their announcement that a September 2025 update will make backup and restore easier, we now have the news released in message center notification MC1117816 (18 July 2025) that an update around the same time to simplify the sign-in experience and improve onboarding for users.

Modified Number Matching

In 2022, Microsoft added number matching to the Microsoft Authenticator app to reduce “MFA fatigue,” a symptom that can happen when users are asked to approve a stream of multifactor authentication challenges and can do so with a simple click. If a user responds with a series of clicks (without too much thinking), it makes it easier for an attacker to slip a bad challenge into the stream. Displaying a number and asking the user to match the number from a set of choices forces the user to pay attention. If they don’t, they probably won’t satisfy the challenge. Number matching became generally available in May 2023.

Good as number matching is at seizing user attention, it can sometimes run into difficulties. The most obvious is when Authenticator responds to a sign-in request for an app running on the app. The notification that a response is necessary can appear over the sign-in screen, meaning that the user can’t see the number they need to enter to satisfy the response.

To solve the problem, Microsoft is replacing the number choice with a simple yes or no. The experience is seamless on Android because all apps will pick up the new mechanism. On iOS, users of the Single Sign On (SSO) plug-in will still need to switch to the Authenticator app to complete the sign-in, but number matching won’t be required.

Users signing in from another device will still use number matching to satisfy the multifactor authentication challenge.

I have not seen the change in action, but I am familiar with the issue that Microsoft is attempting to solve. Indeed, so many notifications can pop-up on a busy device that tracking down authentication requests can be challenging. Anything that’s done to smoothen the user experience will be welcome.

Improving the First-Run Experience (FRX)

Microsoft is also making changes to the initial setup of the Authenticator app to give Entra ID accounts priority over personal accounts. I think this makes sense. The more that can be done to make multifactor authentication seamless for Entra ID users, the better the chances of driving the adoption of multifactor authentication in Microsoft 365 tenants. Attackers still target vulnerable accounts with techniques like password sprays.

According to Microsoft, 99.9% of compromised Entra ID accounts don’t use multifactor authentication. That figure should be sobering enough for any tenant administrator to take immediate action to improve their security stance by insisting that all user accounts are protected with multifactor authentication.

And if the Microsoft Authenticator app is easier for people to use, the resistance to moving from more traditional methods of satisfying challenges, like SMS, will be reduced. Some nagging is likely still needed (here’s a script to help) to convince tenant users to adopt strong multifactor authentication methods, but anything to remove barriers is a good idea.

Microsoft also says that they plan to make the option to scan a QR code more obvious. Again, this is goodness because many sites use QR codes as part of the multifactor authentication enrolment process.

Not Big Changes

Neither of the changes described here are in the category of earthshattering updates. Instead, the changes refine how the Microsoft Authenticator app works to make it easier for the average person to use. That’s a good thing, and I look forward to seeing the changes appear in September 2025.

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

Six Months of an Extended Security Update Program from October 2025 to April 2026

Those who aren’t dedicated followers of the EHLO blog might have missed two interesting posts this week. The first covers delicensing resiliency for Exchange Online and the news that Microsoft is reducing the threshold for this feature to 5,000 tenant mailboxes. I think the feature should be available to all Exchange Online tenants, but let’s leave that debate aside.

Coping with the consequences of a mailbox becoming delicensed isn’t such an issue for Exchange on-premises organizations. They have their own challenge, notably the need to upgrade to Exchange Server Subscription Edition (SE) before Exchange 2016 and Exchange 2019 exit support on October 14, 2025.

Updating a Server to Exchange Server SE is Boringly Easy

The second EHLO post of the week offers a lifeline to organizations who don’t believe that they can deploy Exchange Server SE by the October 2025 deadline. Performing an in-place server upgrade to Exchange Server SE is the easiest Exchange upgrade an on-premises administrator is likely to ever know. It’s been described as “boring” because literally nothing happens apart from version numbers being updated and a few other minor tweaks. The fact that Exchange 2019 and SE share the same documentation for system requirements testifies to the closeness of the two products.

Microsoft designed the upgrade to the first iteration of Exchange Server SE to be boring to remove the barrier where administrators believe that an Exchange upgrade is a major event with many potential problems lurking under the surface waiting to make a server inoperative. Read the documentation, follow the steps laid down, and your update will proceed smoothly.

Factors Stopping Upgrades Happening

Although the server upgrade is easy, there’s usually some other factors that come into play that can slow deployment. Now is peak vacation period so people might not be available. The organization might decide to introduce new hardware or roll out Windows Server 2025. This might be especially so when the organization runs Exchange 2016 on an older version of Windows Server (here’s the operating systems matrix). In any case, lots of preliminary steps might need to be resolved before anyone sits down to update a server.

To help organizations that are struggling to get their ducks in a row to allow the deployment of Exchange Server SE to proceed, Microsoft is therefore introducing a six-month Extended Security Update program. The idea is simple: After August 1, 2025, customers can contact their Microsoft account team to request a subscription to a new product SKU that entitles them to receive security updates for Exchange 2016 and Exchange 2019 for six months. The price of the SKU is per-server, and it’s assumed that the Microsoft account team knows how many servers a customer operates so that they can calculate an initial price before any discounts are negotiated. If you don’t have a Microsoft account team, call the local Microsoft office and get them involved.

There are several important points to consider before proceeding to enrol in the Extended Security Program:

• The agreement only lasts six months and Microsoft doesn’t plan to extend it past April 14, 2026.
• During the agreement, Microsoft will deliver security updates for problems that the Microsoft Security Response Center deems to be critical or important. In other words, a security issue must meet a threshold before Microsoft will create a security update for Exchange 2016/2019.
• Security updates issued through the program will be released privately to program participants. You won’t be able to download the updates from the Microsoft download center.
• There’s no guarantee that any security problems will emerge between October 15, 2025, and April 14, 2026. In other words, this is insurance in case a problem happens, and no refunds are coming if the security landscape remains calm throughout the six-month program lifetime.
• Microsoft says that they will inform program participants if a security update is available on Patch Tuesdays during the covered period.
• The Extended Security Update Program does not affect the end-of-lifetime support dates for Exchange 2016 and Exchange 2019. Those dates remain as they are. This program only covers security issues.

Not a Revenue Generating Opportunity

Cynics will say that this is yet another example of Microsoft adjusting deadlines, this time to create an opportunity for a little extra revenue by charging customers for six months of security insurance. Pragmatists will recognize just how slow Exchange Server updates have been since Exchange 2000 appeared. Given the engineering costs involved, I doubt Microsoft will make much if anything from the Extended Security Update program. This is no more and no less than a lifeline for those who need that extra time.

Your support pays for the time we need to track, analyze, and document the changing world of Microsoft 365 and Office 365. Only humans contribute to our work, which includes topics like Exchange Server SE that are important to hybrid Microsoft 365 deployments.

Copilot Studio Agent Sends Salesforce Customer Data to Attacker

The July 7 report (“A Copilot Studio Story 2: When AIjacking Leads to Full Data Exfiltration“) from Zenity Labs is sobering reading for anyone considering how to introduce Copilot agents within a Microsoft 365 tenant. In a nutshell, Zenity created a replica of a “flagship example” of an agent created using Copilot Studio built by McKinsey & Co and proved that a an email containing a prompt injection sent to the agent could result in the generation of an emailed response containing customer data sent back to an attacker.

I have an instinctive suspicious of reports issued by security researchers because there are too many examples of overhyped text designed purely to enhance the credentials of the company. In this instance, the Microsoft Security Response Center took the issue seriously, so we should too.

The Problem is Still There

We’ve been down this path before with Copilot because researchers reported how they had compromised BizChat at sessions at the Black Hat USA conference in 2024. Copilot agents didn’t exist at the time, but the same method of sending a message for Copilot to process that convinced Copilot to do bad things was used.

Zenity reported the exploit described in the article to Microsoft, who fixed the problem in late April 2025, most likely through the deployment of a “prompt shielding mechanism.” The net result is that attackers cannot use the same avenue to exfiltrate large quantities of data. However, the kicker is that the fix works for the attack as described, but as Zenity says “Unfortunately because of the natural language nature of prompt injections blocking them using classifiers or any kind of blacklisting isn’t enough.” In other words, attackers can find new ways to use natural language prompts to convince agents to do silly things.

The Stupidity of Agents

The problem is, despite all the hype around artificial intelligence, Copilot agents are essentially stupid. They cannot distinguish between good and bad users, nor can they decide that an action demanded of them is wrong or inappropriate. As we head into an era where agents can talk to agents, the need for increased oversight about what agents do and how they do it is all too apparent.

Managing agent objects in Entra ID is a good way to incorporate agents within the infrastructure, but that doesn’t do anything to reveal what agents do in response to different user prompts, including prompts deliberately intended to do harm. You could pour over the details of Copilot interactions captured by the aiInteractionHistory API or the compliance records captured in user mailboxes by the Microsoft 365 substrate searching for evidence of attacker intervention, but what would you look for? Searching for the one API record where 500 Salesforce customer records are sent to an address in Russia might be the equivalent of seeking the proverbial needle in a haystack.

Although ISVs can work on the problem of agent governance, it’s obvious that ISVs can only work with agents using the APIs and data made available by Microsoft. Dealing with prompt injections is something that will remain a Microsoft competence.

As AI tools become more embedded into our work, the more attackers will be interested in seeking gaps. The battle between Microsoft and the bad guys to protect Copilot (apps and agents) is likely to be a ping-pong contest of exploit followed by remediation

The Goodness of Copilot Studio Agents

Don’t get me wrong. I like the ease of use that Copilot Studio brings to the agent creation process. Even an old duffer like me can create and publish an agent from Copilot Studio (Figure 1). We’re simply at the point in the evolution of AI tooling where security, governance, and management struggle to keep up with the pace of innovation and overhyped expectations.

It would be an overreaction to block users from being able to develop agents with Copilot Studio. Some controls are necessary and restricting those who develop agents to a limited group with oversight before publication seems like a reasonable step. I’m sure that more comprehensive development methodologies and structures will emerge over time and will be discussed on the web and at conferences. I’m looking forward to hearing what the experts say at the TEC event in Minneapolis at the end of September. Come along and join the debate!

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

New Version Released on July 9

On July 9, 2025, Microsoft released V2.29 of the Microsoft Graph PowerShell SDK to the PowerShell Gallery (Figure 1). The release notes are available but don’t really throw much light into what’s been updated and the set of issues registered in GitHub for the SDK hasn’t gone down, so it’s hard to know exactly what changes Microsoft has made in V2.29. The only way to check is to install V2.29 and run some cmdlets, which is what I did. I used the script described in this article to refresh my PC and picked up recent updates for SharePoint Online and Teams along with the SDK.

Azure AD PowerShell Finally Going Away

Microsoft recently set the final (no, it won’t be shifted again) retirement date for the Azure AD and Azure AD Preview modules. The underlying infrastructure powering these modules will be turned off in mid-October 2025. It’s not like the slow withdrawal of the MSOL module where some cmdlets (license management) stopped working and others limped on until the module’s retirement in March 2025. Once the shutters come down in mid-October, the Azure AD cmdlets stop working and scripts fail. It’s time to migrate code to use the Microsoft Graph PowerShell SDK, or if you insist, the Entra module (which is based on the SDK).

Testing Microsoft Graph PowerShell SDK V2.29

Migrating to an unstable platform is a bad idea, and the sad fact about the Microsoft Graph PowerShell SDK is that some recent versions have been unmitigated disasters. Released in May, V2.28 of the SDK fixed many problems. The good news is that the suite of commands that I use to test new SDK versions uncovered no problems in dealing with users, groups, sites, mailboxes, and other objects. The new version seems to be as stable as V2.28.

Given the size of the SDK and the number of cmdlets (44,555 spread across the V1.0 and beta modules according to the Get-Command cmdlet), there’s no way that the tests I do will reveal every potential problem in an SDK release. All I can say is that the code in the scripts that I use for testing work without a problem. You can download many of the scripts that I test with from the Office 365 for IT Pros GitHub repository.

Before committing to upgrading a production environment to V2.29, I suggest that you update a couple of workstations and test scripts there. If everything checks out, you can then proceed with a tenant-wide rollout.

Azure Automation Blues

When Microsoft released V2.28 of the SDK, they acknowledged a problem with PowerShell V7.2/V7.1 runtime support in Azure Automation. In a nutshell, it all comes down to the version of .NET supported by the SDK. Microsoft said that the problem would be resolved when Azure Automation supported the V7.4 PowerShell runtime. At the time, support was supposed to appear around June 15. That date was missed and when I checked today, only Azure Automation runbooks configured for the V5.1 runtime worked. V7.1 and V7.2 runbooks barf with an “Invalid JWT access token” error caused because the Connect-MgGraph cmdlet cannot run to authenticate the session.

Until you hear differently, stay with PowerShell V5.1 for your Azure Automation runbooks. Microsoft will eventually get all of the pieces that it owns and maintains into alignment. It’s just sad when obvious gaps appear between important Microsoft 365 automation components.

Still Positive

Despite the recent issues with the Microsoft Graph PowerShell SDK, I’m still very positive about the SDK. Sure, there’s a learning curve to master when coming from more traditional modules like Azure AD. Yes, the issues are maddening and Microsoft’s seeming inability to drive quality in an essential component is infuriating. But despite all that, the SDK allows you to get behind the scenes of Microsoft 365 in a PowerShell-friendly manner, and that’s what really counts.

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

Mail-Enabled Security Groups with Full Access to Shared Mailboxes Makes Access to Protected Messages Easier to Control

Microsoft Purview Message Encryption (previously Office 365 message encryption) or OME allows users to apply two pre-defined rights management-based templates called Do Not Forward and Encrypt Only to protect email. Messages sent to other Microsoft 365 tenants can be read inline by Outlook clients while recipients of messages sent to other email services can read the protected content through the OME portal. Protection extends to email attachments.

Unlike the sensitivity labels created for tenants, administrators cannot edit the settings of the OME templates. The same settings apply in all tenants where OME is configured. For instance, when Outlook clients open messages protected by the Do Not Forward template, the clients disable the Forward, Save As, and Print options and don’t allow the recipient to change the recipient list for a reply.

Improving Access to Protected Messages Delivered to Shared Mailboxes

Shared mailboxes are an important part of the Exchange Online messaging landscape. Since the introduction of Azure Information Protection in 2016, Microsoft has steadily improved the ability of users with access to shared mailboxes to process protected messages. A recent important enhancement is described in message center notification MC794814 (21 May 2024, Microsoft 365 roadmap item 385345), which reports that members of a mail-enabled security group with access to a shared mailbox can read and respond to protected messages.

The caveat is that members of the mail-enabled security group can only read protected messages generated after Microsoft deploys the feature to a tenant. Rollout completed in September 2024, so that shouldn’t be a problem now. Older protected email cannot be read because the “protected wrapper” around those messages doesn’t support access via a mail-enabled security group.

Figure 1 shows a message protected with the Do Not Forward template being read in Outlook (classic). In this case, my account is a member of a mail-enabled security group granted Full Access permission for the Complaints mailbox.

No Need for Direct User Assignment

The important point here is that direct user assignment to the shared mailbox with automapping enabled is no longer required. Direct assignment means that an administrator grants Full Access permission for the shared mailbox to a user account. Automapping is a process where Exchange Online adds a shared mailbox to a profile so that the Outlook (classic) client automatically opens the shared mailbox. This method still works, but now you have the option to use a mail-enabled security group to control shared mailbox membership instead.

Although the mail-enabled security group method works very nicely to allow users to open and read protected messages, remember that separate delegation is required to allow people to send email from the shared mailbox. This can be a Send As or Send on Behalf Of permission.

Why mention a feature launched last year when every Microsoft 365 tenant struggles to manage the ongoing flood of new product feature announcements? Well, the new method seems to have passed people by, so I thought it would be good to highlight it and give the mail-enabled security group approach a little boost. In addition, although MC794814 focused on the Do Not Forward and Encrypt Only templates, it seems like users granted access to a shared mailbox via a mail-enabled security group can read email protected by sensitivity labels too, if the rights assigned in those labels allow access.

Support in OWA and the New Outlook

OWA and the New Outlook are usually faster at deploying enhancements for protected messages. These clients work online and fetch the necessary authorization (use licenses) as required. Outlook (classic) can work offline, so getting the use licenses is more complicated.

OWA and the New Outlook also support the ability to work with protected messages when access is granted via a mail-enabled security group. Figure 2 shows OWA being used to read a protected message in a shared mailbox.

Microsoft Purview message encryption is available to all tenants with Office 365 E3 licenses and above. The Do Not Forward and Encrypt Only templates are very useful and the number of tenants using sensitivity labels grows all the time. Easier access to protected messages in shared mailboxes is welcome, even if it’s taken me far too long to acknowledge the update.

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

Create Audio Overviews for Word and PDF Files and Teams Transcripts

Message center notifications MC1061100 (updated 2 July 2025) and MC1060872 (updated 3 July 2025) both focus on audio overviews generated from documents (Word and PDFs) and Teams meetings (transcripts) stored in OneDrive for Business and Copilot Notebooks. This is yet another example of Microsoft applying AI to Microsoft 365 information. The question is whether having an audio review of a file is of real value or a demonstration of technology that might be used once and then forgotten.

This feature requires a Microsoft 365 Copilot license.

Generating an Audio Overview

The implementation is simple. The Copilot menu for a supported file type in the OneDrive for Business browser interface includes the Create an audio overview option (Figure 1).

Selecting the option causes Copilot to process the file. Logically, it seems like Copilot summarizes the file into a format similar to a Teams transcript and uploads the output to the Azure Audio Stack for transformation into an audio stream (users can save the summary as an .MP3 file in the Recordings folder of their OneDrive for Business account). For now, only English language audio overviews are available, and only files in English can be processed. Copilot politely refused to process documents that contained non-English text, even when the majority of the text was in English. On the other hand, Copilot had no problem processing files containing computer code, such as the PowerShell examples.

Given that Copilot can generate document summaries in different languages and the support for many languages in the Azure Audio Stack, it seems likely that support for other languages will come soon. I also expect to see UX provided to allow users to select other settings, such as the voices used for output (see below).

MC1060872 says that the OneDrive mobile app can generate audio overviews. I haven’t seen the mobile option appear yet.

Audio Overview Styles

The default style summarizes the key points in a document. If you prefer, you can switch the overview to a podcast style using the option in the […] menu. Essentially, the summary is a report of a document read by a single person. The podcast style usually generates a shorter audio stream that’s delivered by two “hosts” (a male voice and a female voice, both with neutral American accents). Figure 2 shows an overview being played with the transcript visible together with the option to switch style.

The audio overview option advises that generation could take a few minutes. I discovered that this is accurate and that overviews for even very large files were available in a couple of minutes. For example, I asked Copilot to generate an audio overview of the Word document for the latest Office 365 for IT Pros eBook. This is a large and complex file (28 MB, 1,250 pages, 22 chapters, and many figures and tables), so I thought it would be a good test. The audio overview was available in less than two minutes. You can download and listen to the summary and podcast versions using the links below to get an idea about the quality and type of output generated for an audio overview.

The DLP Block for Microsoft 365 Copilot

Interestingly, the DLP policy for Microsoft 365 Copilot blocks Copilot from generating audio overviews. I shouldn’t be surprised at this because the idea behind the policy is to stop Copilot from processing confidential files assigned specific sensitivity labels. As noted above, Copilot generates an audio overview using a transcript summary produced from a file. To create the summary, Copilot must be able to extract the file content but is blocked by the DLP policy.

When asked to create an audio overview from a protected file that comes within the scope of the DLP policy, Copilot chews on the problem for a few minutes before concluding that it can’t do anything and errors out (Figure 3). OneDrive must be refreshed before further files can be processed.

Although it’s good that the DLP policy for Microsoft 365 Copilot does its job, the poor user experience in the OneDrive for Business browser interface is evidence that the folks who created the audio overview option never considered that a policy might block Copilot access to a file. It would be much better if the UX displayed an immediate error message to say that Copilot cannot process a file instead of making the user wait for a few minutes before Copilot times out.

Are Audio Overviews Valuable?

I might not be the right target market for audio overviews. I suspect that this feature is directed towards people who can’t use regular Copilot document summaries. In this context, I think audio overviews will be very useful. Another scenario where the feature might shine is the ability to save audio overviews of files to OneDrive for listening to during commutes or other journeys. Like all the AI-driven features, the value comes down to the individual. I’m not sure I will ever use a Copilot-generated audio overview again, but I know how to create one if I need it.

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