Dynamic groups in Azure and Intune come in Dynamic User Groups and Dynamic Device Groups. Members in a dynamic group are automatically added and removed, according to the membership rule. They are a highly efficient way to organize devices and users. They enable you to deploy scripts, apps, and configuration profiles with a set-and-forget mentality. Once you have configured the rule with expressions or even more advanced with a custom rule syntax, you don’t have to worry about the membership anymore.
In this blog post, I’ll focus on basic rules, using the rule builder, and advanced rules using the rule syntax editor
Table of Contents
How to create a dynamic group
The first step is to create a dynamic group. Interfaces in Intune are quite similar to Azure Entra ID. I’ll stick to Intune in this post.
- In the Intune portal, click Groups.
- At the top, click New group
- In the New group blade, you must
- select a Group type: Security, Microsoft 365
- enter a Group name
- select a Membership type: Assigned, Dynamic Device, Dynamic User
For convenience, we choose Security as group type. This allows us to work with devices as well as users. A Microsoft 365 group is useful for collaboration purposes, like sharing a file, or a calendar. Microsoft 365 groups cannot contain devices as a member.
The Group name should be very indicative. All Windows devices is mediocre in my opinion. It is likely you’re going to make some nuances in the Rule Builder, like Windows 10 or Windows 11, laptops or desktops, Azure-joined devices or Azure Registered, et cetera. We will not be diving into the naming convention dilemma in this blog post. But you should definitely have some ideas in mind. I prefer starting with the type of group, like DDG (Dynamic Device Group) or DUG (Dynamic User Group), continuing with AAD (Azure AD) or OP (OnPrem), target type (like Managed App or Script), target name, and optionally the action it fulfills.
For example, if I need to deploy an application called Teamviewer to a bunch of users, the group name would be something like DUG_AAD_MA_Teamviewer_Install . So it’s a Dynamic User Group in Azure AD, targetting the Managed App Teamviewer, and when you are in the group, it will Install
In the Membership Type dropdown box, select Dynamic Device or Dynamic User. You will notice the Members section underneath shows Add dynamic query. Click on the Add dynamic query link to start creating a rule
Creating a basic rule for a dynamic group using the rule builder
A basic rule is quite easy. As long as you know what you want to harvest 🙂
As opposed to Security groups, Dynamic groups cannot mix users and devices. That’s a blessing because blending them into one group is asking for problems in the long term.
To create a Dynamic Device Group that contains all Lenovo systems, create this query:
(device.deviceManufacturer -eq "Lenovo")
In case you want all Lenovo systems with Windows installed, configure this rule:
(device.deviceManufacturer -eq "Lenovo") and (device.deviceOSType -eq "Windows")
Creating an advanced rule for a dynamic group using
Advanced rules often imply you need to edit the rule syntax text. Some properties are not selectable in the dropdown list, while you can query them in the rule syntax. I.e. Member of. Other scenarios require you to get creative, combining and and or. Last but not least, the Rule Builder allows you to only have 5 conditions specified. If you want more, you must use the syntax editor.
For example, the following Rule syntax returns all Lenovo devices. And all HP devices that start with Desktop as the device name
(device.deviceManufacturer -eq "Lenovo") or (device.deviceManufacturer -eq "HP") and (device.displayName -startsWith "DESKTOP")
If I meant to only both HP and Lenovo devices as members, but only when the device name starts with DESKTOP, we have two options.
Using double parentheses
(device.displayName -startsWith "DESKTOP") and ((device.deviceManufacturer -eq "Lenovo") or (device.deviceManufacturer -eq "HP"))
Note the double parentheses (( and )), enclosing the Lenovo and HP query. This creates 2 conditions: The first condition is the name DESKTOP. The second condition is the brand, either HP or Lenovo (one of the two is sufficient)
Using the IN operator
(device.displayName -startsWith "DESKTOP") and (device.deviceManufacturer -in ["Lenovo","HP"])
This option with the IN operator tells the condition to be true if the device.deviceManufacturer is in the list of values [“Lenovo”,”HP”]. I think this syntax is much smoother, although it requires a little bit more expertise. A great benefit, however, is that you select it from the dropdown box in the Rule Builder.
Examples of advanced rule syntaxes
Here’s a list of queries that can be beneficial when you need to create your own query. I will extend this list as I face new challenges in my day to day work
|SCCM managed Windows Devices||(device.deviceOSType -eq “Windows”) and (device.deviceManagementAppId -eq “54b943f8-d761-4f8d-951e-9cea1846db5a”)|
|Intune Managed Windows Devices||(device.deviceOSType -eq “Windows”) and (device.deviceManagementAppId -eq “0000000a-0000-0000-c000-000000000000”)|
|Intune Managed MacOS devices||(device.deviceManagementAppId -contains “0000000a-0000-0000-c000-000000000000”) and (device.deviceOSType -contains “macMDM”)|
Force processing Dynamic Groups
The update interval for Dynamic Groups can be unpredictable. In my experience, the first Dynamic Rule Processing action kicks off quite fast. Results are there within a few minutes. However, when you update the query afterwards it doesn’t always trigger a new processing action.
One option is to add a blank space at the end of your query. Go to the rule syntax, click edit, click the cursor at the end of your query, and hit the space bar. Then click Save.
The second, and best option is to create a 100% correct query on your first attempt. How? By using the Validate Rules option. Read all about it in the next paragraph
The Validate Rules (Preview) option is a lifesaver for complex queries. Before you click Save, go to Validate Rules. Click Add devices, and look for a few devices with deviating properties. Then click Validate.
In this example, the first desktop fails during the validation. To inspect what condition is false, click View Details. The Verification Details exactly show you what attribute values the device has, what value was needed for the condition to be true, and the end result (green mark or red cross)
In this particular case, the name matched the condition. But the deviceManufacturer (Dell. Inc.) was not in the conditions list (HP and Lenovo). So the validation fails and the device will not be added as a member of the group. If it was a member of the group, it would be automatically removed.
Tips to make this post better
That’s pretty much everything I wanted to share. If you have any questions or tips, please leave a comment. It will help me make this post even better, and others will also greatly benefit from this information.
And by the way, currently, I’m heavily planning on writing new blog posts about Intune. Make sure to check them out if you liked this blog post about Dynamic Groups!