One of the biggest changes to Microsoft Intune this year is the way that Grouping and Targeting works. If your reading this post, you might be in a situation where your migration is blocked due to “Exclude Groups”, or you have migrated and now trying to work out how to regain the “Exclude” functionality.
The intent of this post is to discuss the ways that you can achieve similar “Exclude” functionality once your tenant is migrated.
Consider this scenario:
You are currently synchronising an “All Corporate Users” group to Azure Active Directory from your organisations on premises directory. You have an old-school “Intune” group based on this Azure AD Group, but used the ‘Exclude’ feature to ensure that the “VIP’s” (Very Important People) group were exempt from some of the more restrictive device policies.
Firstly, if you had this configuration your tenant would not have migrated automatically – You would have had some notification in the office 365 admin centre letting you know some action was needed on your behalf to remove the blocker before your tenant could be migrated. See this post.
Once your tenant has successfully migrated, There are a couple of options for achieving your desired result: VIP’s not getting the same profiles/policy’s as everyone else.
You could either make use of the new “Exempt” feature of policy deployment (Released May 2017), or use Azure AD dynamic groups.
Option 1: Use the new “Exempt” feature in Intune
This feature is likely the best solution to use in the scenario I described above. For all profile deployments, we can now choose to deploy to one more groups, but then exclude others.
Using the same example, I can deploy Device Restriction policies to my “All Corporate Users” group, but exempt the “VIP’s” group.
Note: This is only available in Profile Deployments (Device Restrictions, WI-FI Profiles, Certificates etc), not Compliance Policies or app deployment.
If you are trying to achieve the same result for App deployment where there is no “Exempt” blade, but you can could use a combination of “Available” and “Not Applicable” to achieve the desired results.
Note: The intent of the app deployment must be set to “Available” for the “Not Applicable” to override. If an app is deployed as “Required”, the app would still be deployed to users in the VIP’s group in this example.
Option 2: Use Azure AD Dynamic Groups to create a new group to meet your intune needs
The other option is to create a brand-new Azure AD Group with the dynamic groups feature of Azure AD.
To create a new Azure AD Group, go to https://portal.azure.com, Azure Active Directory, Users and Groups, All Groups, New Group
Add a name, select Dynamic User Group, Add dynamic Query
Example Dynamic Query
(user.accountEnabled -eq True) -and (user.userPrincipalName -notIn [“CEO@exlab99.onmicrosoft.com”, “VIP1@exlab99.onmicrosoft.com”, “VIP2@exlab99.onmicrosoft.com”])
Note: Dynamic groups don’t allow you to piece together multiple groups. I’m not able to say “New Group contains all users in “All Corporate Users” group but not “VIP’s” group.
Instead in this example I used the “AccountEnabled” attribute to select the big pool of users (who’s accounts are enabled), then exclude individual user accounts by User Principal Name.
Or another common example:
(user.userPrincipalName -ne $null) -and (user.country -ne “GB”)
This group would contain all Users, Except for the UK-based ones.
Once you are happy with your query, Click Add Query, then Create. If there are no errors, head to the Members blade to ensure its populated correctly.
Note: If you have a large group (over 1000 members), you will need to use Azure AD Powershell to list out the members of the group.
Get-AzureADGroup -SearchString “All Corporate Users (VIP’s Exempt)” | Get-AzureADGroupMember
After your group is created your free to go link profiles, policies and apps to it.
One word of caution: Be careful when you edit the Membership rule as after you do so, all members of the group will be removed and then re-added using the new details. If this is a massive group, this could take a little while and could also impact users. For example, if you were using a dynamic group to deploy Root Certificates for iOS devices, then decided to update the membership rule later on, Certificates would be removed from the users impacted by the policy and not re-added until the dynamic group has been completely built and the device processes policy again.
With all that said, There is one other option that doesn’t use any of these new features: Re-design your on-prem Intune groups to best support the linking of policies and profiles. Consider using smaller subsets of user groups so that there is no need to “Exclude” at all.
Instead of “All Corporate Users“, try multiple smaller groups: