Five Good Reasons to Use Dynamic Microsoft 365 Groups

Simplify your Work with Dynamic Groups

Over time, Microsoft 365 tenants often grow and the number of devices and users increases. Instead of adding groups one by one whenever an additional user is added, dynamic groups can simplify your work. In this article, I explain some good reasons to use dynamic groups (regardless of whether they are security groups, Microsoft 365 Groups, or a dynamic distribution list) and some points to keep in mind when using them. One point to note is that dynamic distribution lists are unique to Exchange Online and do not appear in the Entra ID admin center or in results returned by Microsoft Graph requests. Exchange Online computes the membership of dynamic distribution lists using mail-enabled objects in the Exchange Online directory.

Before we review some common use cases for dynamic groups, let’s recap what dynamic groups are. A dynamic group means the group has no fixed members. The member list is determined by a membership rule defined in the group properties. Microsoft 365 Groups supports dynamic membership for either devices or users, but not both. You can also convert a group from static to dynamic membership if needed but this action will remove the current membership list. It may be a better idea to create a new dynamic group and rename the group together with its primary SMTP address so you can save the old group information. Also, note that you cannot rename dynamic distribution lists.

Using dynamic Microsoft 365 groups requires Entra ID P1 licenses for all accounts that come within the scope of the membership rules.

Creating Dynamic Groups Based on Property Values

The most common use case for dynamic groups is to have membership based on attribute values. For example, you can define a membership rule to retrieve users when the value of the department property of their account is “Consulting” and the phone number is +852, as shown in Figure 1. You may wonder why we use phone numbers as a condition. In my previous experience, a country sometimes can represent where the payroll is located but not where the person works. The only valid filter condition is their assigned Teams phone number, so we use that as one of the conditions to do filtering.

Membership Rule Syntax

(user.department -eq “Consulting”)

The rule finds users where their department is Consulting and whose phone number starts with +852.

In many cases, dynamic groups eliminate the need to manage group memberships. Users are members of a group as long as the value of the property used by the membership rule is set correctly for their account. But usually, the issue is that some attributes are missing, spelled incorrectly, or not synchronized from on-premises Active Directory.

Dynamic groups are often used with Microsoft 365 administrations. As group membership grants access to resources such as a SharePoint site, a typo in the member query may lead to the addition of incorrect users to the group and result in inadvertent data leakage. The same issue exists for other parts of Microsoft 365 functions, like Dynamic Administrative Units and adaptive scopes for users and groups. This article covers how to standardize the account creation process to avoid problems with dynamic membership based on incorrect account properties.

Create a List of Special User Accounts

Some dynamic groups are created for administrative purposes. One example we often use when setting up Microsoft 365 tenants is configuring dynamic groups with a membership composed of special user accounts, like Guest Users, as shown in Figure 2. I also added a condition to only fetch Guest users, which was created because of App1 that my client put in extensionAttribute1. This condition can be anything, but it just so happens they used that attribute.

Query Syntax

(user.userType -eq “Guest”) and (user.extensionAttribute1 -eq “App1”)

The rule finds accounts which userType equals to Guest (i.e. guest user accounts) and with value “App1” assigned to extensionAttribute1

One client asked us to create a conditional access policy to block access from shared mailboxes and meeting rooms. We know those accounts are disabled and do not have access to any system, but my client wanted to play it safe and have a blocking policy for these accounts. At the moment, no Entra ID attribute exists to identify shared mailboxes, so we have to come up with another way, such as using an account name prefix or one of the fifteen custom attributes.

Create a List of Devices from the Intune Inventory

When we deploy Intune, often we have a requirement to implement apps or configurations only for specific platforms. For example, we only want to deploy Microsoft 365 Apps to macOS. The easiest way to do this is to set up a dynamic group based on the attributes gathered via the Intune inventory process. Figure 3 shows an example of a dynamic group defined to include all macOS devices in a tenant.

Query Syntex

device.deviceOSType -eq “MacMDM” -or device.deviceOSType -eq “MacOS”

The rule finds the list of devices where the deviceOSType is equal to either MacMDM or MacOS

I usually create several dynamic groups to classify devices like the following to allow us to target the configuration or apps to specific platforms:

• All x64 Devices
• All arm64 Devices
• All macOS Devices
• All Corporate Managed iOS devices
• All Android for Works devices

Create a List of Devices Based on Management Type

Another common scenario is using dynamic groups to identify the devices managed by SCCM. This group can be used to exclude some app deployments or configurations via Intune as SCCM already manages them. Figure 4 shows a group containing only Windows devices managed by Intune.

Query Syntax

(device.deviceManagementAppId -eq “0000000a-0000-0000-c000-000000000000”) -and (device.deviceOSType -eq “Windows”)

The rule finds devices where deviceManagementAppID is equal to the value explained here and their deviceOSType is Windows

Create a List of Users Based on Specific License Type

The final use case is how to define a query based on an assigned Microsoft 365 license or service plan. The administrator can use these kinds of dynamic groups to identify specific users with certain licenses, like Entra ID Premium P1 or P2, and only allow the use of Self Service Password Reset. Figure 5 shows a dynamic group including users that have an Intune license assigned.

Query Syntax

user.assignedPlans -any (assignedPlan.servicePlanId -eq “41781fb2-bc02-4b7c-bd55-b576c07bb09d” -and assignedPlan.capabilityStatus -eq “Enabled”)

The rule finds users where the assignedPlan equals 41781fb2-bc02-4b7c-bd55-b576c07bb09d and is enabled. The full list of the service plan ID and license info for use in this situation can be found here.

Things to be Aware of When Using Dynamic Groups

There are a few items about the behavior of dynamic groups in Microsoft 365 that you should be aware of before deciding if you should use dynamic groups instead of static groups.

• A Microsoft 365 Group cannot include another group. In Microsoft 365, adding a new dynamic groups to a Microsoft 365 Group takes a snapshot of the current membership and adds each member account individually. Make sure you define the dynamic group membership rule to include all the users needed or add the members individually.
• Test and evaluate the rules. After editing the membership rule for a dynamic group, always do a test to confirm the rule works and gives you the exact results. You can use the Validate Rules tool in the dynamic group editor to select the users to see if they will be included in the group as shown in Figure 6. Remember to pick users that should be included and should not be included for testing.

• Entra ID only updates the group members at intervals. In the early days, Azure AD evaluated dynamic group membership in real-time. Now that is no longer the case. This is to reduce the resources consumed to compute group membership on the Microsoft 365 backend. Entra ID now computes the membership of dynamic groups periodically. When applications need to check the membership list, they use the cached copy. Newly created users do not appear in dynamic groups immediately. You can also check the last updated time in the Entra ID portal by opening the group properties as shown in Figure 7. Do pay attention if the list is not updated over 24 hours or if new users are not added to the list after 24 hours.

• Be careful of accidentally including system/service accounts. Administrators may define membership rules that include system users, service accounts, or guest users. Review the membership list and ensure the resultant list is what you wanted. You can do that by regularly checking group membership in the Entra ID admin center or with Microsoft 365’s Access Review. Access Reviews require an additional license (Entra ID P2 or Entra ID Governance).
• Users require Entra ID P1 or above to be included in Dynamic Groups. Some administrators often overlook this one. You cannot use dynamic groups if you do not have Entra ID P1 licenses, but the way it works is tricky. Entra ID will allow you to create dynamic groups, but it won’t add members if there aren’t enough licenses in the tenant.
• Pause processing before performing large changes in Entra ID. Before you make large numbers (such as those affecting over 500 users) of updates to Entra ID accounts, consider pausing dynamic group processing and manually triggering updates to dynamic groups after the update is concluded. You can pause, resume, and manually update as part of your update script via Graph API or PowerShell. Pausing helps to avoid the potential for including incorrect information in group memberships. Eventually, Entra ID will resolve the problems, but it’s as well not to hit an issue.

Making Good Use of Dynamic Groups

Dynamic groups are a powerful tool for administrators. Recently Microsoft added support for additional properties used in membership rules for dynamic groups. Before creating a membership rule, check the latest list of supported attributes. Also pay attention to some tips shared by Microsoft to make membership rules more efficient, especially for large Microsoft 365 tenants.