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:

Connect-ExchangeOnline; 
Get-ExoRecipient -RecipientTypeDetails MailUser -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.

Block ChatGPT Access to OneDrive 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 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).

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

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.

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.

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 licensed through SharePoint Advanced Management (SAM). All tenants with Microsoft 365 Copilot licenses are due to receive SAM licenses. I haven’t seen SAM appear in my tenant yet, but not doubt its deployment 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 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.

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

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.

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.

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.

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.

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.