Table of Contents
EX1015484 Issue Causes Duplicate Exchange Online Mail User Objects Linked to Entra ID Guest Accounts
I am indebted to MVP Joe Stocker for sharing information about incident EX1015484 (duration from February 20 7:38AM PST to February 27 5AM PST). The problem as reported by Microsoft (Figure 1) is that when administrators create new Entra ID guest accounts, duplicate objects appear in Exchange Online that prevent email delivery to the guest accounts.

Creating Mail User Objects
Entra ID and Exchange Online use a dual-write mechanism to update objects. Guest accounts originate when external users are added to Teams or Microsoft 365 groups, or when an administrator invites an external user to join the tenant from the Entra admin center.
When Entra ID creates a new guest user account, Exchange Online creates a mail user object. The existence of the mail user object allows guest users to be included in distribution lists. The mail user object has an email address, so email can be sent to the object, and the transport system is able to route messages to the guest account. Exchange Online removes a mail user object automatically following the removal of the guest user account from Entra ID. If the deleted Entra ID account is restored, the mail user object reappears.
Duplicated SMTP Addresses
In the case of EX1015484, it seems like Microsoft shipped a feature update with a bug that created mail user objects with duplicate SMTP email addresses. The Exchange transport system insists that email-enabled objects have unique email addresses because that’s the basis for routing messages to their final destinations.
Apparently, tenants need to contact Microsoft support to remove the duplicate objects. You can’t just remove duplicate mail user objects because of the dual-write mechanism. Entra ID is the directory of record, so any attempts to run Remove-MailUser to delete an object linked to a guest account will fail:
Remove-MailUser -Identity a9f35d52-572e-4438-a129-08d8c00ae88b Confirm Are you sure you want to perform this action? Removing the mail enabled user Identity:"a9f35d52-572e-4438-a129-08d8c00ae88b" will delete the mail enabled user and the associated Windows Live ID "elifon_contoso.com#EXT#office365itpros.onmicrosoft.com". [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y Remove-MailUser: ||An Azure Active Directory call was made to keep object in sync between Azure Active Directory and Exchange Online. However, it failed. Detailed error message: Resource 'a9f35d52-572e-4438-a129-08d8c00ae88b' does not exist or one of its queried reference-property objects are not present. DualWrite (Graph) RequestId: 61220f4c-90ea-4fa5-bf1f-c07b5d10c26d The issue may be transient and please retry a couple of minutes later. If issue persists, please see exception members for more information.
Removing the guest accounts from Entra ID and restoring them after a few minutes might well work. I can’t say because the problem didn’t affect any tenant that I have access to.
In any case, Joe posted some PowerShell to find mail-enabled objects with duplicate SMTP addresses:
Connect-ExchangeOnline; Get-Recipient -ResultSize unlimited | Select-Object -ExpandProperty EmailAddresses | Where-Object {$_ -like "smtp:*"} | Group-Object -Property {$_.ToString().ToLower()} | Where-Object {$_.Count -gt 1} | Select-Object @{Name="SMTPAddress";Expression={$_.Name.Substring(5)}}, Count | Sort-Object -Property Count -Descending
The code is faster when a filter is applied to select mail user objects. Here’s my version (updated for Exchange Online Management PowerShell module V3.7.2; if you run V3.7.1, filter against MailUser objects)
Connect-ExchangeOnline; Get-ExoRecipient -RecipientTypeDetails GuestMailUser -ResultSize unlimited | Select-Object -ExpandProperty EmailAddresses | Where-Object {$_ -like "smtp:*"} | Group-Object -Property {$_.ToString().ToLower()} | Where-Object {$_.Count -gt 1} | Select-Object @{Name="SMTPAddress";Expression={$_.Name.Substring(5)}}, Count | Sort-Object -Property Count -Descending
I tested the amended code by removing the check for addresses with a count greater than 1, so I am pretty sure that it works. Feel free to improve the code!
Problems Happen
It’s regrettable that EX1015484 happens, but that’s the nature of software. The issue has been resolved, and you will no longer encounter mail user objects with duplicate SMTP addresses in your tenant. It’s worth running the code shown above just in case that the problem hit your tenant and left some bad objects behind.
So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across the Microsoft 365 ecosystem. Subscribe to the Office 365 for IT Pros eBook to receive monthly insights into what happens, why it happens, and what new features and capabilities mean for your tenant.
Hi Tony – thanks for this… I saw that incident in our tenant but hadn’t gone as far as assessing impact yet.
re: your version of Joe’s PowerShell code – I’m not sure your added filter is picking up guest mail users. Should it be one of the following?
-RecipientType MailUser (which would cover both guest and “regular” mail users)
or
-RecipientTypeDetails GuestMailUser
All of the guest mail user objects in my tenant had:
RecipientType : MailUser
RecipientTypeDetails : MailUser
And that’s why I used that filter. The GuestMailUser recipient type (details) was definitely available in the past, so I updated the EXO module from 3.7.1 to 3.7.2 and it came back! So -RecipientTypeDetails GuestMailUser will work (most efficient), but RecipientTypeDetails = MailUser also works. Odd!
Could you try both filters in your tenant and tell mw if the guest mail user objects are returned by both? (with 3.7.2, of course)
Using 3.7.2 (note that I’m having an issue with the REST-based cmdlets at the moment* so, I had to fallback to the older cmdlet – Get-Recipient):
-RecipientType MailUser – returns both guest and “normal” mail users
-RecipientTypeDetails MailUser – returns only “normal” mail users
-RecipientTypeDetails GuestMailUser – returns only guest mail users
*after a while, the Get-EXO… cmdlets return an error: “The underlying connection was closed: An unexpected error occurred on a receive.” – I’ll be opening a ticket with Microsoft shortly.
Interesting. The REST cmdlets are working for me:
$X = Get-ExoRecipient -RecipientTypeDetails MailUser
$X.count
120
$X = Get-ExoRecipient -RecipientTypeDetails GuestMailUser
$X.count
88
And if you run:
$X = Get-ExoRecipient -RecipientType MailUser
$X.count
do you get 208 or 120?
(I’ve got a several orders of magnitude more recipients in my tenant so my problems with the REST cmdlets may stem from that)
208. The sum of both RecipientTypeDetails.
You’re right that running cmdlets against larger data sets could expose problems (like pagination). I could create a bunch of mail user objects but who has time for that on a Friday evening…
Does that mean the code posted in the article:
Get-ExoRecipient -RecipientTypeDetails MailUser -ResultSize unlimited
Would only be checking your 120 “non-guest” mail users?
I’ve updated the text.