Practical Exchange: Microsoft Update Affects How Wildcards Work with Dynamic Distribution Groups

Time to Check Recipient Filters for Dynamic Distribution Groups

Update (December 13, 2024): Microsoft has pushed the change out to early January 2025.

On October 16, Microsoft published message center notification MC912176 to explain a change to the way that Exchange Online processes the recipient filters for dynamic distribution groups (DDGs). Essentially, Microsoft says that recipient filters that use wildcard prefixes with the equal operator should never have worked because this functionality was not designed into how the server evaluates recipient filters. Microsoft will roll out an Exchange Online update on November 30 “to ensure the -eq operator in recipient filters is correctly honored.”

Microsoft also noted that they’ve already deployed a fix to prevent new DDGs from being created with invalid wildcard filters. In addition, if an administrator updates a DDG, the fix changes its recipient filter and stops it working. Microsoft didn’t say anything before they introduced the fix into production. Based on the comments for this article, the problem seems to have surfaced in August 2024.

Poor Communications Marred DDG Fix

It’s obviously a bad situation when a service provider rolls out a fix into production that stops customer functionality from working. The issue is compounded when the service provider leaves it to customers to discover the effect of their code change. In this case, the problem usually surfaced with recipient filters designed to find mail-enabled objects based on their email address, such as all mailboxes for an SMTP domain. Over the years, people have figured out that it’s possible to create a recipient filter against the WindowsLiveID mailbox property and use it with a wildcard prefix. For instance, here’s how it was possible to create a DDG with a recipient filter to find everyone with an office365itpros.com address:

$Filter = 'WindowsLiveID -eq "*office365itpros.com"'
New-DynamicDistributionGroup -Name "Office365ITPros users" -DisplayName "People with Office365itpros.com email address" -Alias O365.WindowsLiveID -PrimarySmtpAddress O365.WindowsLiveID@Office365itpros.com -RecipientFilter $Filter

Exchange Online no longer accepts this syntax and rejects it with:

New-DynamicDistributionGroup: Cannot process argument transformation on parameter 'RecipientFilter'. Cannot convert value "WindowsLiveID -eq "*office365itpros.com"" to type "System.String". Error: "The value "*office365itpros.com" could not be converted to type Microsoft.Exchange.Data.SmtpAddress. "WindowsLiveID -eq "*office365itpros.com"" at position 41."

When writing the original Practical365.com article on this topic last January, I discovered the inconsistent behavior of recipient filters with wildcard prefixes and reported the problem to Microsoft, who debugged the issue, found the root cause, and fixed it in August. Wildcard prefixes are not supported for any filterable property, but wildcard suffixes are.

Impact on DDGs after November 30

Although poor communication caused heartburn for customers affected by DDGs that suddenly stopped working after the August patch, Microsoft believed that a full-blown fix was needed to make sure that DDGs work as designed. That’s what will come on November 30.

After Microsoft deploys the update, any DDG that has a recipient filter which uses a prefix wildcard with the -eq operator like the example cited above will stop working. Tenants with DDGs that use this kind of recipient filter should have received a message center notification like MC912176 (because of all the testing I did to track down the problem, I had many instances).

Microsoft notes that the sudden non-functional nature of DDGs “may impact any processes that rely on this behavior.” They urge affected customers to explore “alternative methods” such as using a custom attribute to hold the domain name and creating a recipient filter that matches against the custom attribute. Full details about how to do this, including an example script, are described in the Practical365.com article referenced above.

Another alternative is to use a dynamic Microsoft 365 group. The membership rules for dynamic groups support a wide range of filtering options against account properties including wildcard prefix matches. However, unlike DDGs, dynamic groups require Entra ID P1 licenses for any account matched by the filter. This isn’t usually a problem in enterprise tenants that might have these licenses already. A more fundamental issue is that dynamic Microsoft 365 groups don’t support the same range of mail-enabled objects that DDGs do (like mail contacts, public folders, distribution lists, etc.).

Performance is the Likely Root Cause

You might ask the question if Entra ID can support the -eq operator against prefix wildcards, why can’t Exchange Online? I don’t know the precise details, but I suspect that the reason comes down to performance. DDGs don’t exist in Entra ID. They are Exchange objects and Exchange is responsible for evaluating recipient filters.

As a mail server, Exchange doesn’t want to slow mail transport by having to evaluate complicated recipient filters. Speeding up evaluation is why Microsoft introduced a background mechanism to evaluate DDG membership some years ago. Exchange also supports precanned filters to further optimize lookups. It could be that allowing wildcard matches against email addresses incurs a performance penalty that Exchange doesn’t want to take. By comparison, Entra ID supports different ways to evaluate membership rules for dynamic Microsoft 365 groups, so the performance implications for matching against email addresses might not be as heavy.

Time to Evaluate Your DDG Recipient Filters

The customer perspective of what’s happened is likely very different to Microsoft’s. From the engineering viewpoint, an inconsistency was reported, they tracked down the problem and fixed it to make DDGs work as designed. All is well unless you depend on using a DDG with a now-prohibited recipient filter, in which case you have some work to do before the axe descends in early January 2025 (extended from the early November 30, 2024 date). Isn’t Information Technology a great area to work in?