Over time, as Microsoft 365 environments grow, managing users and devices can become increasingly complex. Instead of manually adding users to groups every time a new one joins, dynamic groups can make the process easier. In this article, we’ll explore why using dynamic groups—whether they are security groups, Microsoft 365 Groups, or dynamic distribution lists—can be beneficial, along with a few things to keep in mind when setting them up.
One key point is that dynamic distribution lists are specific to Exchange Online. They won’t show up in the Entra ID admin center or in the results of Microsoft Graph queries. Exchange Online automatically calculates the membership of these lists based on mail-enabled objects in its directory.
Before diving into some typical use cases for dynamic groups, let’s quickly recap what they are. Unlike static groups, dynamic groups don’t have fixed members. Their membership is defined by rules set within the group’s properties. Microsoft 365 Groups can have dynamic membership based on either users or devices, but not both. If needed, you can convert a static group to a dynamic one, but doing so will remove its current members. It might be wiser to create a new dynamic group and rename it—along with its primary SMTP address—so that you can retain the old group’s information. It’s also important to know that dynamic distribution lists cannot be renamed.
To use dynamic Microsoft 365 groups, every account that falls under the membership rules must have an Entra ID P1 license.
Creating Dynamic Groups Based on Attribute Values
One of the most common reasons for using dynamic groups is to automatically add members based on certain attribute values. For example, you could create a rule that includes users whose department is listed as “Consulting” and whose phone number starts with +852 (as shown in Figure 1). You might wonder why we include phone numbers in this rule. In some cases, country attributes can indicate where a person is paid from, rather than where they actually work. The assigned Teams phone number provides a more accurate filter, which is why it’s used in this case.
In many cases, dynamic groups take the hassle out of managing group memberships. As long as a user’s account has the correct attribute values, they will automatically be part of the group. However, issues often arise when attributes are missing, misspelled, or not properly synced from an on-premises Active Directory.
Dynamic groups are commonly used by Microsoft 365 admins, and since group membership can grant access to resources like SharePoint sites, even a small typo in the membership rule can add the wrong users to the group—potentially leading to unintentional data exposure. This is a concern not just for groups, but also for other Microsoft 365 features like Dynamic Administrative Units and adaptive scopes for users and groups. To prevent issues with dynamic membership caused by incorrect account details, it’s crucial to standardize the account creation process.
Creating a List of Special User Accounts
Some dynamic groups are designed for specific administrative purposes. A common setup when configuring Microsoft 365 tenants is creating dynamic groups for special user accounts, like Guest Users. In Figure 2, for example, I added a condition to filter only Guest users, using a specific attribute (extensionAttribute1) for one client’s setup. This condition can vary, but in this case, they used that attribute to differentiate Guest users.
The rule identifies accounts where the userType is set to “Guest” (i.e., guest user accounts) and the extensionAttribute1 is assigned the value “App1.”
One client asked us to create a conditional access policy to block shared mailboxes and meeting room accounts. While we know these accounts are disabled and don’t have system access, the client wanted to be extra cautious by implementing a blocking policy. Currently, there’s no specific Entra ID attribute to identify shared mailboxes, so we had to get creative. We used alternatives like a naming convention or one of the fifteen available custom attributes to identify these accounts.
Creating a List of Devices from the Intune Inventory
When deploying Intune, there’s often a need to apply apps or configurations to specific platforms. For instance, you might only want to install Microsoft 365 Apps on macOS devices. The simplest way to achieve this is by setting up a dynamic group based on the device attributes collected through Intune’s inventory. Figure 3 illustrates an example of a dynamic group that includes all macOS devices within a tenant.
Creating a List of Devices Based on Management Type
Another common use for dynamic groups is identifying devices managed by SCCM. These groups can help exclude certain app deployments or configurations from Intune since SCCM is already handling them. For example, Figure 4 shows a dynamic group that includes only Windows devices managed by Intune. This setup allows for more efficient management by ensuring that devices already covered by SCCM don’t receive duplicate configurations.
Creating a List of Users Based on Specific License Type
Another useful scenario for dynamic groups is identifying users based on their assigned Microsoft 365 license or service plan. Administrators can set up dynamic groups to filter users with specific licenses, like Entra ID Premium P1 or P2, and apply policies such as allowing only these users to use Self Service Password Reset. For instance, Figure 5 shows a dynamic group that includes users with an assigned Intune license. This approach makes it easy to manage and apply targeted configurations based on users’ licenses.
Things to Keep in Mind When Using Dynamic Groups
Before choosing to use dynamic groups instead of static ones in Microsoft 365, there are a few important points to consider:
- 1.A Microsoft 365 Group cannot contain another group. When you try to add a dynamic group to a Microsoft 365 Group, it essentially takes a snapshot of the current members and adds them individually. So, ensure the dynamic group’s membership rule is set up to include all the necessary users, or add the members manually.
- 2. Always test and evaluate your rules. After making changes to a dynamic group’s membership rule, it’s important to test it to ensure it’s working correctly. You can use the “Validate Rules” tool in the dynamic group editor to check if the users are being included as expected. Make sure to test with users who should and shouldn’t be part of the group to verify accurate results, as shown in Figure 6.
Dynamic Group Updates in Entra ID
Entra ID no longer updates dynamic group membership in real-time, as it did in the early days of Azure AD. This change was made to reduce the resource load on the Microsoft 365 backend. Now, Entra ID updates dynamic group membership at set intervals, and applications rely on a cached version of the membership list. This means newly created users won’t appear in dynamic groups immediately.
You can check the last update time in the Entra ID portal by viewing the group properties, as shown in Figure 7. If the list hasn’t been updated in over 24 hours or if new users haven’t been added within that time frame, it’s worth investigating further.
Important Considerations When Using Dynamic Groups
- Avoid including system or service accounts by mistake. Administrators might unintentionally define membership rules that include system users, service accounts, or guest users. To prevent this, regularly review the group’s membership list to ensure it only includes the intended users. You can do this by checking the Entra ID admin center or using Microsoft 365’s Access Review feature (which requires an Entra ID P2 or Entra ID Governance license).
- Licensing requirements for dynamic groups. It’s easy to overlook that Entra ID P1 or higher licenses are needed for users to be included in dynamic groups. While Entra ID allows you to create dynamic groups, it won’t add members if there aren’t enough licenses in your tenant. So, make sure you have sufficient Entra ID P1 licenses to fully utilize dynamic groups.
- Pause processing before making large updates. If you’re updating more than 500 Entra ID accounts, it’s a good idea to pause dynamic group processing temporarily. After completing your updates, you can manually trigger updates to the dynamic groups. This can be done using the Graph API or PowerShell. Pausing helps prevent issues like incorrect data being added to group memberships. Although Entra ID will eventually resolve these problems, it’s better to avoid them from the start.
Maximizing the Use of Dynamic Groups
Dynamic groups are a powerful tool for administrators, and Microsoft has recently expanded the range of properties you can use in membership rules. Before creating a rule, check the latest list of supported attributes. Microsoft also shares tips for making membership rules more efficient, which can be especially useful for managing large Microsoft 365 environments.
