October 2024

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: 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.