Dynamic Group Membership is the Obvious But Not the Only Option

A member of the Microsoft Technical Community asks if it’s possible to automatically add newly-created accounts to an existing group. The initial response offered by the community focused on dynamic groups – either dynamic distribution lists or dynamic Azure AD groups.

It’s a reasonable suggestion. Dynamic distribution groups are part of base Exchange Online functionality and don’t require any additional licenses. Dynamic Azure AD groups require Azure AD Premium P1 licenses for every account covered by dynamic membership. In both cases, the trick is to make sure that the query used by Exchange Online or Azure AD to determine group membership finds the new account.

Dynamic Group Membership for Exchange Online Mailboxes

It’s possible to create a dynamic distribution group based on a simple query like “all mailboxes” that will automatically include new accounts (if they have mailboxes). Figure 1 shows the UX in the Exchange admin center (EAC) to define the membership of a new dynamic distribution list.

The list works and email sent to it arrives in the inbox of every mailbox in the tenant, including shared mailboxes. This is because the recipient filter generated by Exchange Online for the dynamic distribution group selects all mail-enabled objects with a recipient type of ‘UserMailbox’ and only filters out some system mailboxes.

A dynamic distribution list like this is said to use a “canned” recipient filter because Exchange Online generates the filter based on the choices the administrator makes when they create the new list. You can only edit canned filters through the EAC. Exchange Online gives greater flexibility through the support of custom recipient filters. These filters can only be created using PowerShell, but they’re much more flexible in terms of selecting the set of mail-enabled objects to address through the list. A simple custom recipient filter to find just user mailboxes is shown below together with a test with the Get-Recipient cmdlet to prove that the filter works.

$Filter = "{RecipientTypeDetails -eq 'UserMailbox'}"
Get-Recipient -RecipientPreviewFilter $Filter

Dynamic Group Membership for Azure AD User Accounts

Dynamic Azure AD groups can be used with Microsoft 365 groups and Teams. These groups use different membership filters (query rules) to find the set of target objects. Instead of mail-enabled objects like mailboxes, the query against Azure AD focuses on user accounts rather than mailboxes. However, the same capability exists in that it’s possible to create a dynamic Azure AD group that includes all user accounts, including those newly created.

Again, the key is to construct a query rule that finds all user accounts – of the right type. When Azure AD is used for a Microsoft 365 tenant, there are many non-interactive user accounts created to give identities to objects such as shared mailboxes and room mailboxes. These are all considered “member” accounts and it’s easy to build a rule to find all member accounts. However, you probably want a more refined version that finds just the accounts used by humans.

Azure AD doesn’t have a human filter, so we need to construct something that Azure AD can use to find matching accounts in its directory. One approach is to use licenses for the check. You could look for accounts assigned Office 365 E3 licenses but would have to check for accounts with F1 or E5 licenses too. An easy change is to look for accounts that have any license that has at least one enabled service. For instance, accounts with Office 365 E3 or E5 licenses with the Exchange Online, Teams, Planner, or SharePoint Online service would all match. Figure 2 shows a test of the rule against a “real” user account and some other user accounts belonging to room and shared mailboxes. You can see that the real account passes the validation test while the others do not.

Azure AD accounts used by shared mailboxes must be assigned licenses when they need more than 50 GB of mailbox storage or an online archive. These accounts satisfy the membership rule, but that’s perhaps not important. If it is, some tweaking of the membership rule is necessary to remove the shared mailbox accounts.

Dynamic Group Membership of Org-Wide Teams

If your organization is smaller than 10,000 accounts, new Azure AD accounts automatically join the org-wide teams in the tenant (a tenant can support up to five org-wide teams). Org-wide teams are a special form of dynamic Microsoft 365 group whose membership is controlled by Teams rather than Azure AD, so Azure AD Premium P1 license are not required.

The PowerShell Alternative to Manage Dynamic Group Membership

If you don’t want to use a dynamic object, it’s certainly possible to use standard distribution lists or Microsoft 35 groups. In this scenario, the tenant takes the responsibility for maintaining group membership. Usually, PowerShell is used to add new accounts to group membership. You don’t have to worry about removing deleted accounts from the group as this happens automatically following an account deletion.

To add a new user to a distribution list, use the Add-DistributionGroupMember cmdlet:

Add-DistributionGroupMember -Identity "All Tenant Mailboxes" -Member Lotte.Vetler@office365itpros.com

To add a new user account to a Microsoft 365 group, either run the Add-UnifiedGroupLinks cmdlet (from the Exchange Online management module) or the New-MgGroupMember cmdlet (from the Microsoft Graph PowerShell SDK):

Add-UnifiedGroupLinks -Identity "All Tenant Accounts" -LinkType Member -Links Lotte.Vetler@office365itpros.com

New-MgGroupMember -GroupId "107fe4dd-809c-4ec9-a3a1-ab88c96e0a5e" -DirectoryObjectId (Get-MgUser -UserId Lotte.Vetler@office365itpros.com).Id

If the tenant creates user accounts programmatically with PowerShell, these commands can be added to that script. If not, a background scheduled job could find accounts that don’t exist in group membership and add them. See this article for more information about group management with the Microsoft Graph PowerShell SDK.

Many Possibilities to Ponder

A simple question required a long answer. That’s because the questioner didn’t specify what type of group that they wanted to add new accounts to. In any case, it’s nice to be able to debate the possibilities and then settle on the best course of action to take.

Insight about the various options to manage dynamic group membership for new accounts 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.

Dynamic Distribution Lists to Dynamic Microsoft 365 Groups

Earlier this week, I described how to create a Microsoft 365 group and team from an Exchange Online dynamic distribution list. The code creates a group with static membership, but the input dynamic distribution list has its membership computed by Exchange Online using a recipient filter (aka a membership rule). Why can’t we take the filter used by the dynamic distribution list and apply it to create a dynamic Microsoft 365 group, which in turn becomes a team with dynamic membership. Well, as it turns out, it’s not quite as simple as taking a filter from one Microsoft 365 workload and using it in another.

Translating Recipient Filters for Dynamic Microsoft 365 Groups

Conceptually, it is possible to convert a dynamic distribution list to a be the membership rule for a dynamic Azure AD group. Two challenges exist: filter syntax and filter properties.

The query stored in a dynamic distribution list looks like this:

((((((Title -eq 'Architect') -or (Title -eq 'Senior Architect'))) -or (((Title -eq 'Principal Architect') -and (ExchangeUserAccountControl -ne 'AccountDisabled'))))) -and (-not(Name -like 'SystemMailbox{*')) -and (-not(Name -like 'CAS_{*')) -and (-not(RecipientTypeDetailsValue -eq 'MailboxPlan')) -and (-not(RecipientTypeDetailsValue -eq 'DiscoveryMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'PublicFolderMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'ArbitrationMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuditLogMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuxAuditLogMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'SupervisoryReviewPolicyMailbox')))

We know this is a custom recipient filter created using PowerShell because the properties it uses are not covered by the precanned filters created using EAC. The custom filter comes first followed by a bunch of exclusions inserted by Exchange to make sure that system mailboxes are not in the returned set. Exchange adds these exclusions automatically when it saves the recipient filter for a dynamic distribution list.

It’s technically possible to take a recipient filter from a dynamic distribution list and parse it to extract the custom part using Regex expressions. By using a function to remove special characters, I was able to process the recipient filter shown above like this:

$Filter = (Get-DynamicDistributionGroup -Identity "System Architects").RecipientFilter
$i = $Filter.IndexOf("-and (ExchangeUser")
$f = $Filter.Substring(0,$i)
$ExoFilter = Remove-StringSpecialCharacter -String $f -SpecialCharacterToKeep '-', " "

The output is:

Title -eq Architect -or Title -eq Senior Architect -or Title -eq Principal Architect

However, a complicating factor is that Exchange has changed the format of the exclusions it inserts over time. This means that you can never be sure how the recipient filter is formatted, and my code didn’t work when tested against several other dynamic distribution lists in my tenant, some of which go back to 2014.

In any case, the output I generated isn’t a valid Azure AD filter, and some additional work is needed to make it work with a dynamic Azure AD group (team). Briefly:

• Title is the name of the Exchange property. It is JobTitle in Azure AD. Also, user properties are prefixed with “User,” meaning that you end up with User.JobTitle.
• The -eq and -or operators in Exchange lose the leading hyphen in Azure AD.

Different Filterable Properties

A more fundamental issue is that while Exchange supports many mail-enabled properties for custom recipient filters in dynamic distribution lists, the set of filterable properties don’t match the set available for Azure AD. You might be able to convert some queries, but you won’t be able to convert others. The difference is accounted for by the fact that Exchange queries against its own directory, which stores details of mail-enabled objects, while Azure AD queries its directory. The two directories have different schemas.

Once I realized the extent of the incompatibility between the two sets of properties, I stopped trying to figure out how an automatic conversion could be done. Too much time would be needed to figure out the permutations and combinations involved in formatting membership rules. And given the number of times a conversion might be necessary, the easiest solution is to let human administrators generate the membership rules.

Previewing Azure AD Filters

The GUI in the Azure AD admin center to deal with dynamic groups include a rules editor. You can paste the outline of a membership rule taken from an Exchange dynamic distribution list and modify it there. The Azure AD admin center also includes a nifty preview feature to validate that a membership rule works. After making whatever changes are necessary to create a valid rule for Azure AD, you can test the rule by nominating one or more users that you know should match the membership rule. Click the validate button and Azure AD will tell you if the directory can find the users you selected using the rule (Figure 1).

Exchange Online doesn’t have a similar way to validate the membership of a dynamic distribution list. Maybe that’s why Microsoft considers dynamic Azure AD groups to be a premium feature and charges accordingly.

Creating a Dynamic Azure AD Group with PowerShell

For the record, you can create a dynamic Azure AD group with PowerShell. In this instance, I use the New-MgGroup cmdlet from the Microsoft Graph PowerShell SDK (the New-AzureADMSGroup cmdlet from the preview version of the Azure AD module will work too). The important point is that the group has dynamic membership rather than static and has a rule to control the membership:

$Group = New-MgGroup -DisplayName "System Architects (Dynamic x2)" -Description "People with an architect job title" -MailEnabled:$True -SecurityEnabled:$True -MailNickName "System.Architects.Dynamic2" -GroupTypes "DynamicMembership", "Unified" -MembershipRule "(User.JobTitle -eq ""Architect"" or  User.JobTitle eq ""Senior Architect

After creating the dynamic Azure AD group, you can team-enable it with the New-Team cmdlet by passing the identifier of the newly created group.

New-Team -GroupId $Group.Id

Incompatible schemas, properties, and syntax might stop the automatic conversion of membership rules, but you can at least get the job done with a little manual effort.

Learn more about how the Office 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.

Creating Teams from Exchange Online DDLs

After writing about the recent revamp of Exchange Online dynamic distribution lists, I was asked if it was possible to create a team from the membership of a dynamic distribution list. The answer is that the steps are straightforward to create a static Microsoft 365 group. Things get more complicated if you contemplate using a dynamic Microsoft 365 group.

Available in both Exchange Online and Exchange Server, dynamic distribution lists are very powerful. That is, if the organization directory is well-maintained with details about people, job titles, department names, offices, country, and so on. The membership of dynamic distribution lists can include any kind of mail-enabled recipient, including other groups. And that’s the first challenge to face: the Microsoft 365 groups used by Teams support a flat membership (no nested groups) composed solely of accounts belonging to the host organization (members and guests): only user mailboxes can migrate to become members of a target Microsoft 365 group.

The second challenge comes into play if you decide that the target Microsoft 365 group should have dynamic membership. The issue here is that dynamic distribution lists use filters executed against Exchange Online’s directory while dynamic Microsoft 365 groups use filters based on Azure AD. Different filters, different syntax, and different properties. More on this later.

Converting a Dynamic Distribution List to a Team with Static Membership

Starting with the simple issue of finding the members of a dynamic distribution list and using this information to create a new Microsoft 365 group, the steps are straightforward:

• Identify the source dynamic distribution list.
• Get the members of the dynamic distribution list and throw away any that can’t be members of a Microsoft 365 group.
• Check that the owner of the source dynamic distribution list is a valid mailbox.
• Create the new Microsoft 365 group using properties like name and description inherited from the source dynamic distribution group. The person who manages the dynamic distribution list becomes the owner of the Microsoft 365 group.
• Add the members to the new Microsoft 365 group to the membership.
• Team-enabled the new Microsoft 365 group.

The script I created is available in GitHub. Normal caveats apply: the code works but it doesn’t have much error checking. It’s there to prove a principle, not be an off-the-shelf solution.

Finding the Source

Multiple ways exist to identify a source dynamic distribution list. This example prompts the user to select one. The code could become a lot more complex to allow the user to make a mistake and select from a numbered list, and so on, but for the purpose of the example all we want is the object identifier for a valid dynamic distribution list:

$InputDDL = Read-Host "Enter the name of the Dynamic Distribution List to convert to a Microsoft 365 Group"
[array]$SourceDDL = Get-DynamicDistributionGroup -Identity $InputDDL -ErrorAction SilentlyContinue

If (!($SourceDDL)) {Write-Host ("Sorry! We can't find the {0} dynamic distribution list" -f $InputDDL); break}
If ($SourceDDL.Count -gt 1) {
   CLS
   Write-Host "We found multiple matching dynamic distribution lists"
   Write-Host "-----------------------------------------------------"
   Write-Host " "
   $SourceDDL | Format-Table DisplayName, Alias, PrimarySMTPAddress
   Write-Host " "
   Write-Host "Please try again..."; break }

[string]$SourceDDLId = $SourceDDL.ExternalDirectoryObjectId

Two methods exist to return the membership of the dynamic distribution list:

• Run Get-Recipient using the filter stored in the dynamic distribution list.
• Use the new Get-DynamicDistributionGroupMember cmdlet.

The first method resolves against the Exchange directory and its results are up to date. The second fetches membership data as at the last time Exchange processed the list (more information here). After retrieving the membership using the chosen method, we apply a filter to extract mailboxes.

# Now that we have a source DDL, let's get its membership
[array]$SourceMembers = Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup -Identity $SourceDDLId).RecipientFilter
# could also be 
# [array]$SourceMembers = Get-DynamicDistributionGroupMember -Identity $SourceDDL.Id
# Throw away anything but user mailboxes because that's all a Microsoft 365 group supports
[array]$ValidMembers = $SourceMembers | ? {$_.RecipientTypeDetails -eq "UserMailbox"}

The next piece of code establishes the owner of the new group. Microsoft 365 groups must have an owner, so if the ManagedBy property of the source list results in an invalid result (for instance, it’s empty), we need to assign ownership to a default account. One way of doing this is to find the set of Exchange administrators for the organization and select one of them, which is done here using the Get-MgDirectoryRoleMember cmdlet from the Microsoft Graph PowerShell SDK and filtering out any service principals assigned the Exchange administrator role. You could simplify the script by hardcoding a default group member.

# We've got to assign an owner to the new Microsoft 365 group, so we need to have a default in case the source DDL doesn't have an owner
# Find the set of accounts that are Exchange admins (you can also use Get-AzureADDirectoryRoleMember here)
[array]$ExoAdmins = Get-MgDirectoryRoleMember -DirectoryRoleId "53add08e-5b0c-4276-a582-9ce02fb6c947" | Select Id, AdditionalProperties 
# Throw away any service principals which might have the Exchange Admin role
$ExoAdmins = $ExoAdmins | ? {$_.AdditionalProperties.'@odata.type' -eq '#microsoft.graph.user'} | Select -ExpandProperty Id
# Select the first and use them as the default owner
$ExoDefaultAdmin = Get-MgUser -UserId $ExoAdmins[0] | Select -ExpandProperty UserPrincipalName
# Check that the group owner is a mailbox
$GroupOwner = Get-ExoMailbox -Identity $SourceDDL.Managedby -ErrorAction SilentlyContinue
# If it's null or something weird like a shared mailbox, use the default owner
If (($GroupOwner -eq $Null) -or ($GroupOwner.RecipientTypeDetails -ne "UserMailbox")) {
   $GroupOwner = $ExoDefaultAdmin }
Else {
   $GroupOwner = $GroupOwner.PrimarySmtpAddress
  }

# Populate other group properties
$AliasDDL = $SourceDDL.Alias + "M365"
$GroupDisplayName = $SourceDDL.DisplayName + " (Group)"

Creating the New Group and Team

With everything ready, we can go ahead and create the new Microsoft 365 Group, add the members, and team-enable the group. All the members can be added with a single Add-UnifiedGroupLinks command because we have an array of email addresses. Exchange processes each item in the array and adds it as a member.

# Create the new Microsoft 365 Group
Write-Host "Creating the new Microsoft 365 group..."
$Description = "Created from the " + $SourceDDL.DisplayName + " dynamic distribution list on " + (Get-Date -Format g)
$NewGroup = New-UnifiedGroup -DisplayName $GroupDisplayName –AccessType Private -Alias $AliasDDL -RequireSenderAuthenticationEnabled $True -Owner $SourceDDL.ManagedBy -AutoSubscribeNewMembers -Notes $Description
# Add the members to the group
Write-Host "Adding members from the dynamic distribution list to the Microsoft 365 group..."
Add-UnifiedGroupLinks -Identity $NewGroup.ExternalDirectoryObjectId -LinkType Members -Links $ValidMembers.PrimarySmtpAddress
Write-Host "Enabing Microsoft Teams for the Microsoft 365 group..."
New-Team -Group $NewGroup.ExternalDirectoryObjectId

The code doesn’t add a sensitivity label, so if you use these to apply container settings to groups and teams, you should add the label when creating the new group by passing the identifier for the selected label in the SensitivityLabel parameter.

That’s it. We have a new team built from the membership of a dynamic distribution list. The code is straightforward and works without a hitch, but if we throw dynamic membership for the Microsoft 365 group/team into the equation, things become much more complex. I’ll cover that subject in another post.

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

Seeking Protection Against Forwarding

A question came in about the best way for internal email to be protected against external sharing. The company in question uses dynamic distribution lists for employee communications like organizational announcements. Management wants recipients to be unable to forward this email to external people. It’s a common request that goes back to the earliest days of information protection.

Outlook and OWA support encryption through the two default templates made available through Office 365 Message Encryption (OME) to users with Office 365 E3 and E5 licenses. The Encrypt-Only template protects email in transit and makes sure that only people on the addressee list can open messages. The Do No Forward template adds in a block to prevent forwarding. On the surface, it seems like the Do Not Forward template is a good choice. And is it, but only if you use regular distribution lists. OME-protected messages don’t work with dynamic distribution lists. The reason is simple and comes down to the inability to obtain use licenses from the Information Protection service.

Dynamic Membership Stops Protection Licensing

Exchange Online resolves the membership of a dynamic distribution list to know who should receive copies of messages sent to the list. For years, resolution happened when the transport service processed a message sent to a dynamic distribution list. Recently, Microsoft changed this to a timed basis, meaning that Exchange Online resolves the recipient query against the directory to find list membership daily. List membership is less dynamic than it once was, but the lack of immediacy doesn’t usually make much difference in practice.

When Exchange Online processes email sent to a dynamic distribution group, it bifurcates the message to create a copy to deliver to each recipient. If the message is protected with OME, recipients receive an encrypted copy with their email address in the message recipients. To open the copy, the recipient needs the right to access the content, which works for OME because the publishing license for the message includes the recipient. However, because Exchange Online creates message copies in the transport pipeline for list recipient, the publishing license doesn’t include their details. Email clients cannot verify that the recipient has the necessary permission, so they cannot open the message (Figure 1).

In a nutshell, OME templates work well when sent to individual recipients present in messages when sent. They just can’t deal with the way Exchange Online adds recipients to messages during transport.

Use a Sensitivity Label to Protect Confidential Email

Although dynamic distribution lists cannot be used with OME, sensitivity labels offer a solution. You cannot control the rights assigned through an OME template, but this control is possible in a sensitivity label. The key is to include the special All users and groups and your organization group in the permissions assigned in the label (Figure 2).

You can also assign permissions to individual users or groups (but not dynamic distribution lists). If you do this for a label used with dynamic distribution lists, make sure that you assign permissions to cover everyone in the list. If you don’t, some recipients will be unable to read messages. All users and groups in your organization is a convenient way to ensure that everyone in the tenant can read content protected by the sensitivity label, including documents stored in SharePoint Online and OneDrive for Business.

When you add permission assignments to the label, you define the rights the assignees receive. While you can create a custom permission set containing specific rights, Microsoft makes it easy to assign rights through predefined sets. Details of the Viewer role appear in Figure 3. Recipients with this role can read content but they cannot perform other actions like print or forward. Assigning this role to the special group in a sensitivity label ensures that everyone with an account in the tenant can read any content protected by the label.

After configuring the sensitivity label, it can be made available to users through a label publishing policy. This process will take some hours because it requires clients to refresh their label cache. Once this happens, users can apply the sensitivity label to email sent to dynamic distribution lists, and tenant accounts who are members of those lists can read the messages (Figure 4).

If someone forwards a message to someone outside the tenant, that user won’t have the necessary rights to open the message and all they’ll see is a message with an encrypted attachment. They can follow the directions in the message to the OME portal and attempt to open the message there, but without rights, nothing will happen. This is a good example of rights management in action.

Rights Management and Office 365

Anyone with an Office 365 license can read content protected with sensitivity labels. To apply sensitivity labels, you need at least an Office 365 E3 license. Remember that sensitivity labels also support container management for Groups, Teams, and Sites, so they’re more than just a way to apply encryption.

Learn more about how Office 365 really works 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.

Update Intended to Make Dynamic Groups More Reliable

Update March 8: Microsoft published MC340293 to announce the feature. It’s odd that they do so some months after people saw the functionality work in their tenants. Microsoft says that they will begin the general roll-out the feature in April 2022.

A LinkedIn post discusses Modern Dynamic Distribution Groups (also known as dynamic distribution lists) and says that Microsoft is going to roll out this upgrade for these very useful objects in January with worldwide completion due in March. The fundamental change is to move away from on-demand resolution of group queries to resolve and store group membership daily.

The reasons cited to make the change are to Reduce mail delivery latency by removing the need to resolve the queries against the Exchange directory each time someone addresses the group. Because they cover a limited set of well-known conditions, it’s usually easy for Exchange to resolve precanned filters to find a set of mail recipients. However, custom filters can be reasonably complex and their resolution can slow the ability of the Exchange transport service to route messages. Microsoft believes that making the change to pre-resolved recipient lists will also Improve service reliability.

According to Microsoft, they released details of the change in message center notification MC289967 in early November. I never saw this notification and no trace of it exists in my tenant. However, everything seems to be working as reported in my targeted release tenant. Microsoft says that full roll out will start in early January and should be available everywhere in March 2022.

Less Dynamic but Still Valid

Of course, creating recipient lists for dynamic distribution groups makes them less dynamic and depends on an assumption that group membership doesn’t change often. In most cases, the assumption is true: organizations do not update directory attributes every few days and the membership of dynamic groups probably doesn’t vary all that often.

A side effect of the change is that when administrators create new dynamic distribution groups or update the filters of existing groups, it can take up to two hours before Exchange Online calculates the membership of the new group and makes it available for use. This is different to previous behavior when Exchange could use a new or updated filter immediately it was updated in the directory. The new Exchange Admin Center already flags the need to wait to administrators (Figure 1). True to its word, when I created a new dynamic distribution group, it was available almost exactly two hours later.

To see when Exchange Online last computed the membership of dynamic distribution lists, run the Get-DynamicDistributionGroup cmdlet and examine the CalculatedMembershipUpdateTime property. The results shown below were obtained at 15:00 on 10 December 2021 at, so membership was approximately 18 hours old at that point.

Get-DynamicDistributionGroup | Format-Table DisplayName, CalculatedMembershipUpdateTime

DisplayName                              CalculatedMembershipUpdateTime
-----------                              ------------------------------
Company-DDG                              09/12/2021 20:50:06
Dublin users                             09/12/2021 20:50:06
Office 365 Gurus                         09/12/2021 20:50:06

Moving away from on-demand membership resolution means that Exchange Online now uses the same approach to calculating dynamic group membership as Azure AD uses for its dynamic groups. No great issues have been reported by organizations struggling to deal with Azure AD group memberships, so there’s no reason to believe that problems will surface with Exchange Online.

New Get-DynamicDistributionGroupMember Cmdlet

Because Exchange Online now calculates the membership of dynamic distribution groups daily, the membership of these groups is available without having to run the Get-Recipient cmdlet to resolve the group query. For example, instead of fetching the recipient filter from the group and using it as an input to the Get-Recipient cmdlet like this:

Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup -Identity Architects).RecipientFilter

Name           RecipientType
----           -------------
Ben.James      UserMailbox
Brian Weakliam UserMailbox
James.Joyce    UserMailbox
Marc Vilas     UserMailbox
TRedmond       UserMailbox
Vasil.Michev   UserMailbox

You can use the Get-DynamicDistributionGroupMember cmdlet instead:

Get-DynamicDistributionGroupMember -Identity Architects

Name           RecipientType
----           -------------
TRedmond       UserMailbox
Marc Vilas     UserMailbox
Vasil.Michev   UserMailbox
Brian Weakliam UserMailbox
Ben.James      UserMailbox
James.Joyce    UserMailbox

Although they’re not returned in the same order, the two cmdlets produce the same set of mail-enabled recipients.

The Get-DynamicDistributionGroupMember cmdlet is available in the Exchange Online management module (and based on Microsoft documentation, the cmdlet has been around since mid-August 2021, even if no one noticed). However, no email client yet supports the ability to:

• Expand the membership of a dynamic group and insert each member as a separate recipient in the header of a message.
• View the membership of a dynamic group through the address book.

As of November 2022, no Outlook client supports these features.

Trivia note: The Microsoft Exchange PowerShell Cookbook, published in 2015, includes a function called Get-DynamicDistributionGroupMember which uses Get-Recipient to resolve a recipient filter against the directory.

Not Much Impact

Only Microsoft can say if the change to precalculated membership speeds message delivery and increases the robustness of the Exchange Online transport service. It’s easy to see how performance will improve, but you’d assume that Exchange had mastered the resolution of membership queries by now (dynamic groups first appeared in Exchange 2003). In any case, the change won’t make any difference to end users. Some might notice if Microsoft updates Outlook to support membership expansion of dynamic groups, but others will never see a difference.

Keep up to date with developments like new PowerShell cmdlets by subscribing to the Office 365 for IT Pros eBook. Our monthly updates make sure that our subscribers understand the most important changes happening across Office 365.

Build Filters Against Multiple Entra ID User Account Properties

A post in the Microsoft Technical Community looked for help building a dynamic distribution list based on multiple Entra ID properties. Our esteemed technical editor, Vasil Michev, stepped in to help and involved me. I pointed out that this topic is covered in the Groups chapter of the Office 365 for IT Pros eBook (easy to miss in 1,350 pages) but admitted that the question was interesting.

Dynamic distribution lists are an undervalued part of Exchange Online. The functionality has existed since Exchange 2003 introduced the query-based distribution group, or QDG. The current implementation arrived in Exchange 2007. In both cases, a query is resolved against the directory to identify the set of recipients for a message. The list is dynamic because the set of recipients will change based on the contents of the directory. Exchange Online calculates the list membership behind the scenes (the “modern” implementation), but the concept of membership depending on a filter run against the directory still holds.

Precanned and Custom Recipient Filters

The Exchange admin center (EAC) GUI is designed to make it easy for administrators to create the queries for dynamic distribution lists. It does this by limiting the set of properties available for queries, like department and city. The queries generated by the EAC are called precanned queries. after generation, Exchange stores the recipient filter as a property of the dynamic distribution list.

Custom queries can use a much wider set of properties. The downside is that you must build the recipient filters by hand and update dynamic distribution lists with PowerShell. That might seem hard, but it’s really not.

Excluding Some Mailboxes

In this instance, the need is to have a dynamic distribution list to address mailboxes owned by people with a specific job title but exclude any user accounts that Entra ID currently blocks for sign-in. Figure 1 shows the account of architect Ben James. The account is blocked.

When a user account is blocked, Exchange Online synchronizes the status and updates the ExchangeUserAccountControl mailbox property. To find the set of recipients who have architect in their job title and can still sign in, we can build a recipient filter which checks the Title and ExchangeUserAccountControl properties. Because people might have prefixes to indicate the seniority of their architect status, we need to include some variants of the job title. Exchange Online only supports wildcards for filters at the end of a string (“architect*”) instead of the start (“*architect”), which would be more useful in this case.

Building and Testing a Recipient Filter with PowerShell

Here’s what a custom filter to check for a job title and account blocked status looks like:

$Filter = "((Title -eq 'Architect') -or (Title -eq 'Senior Architect') -or (Title -eq 'Principal Architect') -and (ExchangeUserAccountControl -ne 'AccountDisabled'))"

To know if the filter works, we can use the Get-Recipient cmdlet. Get-Recipient accepts the filter defined in the $Filter variable and returns what it finds in the directory. This is exactly what will be returned as the set of recipients when the Exchange transport service resolves the query stored in the dynamic distribution list.

Get-Recipient -RecipientPreviewFilter $Filter | ft displayname, title

DisplayName                   Title
-----------                   -----
Ben James                     Architect
Eoin Redmond (Ireland)        Architect
James Joyce                   Principal Architect
Tony Redmond                  Principal Architect
Vasil Michev (Technical Guru) Senior Architect

It’s important to test a recipient filter before using it with a dynamic distribution list. If the query generated by the filter fails to resolve and return any recipients, any message sent to the list goes into a black hole. Exchange won’t generate a non-delivery notification because the address used for the message is valid (the list); the problem lies with what happens when the query is run against the directory.

Creating a Dynamic Distribution List with PowerShell

After you’re sure that the filter returns the correct set of recipients, you can create a dynamic distribution list using the filter. For example:

New-DynamicDistributionGroup -Name "Architects" -DisplayName "System and Engineering Architects" -Alias AllArchitects -PrimarySmtpAddress Architects@Office365itpros.com -RecipientFilter $Filter
Set-DynamicDistributionGroup -Identity AllArchitects -ManagedBy Tony.Redmond -MailTip "Distribution List for anyone with Architect in the job title"

The second command is to add an owner for the dynamic distribution list and to assign a mail tip for clients like Outlook to display when people address email to the list.

EAC Blocks Edits of Custom Recipient Filters

Any further adjustments to the recipient filter can only be made with PowerShell. If you look at a custom recipient filter with the Exchange admin center, it’s blocked for edit (Figure 2).

As for Ben James, when his user account is reenabled for sign-in, he’ll start to receive messages sent to the dynamic distribution list again, which is exactly what we want.

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.

Dynamic Expansion of Recipient Lists

Exchange 2003 introduced query-based distribution groups (QDGs), a form of email distribution list which doesn’t have a fixed set of recipients but instead contains a query to be executed against a directory to resolve the recipients each time the list is used. Today, the same concept persists in Exchange Online dynamic distribution lists (DDLs) and Microsoft 365 dynamic groups. However, as detailed in Table 1, the two implementations for dynamic membership are based on very different foundations.

You can boil the differences down to the directory used to resolve membership, but that’s a very simplistic view. The bigger differences are the cost and how Microsoft 365 groups are used to manage membership for Teams, Yammer, and other apps.

Anatomy of a Dynamic Distribution List

A DDL is composed of:

• An Exchange Online object which is not synchronized to Azure AD. A DDL only exists in EXODS.
• A recipient filter used to resolve the set of recipients. The filter can resolve against Azure AD attributes (like City and Department), but only if they are synchronized to EXODS. Many other Exchange-specific attributes can be used in recipient filters.
• Other properties like a manager, MailTip, etc. used by email functionality.

A DDL cannot be used for security purposes. Its membership cannot contain a mixture of fixed and dynamic recipients, but membership can be made up of any mail-enabled recipient type including other distribution lists, mail contacts, public folders, and hybrid recipients.

Managing Dynamic Distribution Lists

DDLs are created and managed using the older Exchange admin center or PowerShell. The modern EAC does not yet include the functionality to create and manage DDLs. And because DDLs are not Azure AD objects, you can’t create or manage them through the Azure AD portal or the Microsoft 365 admin center.

Figure 1 shows the initial step in creating a new DDL. At the bottom of the screen you can see the start of creating the query for the DDL when we specify what types if mail-enabled recipients should be found.

Finding only recipients of a certain type is a valid query, but in most cases, you’ll want to refine the filter by adding some rules to check against filterable properties. In Figure 2, we’ve chosen to filter against two properties (Department and CustomAttribute1) and are entering one of the values we want to find in CustomAttribute1.

When saved, the rules are written out into the RecipientFilter property of the DDL. Exchange Online writes the recipient filter into the list after applying some post-processing to make sure that the filter finds the intended objects. Here’s the filter created for the DDL shown in Figures 1 and 2:

Get-DynamicDistributionGroup -Identity "Office 365 for IT Pros Writers" | Select -ExpandProperty RecipientFilter

((((((Department -eq 'Writers') -or (Department -eq 'Authors') -or (Department -eq 'Production'))) -and (CustomAttribute1 -eq 'Author’) -and (RecipientType -eq 'UserMailbox'))) -and (-not(Name -like 'SystemMailbox{*')) -and (-not(Name -like 'CAS_{*')) -and (-not(RecipientTypeDetailsValue -eq 'MailboxPlan')) -and (-not(RecipientTypeDetailsValue -eq 'DiscoveryMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'PublicFolderMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'ArbitrationMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuditLogMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'AuxAuditLogMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'SupervisoryReviewPolicyMailbox')) -and (-not(RecipientTypeDetailsValue -eq 'GuestMailUser')))

The filter looks complex, but the bulk is made up of exclusionary clauses to avoid messages being sent to system mailboxes.

Recipient Filters

Recipient filters (queries) are at the heart of DDLs. The queries are stated in OPATH format and two types are available:

• Precanned filters are created when you compose query rules for a DDL through the EAC. Precanned filters are restricted to queries against a small number of well-known object properties such as the department, city, and 15 customizable attributes. See this article for details for how to use precanned filters.
• Custom filters are created when you use PowerShell to define a recipient filter. Canned filters are more powerful and flexible than precanned filters because a wider of properties can be included in a query. Once you apply a custom filter to a DDL, you won’t be able to edit the filter through the EAC. This article explains how to build custom filters for use with a dynamic distribution list.

No matter how good your query is, it is useless if the properties of objects stored in EXODS are incomplete or inaccurate. Queries will run, but the transport service won’t find the correct set of addressees to receive messages.

You can test the effectiveness of a recipient filter by using it with the Get-Recipient cmdlet and checking the set of objects returned. For example:

Get-Recipient –RecipientPreviewFilter (Get-DynamicDistributionGroup –Identity "Office 365 for IT Pros Writers").RecipientFilter

Name		RecipientType
---- 		-------------
Jeff.Guillet    UserMailbox
James.Ryan      UserMailbox
Jane.Sixsmith   UserMailbox

Update: You can now use the Get-DynamicDistributionGroupMember cmdlet to see the membership of a dynamic distribution list.

Messages sent to dynamic distribution lists with queries that don’t find any recipients go into a void. Senders don’t receive any indication that the message reached no one, which is a good reason to validate that the recipient filter for a DDL finds some recipients.

Dynamic Distribution Lists Still Valuable

DDLs are simple, robust, and work. Everything depends on the recipient filter, but once you can query and find the right recipients, there’s very little else that can go wrong. DDLs are a good choice when you want to target communications at a changeable set of mail-enabled recipients and don’t want to spend a lot of time making sure that the list membership doesn’t go out of date. The big dependency is the directory. Make sure that EXODS (and by extension, Azure AD) is populated with accurate information and you’ll lay a great foundation for successful DDLs.

Learn more about dynamic distribution lists and dynamic Microsoft 365 Groups in the Office 365 for IT Pros eBook. We must be like a dynamic distribution list because we’re always updating our contents to stay accurate.

Send Email to Filtered Sets of Recipients

After explaining how to use a custom attribute to store users’ beverage of choice and surface that information in Office 365 apps through the Microsoft 365 profile card, the question came up if it is possible to create a dynamic distribution list using the same custom attribute. The answer is “absolutely!”

Dynamic distribution lists are a very powerful way of addressing specific sets of mail-enabled recipients. Table 1 compares their capabilities against those of dynamic Microsoft 365 groups.

Some on-premises Exchange organizations use thousands of dynamic distribution groups. Because of the presence of other methods to address sets of users like Microsoft 365 Groups and Teams in Office 365, dynamic distribution lists are not as heavily used. But as we’ll see, these lists are easily to create and use.

Filters Against the Directory

The core of both types of dynamic groups is the filter used to find objects in the source directory. The filters can be very complex when multiple attributes are involved, but in this case the filter needed to find users with a particular value in a custom attribute is straightforward. For example, to create a dynamic distribution list of mailboxes whose owners like beer, we can either use the Exchange admin center or run the New-DynamicDistributionGroup cmdlet:

New-DynamicDistributionGroup -Name DynamicBeer -DisplayName "Dynamic Beer Drinkers" -ConditionalCustomAttribute9 Beer -IncludedRecipients MailboxUsers -PrimarySmtpAddress Beer.Drinkers@office365itpros.com -Alias Beer.Drinkers

In this case, because we use CustomAttribute9 to hold the drink preference, we can use what’s called a “precanned” filter. In other words, Exchange knows that custom attributes are often used for filters, so the cmdlet supports an easy way to include these attributes in filters. The ConditionalCustomAttribute9 parameter is set to “Beer” and the IncludedRecipients parameter is set to MailboxUsers. Together, this creates a filter to find any user mailbox whose CustomAttribute9 is “Beer.”

If the attribute you want to use isn’t covered by a precanned filter, dynamic distribution lists can also use custom filters to find mail-enabled recipients. This is a little more complex because you must construct the filter instead of Exchange doing the job for you.

To complete the setup of the new dynamic distribution list, we use Set-DynamicDistributionGroup to define who is the list owner and create a mail tip to give an indication to users about the list’s purpose:

Set-DynamicDistributionGroup -Identity Beer.Drinkers -ManagedBy James.Joyce@Office365itpros.com -MailTip "Mailbox users who like beer"

Some judicious cut and pasting will quickly generate a set of dynamic distribution lists for people who like water, wine, cola, and so on.

Testing Recipient Filters

If you want to be sure that the filter created for a dynamic distribution list will locate the correct mailboxes, you can run the Get-Recipient cmdlet and input the recipient filter for the list. Here’s how:

Get-Recipient -RecipientPreviewFilter (Get-DynamicDistributionGroup -Identity Beer.Drinkers).RecipientFilter | Select DisplayName

DisplayName
-----------
Kim Akers
Imran Khan
James Ryan

To have more mailboxes picked up by the filter, update their CustomAttribute9 with the value used by the filter. For example:

Set-Mailbox -Identity James.Joyce -CustomAttribute9 "Beer"

Using the List

Using the dynamic distribution list is as easy as using any distribution list. The notable difference from an end user perspective is that there’s no option to expand the list and reveal the individual members by adding them to the message header (Figure 1).

The list membership is evaluated each time a message addressed to the list passes through the Exchange transport service and messages for matching recipients are generated at that point.

We’re rather fond of dynamic distribution lists, so they are covered in the Office 365 for IT Pros eBook. It’s an Office 365 feature that hasn’t changed in years… but we still like it.