By Alvin Tsou | PM, Intune
We’re almost done with the migrations from Intune groups to Azure Active Directory (Azure AD) groups, so we’re posting a major update to this blog post. We have only a few hundred tenants that are blocked due to issues on our side, and we are working tirelessly to fix those and get those accounts migrated. We still have a few thousand of you, though, that are blocked from migrating due to issues that we can’t fix on our side because we can’t reproduce your current configuration.
If you haven’t migrated yet, we need you to go to the Office Message Center, login with your admin credentials, and check for messages that start with Intune Migration. If your migration will not go forward due to the presence of the configuration issues below, we posted a message to you today. (If you managed to fix between the time we last pulled the migration status and the time we posted, please ignore the message(s).)
What happens if I don’t fix my migration issues?
We’ll keep trying to migrate you, hoping that you’ve fixed any configuration issues that blocked your migration. We’ll try to reach you using the Message Center to let you know which issues are blocking you. If we have an email address we can use to contact you for things like this, we’ll even try to send you mail. Eventually we’ll have to migrate you anyway, even though things won’t work the same going forward.
After June 30, we’ll start doing “snapshot” migrations for all group issues. We’ll look at your problematic groups and copy the members at the time of migration into an assigned (static) AAD security group. Post-migration, the membership of the group will not automatically change.
If you are blocked by an outdated Exchange connector, your Exchange connector won’t work after we migrate you. We’ll hold off on that until after June 30.
Why should I care if I get a snapshot migration?
Dynamic groups in Azure AD make life easier for admins. When a user or device meet certain criteria, they are automatically added to the dynamic group and automatically get policies, apps, and terms and conditions that are deployed to that dynamic group. If you had an Intune group that used to update dynamically but is migrated as a static group as part of a snapshot migration, your newly added users and devices won’t automatically get deployments.
For example, if you had an Intune group that included everyone on the Sales team but excluded the user Joey Maxfield, the “snapshot” group would be migrated as a flat list of users in Sales – minus Joey, so he won’t get the deployments he used to get. If, post migration, a new user Terri Richards joins the Sales team, she would not be automatically added to the static Sales group and would not receive apps, policy, or terms and conditions targeted to that group. You may be OK with this, or you may not.
We’ll let you know in the Message Center sometime after June 30 if we had to do a snapshot migration, so you can decide what to do about that going forward.
Configurations that block Intune migration
Here are all the known configurations that could be blocking your migration. We’ll start with an overview, and then we’ll include links to step-by-step information on how to fix each issue.
1- Deployments to Ungrouped Users/Devices
In our previous administrative console experience, we automatically grouped users and devices that were enrolled, but not yet a member of any deployment group. Respectively, we called these dynamic groups “Ungrouped Users” and “Ungrouped Devices”. Once the user or device was placed into the desired group, it would disappear from the respective ungrouped group.
If you target any deployment – apps, policy, terms and conditions – to these groups, it will delay your migration until the payload is removed, or until we pass the migration deadline of June 30 and start doing snapshot migrations as described above.
2- Exclusion Clauses in Groups
The way grouping works now, you can create security groups in https://portal.office.com or https://portal.azure.com, but you can’t target any policy or apps to those groups in Intune. Instead, you create Intune groups that can use security groups as the source of membership, then target your policies to these groups. (After the migration, you’ll be able to target your policies directly to the security groups.)
Intune currently supports the concept of creating a group that excludes members of an Azure AD Security group, or specific users. If your Intune groups have exclusion criteria, Intune won’t be able to migrate them because there’s no equivalent way to exclusion groups in Azure AD. However, there is a way to create a dynamic user or device group that can exclude based on attributes.
Here is an example of an exclusion group: You could have an Intune group called All Continental US Users by starting with All US Users and excluding the security group All Alaska Users and All Hawaii Users. This could also be achieved in an additive manner by creating security groups for each state and not including Alaska and Hawaii as members.
3 –Nested Groups (also called Implicit Exclusion Groups)
Even if you never use the exclude button on your criteria membership, you create a nested (also called implicit) exclude if you do the following:
- Create a group that does not use All Users as the parent group.
- Start with an empty group on the criteria membership page.
- Include one or more security groups.
In this case, the users of the new group must be a member of the parent group and satisfy the criteria for this group. This concept is not supported in Azure AD, because they do not follow a strict tree structure for groups.
For example, let’s say you want a group called US Marketing. You already have an Intune group called All US Users, and a security group called Worldwide Marketing. When you create your Intune group called US Marketing, you:
- Set the parent group to All US Users.
- Start with an empty group on the criteria membership page.
- Include Worldwide Marketing.
This group will only include members that are part of the All US Users group and are a member of the Worldwide Marketing group.
Nested groups are often misunderstood in Intune. Oftentimes, the intention was to create hierarchies; in actuality, nested groups limit group membership by their parent, and are not meant to be used for organizing the console.
A child group cannot have any more members than the parent group. For example, let’s say you have 100 users in All users, and 10 users in a group called “Parent”. If you create a nested group under “Parent”, whatever the membership criteria you use (AD group membership for example) will be limited to the 10 users found in the “Parent” group.
4- Groups Using the ‘Is Manager’ Clause
Intune used to allow you to create a target group where one of the criteria is a Manager. This feature was deprecated a while back, but if the clause still exists in your Intune setup, you have to remove it, or your account will fail the migration pre-check.
Note: this configuration is so old, we aren’t notifying accounts about this one. Only a few account still have these, but we’re including it here just in case.
5- Conflicting App Deployment Rules
Your migration may be blocked if you have app deployments to groups where the deployment intent conflicts with a child group’s deployment intent, and a user is a member of both the parent and the child group.
App deployment intent describes how an app is targeted at a user; be it Install Required, Install Available, Uninstall or Not Applicable.
For example, you have a group called Outlook – Uninstall underneath All Users, and you deploy Outlook as a Required install to All Users but deploy Outlook as Uninstall to the Outlook -Uninstall child group, there’s a conflict. Before the migration, anyone in the Outlook – Uninstall group won’t get Outlook, but after the migration, all those users will get Outlook as a Required app.
6 –Using an Old Version (Prior To December 2016) of the Exchange Connector for Intune
You can fix this by updating to the latest Exchange connector version of Intune. Why does this block migration? Since the Intune on Azure is a new infrastructure in the back end, the Exchange connector has been updated to connect to the new infrastructure.
7 – Self-Service Group Management in Azure AD is disabled
Intune uses the ‘Self-services group management’ feature of Azure Active Directory (Azure AD) to migrate your Intune groups into Azure AD. If you’ve disabled self-service group management, you will need to enable it until your Intune migration is complete.
We hope this post is useful to summarize all up the blockers that could impact your migration to the new grouping and targeting experience. Remove all of your blocking issues, and then be patient. We retry all blocked migrations every 24 hours, but depending on how complex your account is, it may take a few days to create all the new Azure AD groups, remap all of your policies, terms and conditions, and apps to the new groups, and then verify that we got everything right. After migration has started, we unfortunately don’t have a way to tell you how long it will take.
We plan to introduce a new way to handle exclusions in a future release – we’ll update this blog when we have more information.
After June 30, be prepared for snapshot migrations. Watch the Office Message Center for posts saying you’ve been snapshot migrated, and go take stock of your new Azure AD groups to make sure your policies, terms and conditions, and apps will be targeted to the right users and devices.
We look forward to getting you onto the new Intune on Azure experience as soon as possible!