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.

New Pause Processing Toggle Appears in Entra ID Admin Center

Updated 22-Nov-2023

A recent Entra ID admin center update for Entra ID dynamic groups allows administrators to pause membership processing to resolve membership rules and identify group members. I can’t find any announcement about the change, and it’s not tagged as a preview, but a toggle is there to pause processing (Figure 1) and it works.

Switching the pause processing toggle back to off allows Entra ID to continue processing membership rules. The properties of a dynamic group tell you the current state of processing and when the last membership change happened. Common processing states for Entra ID dynamic groups are:

• Succeeded: Entra ID has evaluated the membership query and the membership is up to date.
• Evaluating: Entra ID is currently resolving the membership query to identify group members.
• Processing: Entra ID is currently processing the membership.
• Processing error: Entra ID was unable to evaluate the membership query.
• Updates paused: An administrator has paused updates. The membership remains static until updates resume.
• Not started: Entra ID has not yet started to evaluate the membership of a dynamic group.

Entra ID reassesses membership as demand on the service allows, with the goal of checking at least once daily. It’s therefore possible that Entra ID will not process changes made to user objects that bring them within the scope of a membership rule for up to 24 hours. My experience is that updates often occur earlier, but it’s wise to set this expectation.

Reporting Dynamic Membership Updates

To check the current situation with dynamic membership updates, we can use PowerShell to find all the dynamic groups in the tenant and report the timestamp for the last membership update, whether processing is enabled, and the current update status. Here’s how to do the job with the Microsoft Graph PowerShell SDK:

Connect-MgGraph -Scope Group.Read.All, GroupMember.Read.All
[array]$Groups = Get-MgBetaGroup -Filter "groupTypes/any(c:c eq 'DynamicMembership')" -All 
If (!($Groups)) { 
    Write-Host "No dynamic groups found"
} Else { 
   Write-Host ("Processing {0} dynamic groups" -f $Groups.count) }
$Report = [System.Collections.Generic.List[Object]]::new()
$Groups = $Groups | Sort-Object DisplayName
ForEach ($Group in $Groups) {
  $Options = $Group.ResourceProvisioningOptions -join ", "
  [array]$Members = Get-MgGroupMember -GroupId $Group.Id
  [array]$Owners = Get-MgGroupOwner -GroupId $Group.Id
  $DynamicData = Get-MgBetaGroup -GroupId $Group.Id -Property MembershipRuleProcessingStatus
  $DataLine = [PSCustomObject] @{
    Id              = $Group.Id
    DisplayName     = $Group.DisplayName
    Owners          = $Owners.Count
    Members         = $Members.Count
    ProcessingState = $Group.MembershipRuleProcessingState
    LastUpdate      = $DynamicData.MembershipRuleProcessingStatus.LastMembershipUpdated
    Status          = $DynamicData.MembershipRuleProcessingStatus.Status
    Options         = $Options }
  $Report.Add($DataLine)
}
$Report | Out-GridView

You can see that the code uses separate calls to the Get-MgBetaGroup cmdlet to fetch the property holding the membership rule processing status for the groups. For some reason, the original call to fetch a set of filtered groups fails if this property is included in the list to be retrieved. As revealed by the Graph X-Ray add-on, the same flow happens in the Entra ID admin center.

The code also includes calls to the Get-MgGroupOwner, Get-MgGroupMember, and Get-MgUser cmdlets to fetch the set of owners and members for each group. Although the Get-MgGroupOwner and Get-MgGroupMember cmdlets returns the set of owners and members respectively for a group, they return object identifiers instead of display names. While we can use the information to report counts, to report the owner names, we need to run Get-MgUser. See these articles for more information about using the Microsoft Graph PowerShell SDK to work with Entra ID user accounts and Entra ID Groups. Figure 2 shows the output of the report.

Dynamic groups with paused membership updates show a last update of 1 January 2000. Most of the groups in Figure 2 have odd dates (1/1/0001). This situation occurred when I ran a script to pause membership processing for all dynamic groups. The next time Entra ID processes membership rules to validate group membership , it will update the date.

Dynamic Groups and Dynamic Distribution Lists

Entra ID dynamic groups and dynamic distribution lists are very different objects, but some people confuse the two or believe that the two objects are roughly the same. Apart from the requirement to have Entra ID Premium P1 licenses for Entra ID dynamic groups, the three biggest differences are:

• Dynamic distribution lists don’t exist in Entra ID. They are an Exchange object.
• Dynamic distribution lists support a wider set of member objects (any mail-enabled recipient).
• Dynamic distribution lists support a wider set of properties for building custom membership filters (queries).

See this article for more information about the differences between the two types of dynamic group.

Dynamic Restrictions

Because of the processing load required to evaluate and process group membership, Entra ID restricts the number of dynamic groups and dynamic administrative units combined per tenant to 5,000. In December 2021, Microsoft changed the way that Exchange Online evaluates membership of dynamic distribution lists in a similar attempt to save resources.

Reasons to Pause Membership Processing

Although I appreciate Microsoft adding the extra flexibility in pausing membership processing, I’m struggling to find a good use case. One might be in a merger and acquisition scenario where the directory is in a state of flux, and you want consistency in dynamic group memberships for a period. Apart from that, I don’t know why Microsoft introduced the feature. However, it’s here now and available if you need it.

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.

Including Members from Other Groups in Membership of Dynamic Groups

Until recently, Dynamic Azure AD Groups have not supported the ability to include members from other groups in their membership (aka, nested groups). You can construct membership rules to include the same accounts in a dynamic group, but it’s easier to say, “include the members from groups 1, 2, and 3” if those groups already exist and include the necessary accounts.

In a June 6 announcement, Microsoft introduced a preview feature to allow the membership rules for dynamic Azure AD groups to use the memberOf attribute. In essence, memberOf instructs Azure AD to extract the membership of one to up to 50 groups and include the individual members of those groups in the dynamic membership.

Creating a New Azure AD Dynamic Group

Apparently, the preview feature is available worldwide. I had no success using it in the Azure AD admin center. Any attempt to create a new group (of any type) generated the error: “per label policy, the selected visibility is not allowed” (Figure 1). No doubt this is due to some configuration I have tweaked, but the error message is obscure, to say the least. (Update: I discovered the root cause of the problem, which Microsoft say they will fix).

But where the will exists, you get the job done, and PowerShell came to the rescue. I created the new dynamic group with the following command. You can see that the membership rule is that the membership comes from any user members in the specified groups.

$Group = New-MgGroup -DisplayName "System Innovation" -Description "Dynamic group containing system innovators" -MailEnabled:$True -SecurityEnabled:$False -MailNickname SystemInnovators -GroupTypes "DynamicMembership", "Unified" -MembershipRule "user.memberOf -any (group.objectId -in ['ef4af711-bf83-4ba1-81be-fd98f4098d12',' d6279df7-2eff-4566-ba93-22aa9320385b','b07c7e05-10e0-47a4-acca-767621ac8ddc'])" -MembershipRuleProcessingState "On"

The groups added were:

• A Microsoft 365 group with assigned membership.
• A Microsoft 365 group with dynamic membership.
• A distribution list with a fixed membership.

Microsoft’s documentation doesn’t include any reference to using distribution lists, but as Azure AD treats distribution lists like other groups, it seemed like they should work. After all, you can run the Get-MgGroupMember cmdlet (or Get-AzureADGroupMember if you still haven’t converted from the soon-to-be-deprecated module) against a distribution list and Azure AD is happy to list the members. And as it turns out, you can include the membership of distribution lists in dynamic Azure AD groups. After an hour or so, Azure AD resolved the rule and built the membership of the new dynamic group, including the removal of any duplicates (Figure 2).

Preview Limits

During the preview, a dynamic group can have up to 50 groups in its membership, and each tenant can have up to 500 dynamic groups that use the memberOf attribute in their membership rule. If you add security groups to the membership of a dynamic group, Azure AD includes only the direct members of the security group in the dynamic group’s membership.

In addition, Microsoft says that you can’t use a dynamic group that uses the memberOf attribute to define the membership of another group that also uses memberOf. The old and well-proven adage to keep it simple (stupid) rings loud and clear. Don’t nest groups inside groups and don’t over-complicate things. Perhaps more complicated arrangements might be possible in the future, but for the preview, don’t give Azure AD complex membership rules to resolve. For more information on including groups within the membership of dynamic groups, read Microsoft’s documentation.

Another issue is that the memberOf attribute can’t be used with other rules. For instance, let’s assume that you assemble a set of users drawn from the membership of several other group. You can’t add another filter to select people whose accounts match another attribute, such as the department or country.

For now, the rules editor doesn’t work for this type of dynamic group, nor does the other Validate Rules preview feature which allows administrators to check the effectiveness of a membership rule against an account that they know should be in a group’s membership (Figure 3).

Dynamic Teams Work Too

I updated the group’s properties to enable it for Teams. Support for dynamic teams has been around since 2018, but it’s always wise to check. The good news is that the dynamic membership for the team appears as expected (Figure 4).

Solid Update

There’s no doubt that this is a good change. Anything that adds to the flexibility and capability of dynamic Azure AD groups is a good thing. The bad thing is that Microsoft requires Azure AD Premium P1 for dynamic groups (Exchange Online dynamic distribution lists don’t need additional licenses). The guidance is:

This feature requires an Azure AD Premium P1 license or Intune for Education for each unique user that is a member of one or more dynamic groups. You don’t have to assign licenses to users for them to be members of dynamic groups.

It would be nice if dynamic groups were included in Office 365 E3, but life is cruel sometimes…

So much change, all the time. It’s a challenge to stay abreast of all the updates Microsoft makes across Office 365. 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.