Intune Migration Blockers for Grouping & Targeting

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.

How to fix deployments to ungrouped users and devices

2- Exclusion Clauses in Groups

The way grouping works now, you can create security groups in or, 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.

How to find and remove exclusion clauses in groups

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:

  1. Create a group that does not 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.

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:

  1. Set the parent group to All US Users.
  2. Start with an empty group on the criteria membership page.
  3. 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.

How to find and remove nested groups

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.

How to find and remove the Is Manager clause

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.

How to find and fix conflicting app deployment rules

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.

How to upgrade your Exchange Connector for Intune

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.

How to enable self-service group management

Next Steps

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!


Comments (14)

  1. jse2 says:

    Cool! We’ve got some ungrouped devices — hopefully not a problem if there aren’t policies applied to them?

    (We’ve actually just deleted *all* configurations — in the hopes that speeds up our migration!)

  2. Correct – only when the ungrouped groups are targeted, migration will fail. Thank you!

  3. Dave says:

    I just added ungrouped users and devices to a group. How long will it take to finish the migration for my account?

    1. If you’re wondering where you’re at in the migration process, you can contact support to see where you are. Many customers are successfully migrated or are in the process right now. Please keep in mind, it’s the targeting of those groups that is a problem, not the removal of users/devices from the ungrouped group.

  4. Leij says:

    Question regarding point one, seeing I have this blocker in multiple environments I manage.

    We have this notification even though we are not specifically targeting any individual users or an ‘ungrouped’ group. We are however, targeting the ‘all devices’ group.

    To fix this, do I need to specify targeting to any group other than the ‘all’ groups in the old Silverlight based portal, or do I have to create groups containing AAD security groups instead of using the old internal functions like direct membership or dynamic memberships based on parent groups (no implicit exclusion in my case afaik)?

    1. Hi, Leij, The All devices group is fully supported. If you received a message that you are targeting the “Ungrouped Users” or “Ungrouped Devices” you should check all of your policies, apps and Terms and Conditions.

  5. Sean DeLessio says:

    Is there a way to get the specific item that is blocking the migration, and how do we know when the service will “check back” to try again?

    1. Hi, Sean, yes, if you open a support ticket, the customer support engineers have the lists of who is blocked by what, and can tell you which item to look for. The service will check back again every 24 hours to see if you still have blockers. After the algorithm determines you don’t have any configuration blockers, it can still take a few days to validate that all the new groups have the correct membership and that all the policies (including terms and conditions and apps) have been properly applied. If you have a lot of groups, and/or a lot of policy, and if they change a lot, it can take a while for us to validate. (Also, if there is anything that isn’t 100% perfect on our side, we’ll investigate and we won’t call it done until we’re sure everything has been migrated properly.) When the algorithm determines that everything adds up perfectly, the migration finalizes and you get a banner in Silverlight saying you can use the Intune on Azure portal.

      For information about how to open a support ticket, see

  6. Francesco says:

    How do i know when my Tenant will be migrated?

    1. Hi, Francesco, please see the reply we gave Dave.

      1. Francesco says:

        On 03/10/2017 I wrote to but got no answer. Could you give me the contact to request information?

        1. Hi, Francesco, you can go to for information about to contact Intune Support.

  7. Andrew Fleming says:

    I have just been informed I have nested groups, I don’t as, I removed them about 6 months ago, so this is frustrating, try updating the data that you are checking against and migrate me please.

    1. (updated 5/18, 3:55 pm)
      Hi, Andrew, I originally said that if we sent you a post in the Message Center saying you have nesting groups, then there is still *something* lurking there. But you may be right about not having nested groups – you may have exclude group/s instead. The datasets for nested and excludes were swapped. We just reposted them. After triple checking them. The lists we used to notify anyone blocked by excludes, ungrouped, or nested issues were only hours old when we posted, so if there’s something there, there’s something there.

      If you call support, they also have the detailed (and correct) lists now and can tell you which group(s) specifically to look for. For information about how to open a support ticket for this, see

Skip to main content