A few days back it was announced that there was a new expression available that could be used to nest groups within Intune. There was some talk about how useful it may be since nesting groups using direct assignments has been available for some time.
So, I thought I’d give it a try. When I did, I found some tidbits that makes this (in my opinion) the superior option.
The ability to nest groups has been around for a while. You can create an “assigned” group and then specify other groups as the members. This though introduces a problem. You can easily add groups that contain users and devices, the end result being a parent group that contains both users and devices. This is something that is highly discouraged.
Scott Duffey made the announcement on Twitter that there was a new attribute available to nest groups inside of dynamic groups; MemberOf.
The syntax is fairly straightforward:
user.memberof -any (group.objectId -in ['groupId', 'groupId'])
In the above case we’re checking to see if the user is a “member of” any groups defined by an array of group IDs.
Since this requires a dynamic group, this immediately addresses the concern of mixing group types in the parent group. If the parent group is defined as a Dynamic User group, then you should not be able to then “nest” in a device group.
Here is a catch. If you create a Dynamic User group and then provide a MemberOf query that points to a group of devices, Intune will automatically change the group type from Dynamic User to Dynamic Device. If you attempt to combine a device.memberof with a user.memberof (see below) then Intune accepts the first expression (changing the group type to match) and then ignores the second expression.
device.memberof -any (group.objectId -in ['8ba5da37-adf1-4688-8ea3-bce3962c59e6']) -or user.memberof -any (group.objectId -in [''973147ab-3b90-4f0a-8d5f-e088eb7ccc3f'])
This makes sense when taken alongside one of the limitations listed in the documentation.
It states that MemberOf expressions cannot be combined with other expressions.
So, keep this in mind when using the new attribute.
Advantages Over Assigned Nested Groups
This is a good one. If you use the “traditional” method of nesting groups, the group membership of the parent group does not reflect the nested members. Nor does the group membership show up on the properties of the object in Azure AD.
Scenario: Dodge, Kansas has implemented Intune for the town. They need a group that will contain the main characters from the show. You need to create a Dynamic User group named “Users – Gunsmoke Main Characters” that pulls in the main characters.
The following groups already exist:
|Users – Gunsmoke Marshal’s Office||The marshal and his deputies:|
|Users – Gunsmoke Doc’s Office||Doc Adams’ office:|
Dr Galen Adams
|Users – Gunsmoke Guest Stars||Guest stars of the show:|
Quint Asper (played by Burt Reynolds) was the town blacksmith and occasionally deputized when needed. The guest stars group will be nested (using the “traditional” method) in the group for the marshal’s office to reflect this.
The intended result would be that the “Users – Gunsmoke Main Characters” will have these members:
- Matt Dillon
- Chester Goode
- Festus Hagan
- Galan Adams
Attempt 1: Directly Assigned Nested Groups
This is the “traditional” method of nesting groups. After creating the “Users – Gunsmoke Main Characters” parent group, I assigned the Marshal’s Office and Doc’s Office groups as members.
If you check the Overview of the group, it shows 8 members.
Wait! What? Why eight members? It is pulling in all 5 cast members (including Quint Asper) and all 3 groups, for a total of 8 members.
Plus, if you look at the Members list (see the screenshot above) you only see the 2 nested groups and none of the users. If that isn’t bad enough, the Guest Stars group, nested inside of the Marshal’s Office is also a member but you would not see that by looking at this view.
Let’s take a look at one of these users in Azure AD…
It only shows that Matt Dillon is a member of the Marshal’s Office group. It does not show that, due to nesting, he is also a member of the Main Characters group.
Attempt 2: Dynamic MemberOf Nested Groups
Let’s try this again only this time we’ll use the new MemberOf attribute. I created a second Main Characters group configured as a Dynamic User group. This is the query I used (MemberOf is not currently supported when using the query builder).
user.memberof -any (group.objectId -in ['fed4323f-1f74-4810-b0fc-e0797d17d87d', '2203395d-5356-4533-ae92-512bbe01d79d'])
This time the membership of the new parent group shows the expected 4 cast memebers.
You may be asking, why isn’t Quint Asper a member? The MemberOf attribute does not recurse sub-groups. This is not directly called out in the documentation from Microsoft but alluded to in one of the images illustrating the feature.
As shown in the first attempt, when using the “traditional” nested group option objects do not report that they are indeed members of parent groups. They only know and report that they are members of the sub-group. This then would be the response from the MemberOf query. Using the above image as an example, in plain language the query asks, “Is ‘member6’ a MemberOf ‘Security-Group-X’?” The answer would be “No”, because the object is only aware of the groups that it is explicitly a member of. It is unaware of any let’s say “shadow” memberships due to nesting.
If we look at the Overview, the count is also correct and accurate.
Now if we check Matt Dillon in Azure AD…
It too properly reflects Matt’s group memberships.
Why the difference?
It’s rather simple when you think about it. When using the MemberOf attribute, the objects (users in this example) become members of the parent group. The query brings them in just like any other query would. In the case of the “traditional” nested group, while Intune recognizes that objects in the sub-groups belong to the parent group, the underlying code does not handle displaying the information properly. In fact, the user object is not directly aware of the membership in the parent group. It’s membership in the parent group is by association.
This new attribute in Preview and was only made available a few days ago, so a lot can change between now and the final product.