Intune Migration Blockers for Grouping & Targeting

By Alvin Tsou | PM, Intune

Migrations are underway for existing Intune standalone customers to move from Intune Grouping and Targeting to Azure AD grouping and targeting. We’ve written quite a bit of documentation that will help you think through the before and after grouping experience (read more here). The good news is that once you’re migrated to Azure AD grouping, you will have a whole new grouping and targeting experience on Azure AD – which will give you features such as Dynamic Grouping. However, there are a few scenarios that can’t be migrated as they are structured differently over in Azure AD or will not work as expected once migrated over.

In this post, we share the buckets of migration blockers that our pre-migration checker is finding. If you fail the pre-migration check, your account can’t get migrated. But, if you remove all migration blockers before we start on your groups, you may end up back in the queue with no migration delay. Many of these scenarios customers used below are workarounds for not having true dynamic grouping in Intune. We’re happy to report that customers who have removed the blockers have been successfully migrated.

By the way, if you’re reading this post and wondering whether you have any of the items below in place, head to the Office Message Center, login with your admin credentials, and check your messages. If your migration will not go forward due to the presence of any of the scenarios below, we posted a message to you. We will also be following up if we couldn’t migrate you with additional instructions. Finally, tenants are not scheduled by date, but rather picked by an algorithm that assesses the complexity of the tenant. Less complex tenants will be migrated first, while the most complex will go near the end. Again, the Office Message Center will have a post when your scale unit or tenant is close to migrating.

Here’s the top migration blockers.

1- Policies or apps targeted to ungrouped users/devices. Today in Intune, we allow you to target policies to non-groups – essentially those devices or users that haven’t been placed anywhere and are just sitting in the All Users bucket. Moving forward, over in Azure AD, you can use dynamic groups to automatically assign devices and users directly into groups. But targeting has to be done at a group level. To remove this blocker, you’ll need want to move your ungrouped users and devices into the desired groups. In addition, you’ll also want to remove anything you’ve targeted, such as policies, applications, or terms of use, to those ungrouped users or devices. Just expect that when you move a device or user from one group to another, the policy will be applied according to the group you move the device into. Note that with all these migration blockers, you don’t want to go back and add in blockers after you’ve removed them.

2- Using Exclusion 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 by including or excluding your security groups from a parent group and targeting your policies to the Intune groups. (After the migration, you’ll be able to target your policies directly to the security groups.)

If your Intune groups are created by excluding security groups, Intune won’t be able to migrate them yet because there’s no equivalent way to exclude groups in Azure AD. For example, you could have an Intune group called All US Users by starting with All Users and excluding the security group All EU Users, but that exclusion would delay your migration because the process can’t create a dynamic group with the same result. Again, when you remove your exclude groups, remember that the exclude group and your policies and anything else you’ve targeted to that exclude group – those also need to be removed.

3 – Using 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:

1. Create a group that doesn’t use All Users as the parent group.
2. Start with an empty group on the criteria membership page.
3. Include one or more security 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:

1. Set the parent group to All US Users.
2. Start with an empty group on the criteria membership page.
3. Include Worldwide Marketing.

Because you are using the parent group All US Users, you are excluding any Marketing employees not based in the United States.

4- Any 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.

5- You have conflicting App deployment rules. In Intune, you could have targeted an app to all users except a specific group that’s a child of the group targeted. Since the app policies differ, and the exception group is a child of the users group, then this also keeps deployment from moving over. An easy way to fix this setup is to create a new group, target the policies and apps as you intend, then move over the child group into its own group. You can read other ways of accomplishing this here.

6 –You are 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. You can find more information on how to update your Intune Exchange Connector in the doc’s here.

Once you pass the migration pre-check, then we’ll pre-populate your groups in Azure AD, migrate your groups and targeting, and then run a consistency checker to make sure everything you had in Intune old groups moved as expected to the new groups, including policies targeted to devices, groups, and more. Then we finally cut you over to the new experience.

We hope this post is useful to summarize all up the blockers that could impact your migration to the new grouping and targeting experience. Look for a notice in the Office Message Center before you’re migrated, then once you are migrated you should see a banner in console and when you click on the groups page, it’ll refer you to the new experience. You’ll also be able to use the new Intune on Azure administrative experience once you are migrated.