Intune Migration Blockers for Grouping & Targeting

By Alvin Tsou | PM, Intune

All Intune standalone accounts have been migrated now, except for a few that requested to wait. We'll leave the article here for archival purposes.


This is the fourth major update to this blog post. We’ve been encouraging you for months to fix any issues preventing us from migrating you cleanly, but we haven’t done any migrations if there was something we knew would work differently afterwards. For the last several weeks, we have been doing migrations for customers who have not fixed migration issues. We're down to just a few hundred accounts left to migrate. If you're reading this, you're probably one of them. This August update will tell you what you need to know about migrations going forward. We added some info to issue #1 about a report to help you find ungrouped users and devices. We've added more information to issue #7 and #8. On August 22 we added a new issue, #9, even though it impacts only a few dozen accounts.

If you haven’t done so already, you really should go to the Office Message Center, login with your admin credentials, and check for messages we’ve recently sent you about migration. If you think you’ve fixed all of your issues, go read How to tell if your Intune account has been migrated. If you’re migrated, great! You’re good to go! You might want to check out some of the known issues post-migration here:

If you haven’t migrated yet, you’re either blocked by an issue on our side or a configuration on your side that caused us to pull you out of the migration process. There are very few accounts still blocked by issues on our side, and we’re working through those with extreme care to make sure they get migrated perfectly, so most likely you’re still blocked by configuration. If you can remove any blocking issues, do it as soon as possible. If you can’t, we’ll explain below what will happen when we migrate you anyway.

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.

What happens if I don’t fix my migration issues?

Eventually we’ll have to do your migration, even if things won't work as they did before. The results will vary, depending on which issue blocked you. Some of you are blocked by multiple issues. If we couldn’t recreate your group structure, we may need to do what we call a snapshot migration. See each issue for more detail about what happens for each issue.

What is a snapshot migration and why should I care?

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. Whenever we could, we created dynamic groups that mimicked your current group structure and finished your migration.

If we couldn’t reproduce your current state because of a group blocking issue as described below, we’ll do what we call a “snapshot” migration. 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.

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.

If you fix your blocking issue before we get to your snapshot migration, you’ll continue through the regular migration process like other accounts did.

If we do a snapshot migration, you can tell because you’ll have groups that start with Snapshot of <Intune group name>. Keep reading for more information about each specific 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 targeted any deployment – apps, policy, terms and conditions – to these groups, it delayed your migration until we started doing snapshots a few weeks ago.

How to fix deployments to ungrouped users and devices to avoid a snapshot migration.

If you’re impacted by this, we sent you a message in the Message Center on June 29 telling you how to use the new Intune self-service reporting feature to fix deployments to ungrouped users or devices. If you get a snapshot migration for this issue, use that report to make sure any users or devices that were not grouped will get the policies they need.

2- Exclusion Clauses in Groups

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.

For more information on this topic, see How to find and remove exclusion clauses in groups to avoid a snapshot migration.

If you have exclusion groups that were snapshot migrated, they will be called Snapshot of <Intune group name>, Unsupported Configuration. If you look in the Message Center for the posts we sent in May, it will tell you if you had exclude issues.

In our last release, we released a new way to get similar “exclude” functionality after your tenant is migrated. For more information about how to exclude groups from a device profile assignment, see You can also read a blog post by Scott Duffy, a program manager on our team, about replacing Intune “exclude groups” in the Azure portal.

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.

See How to find and remove nested groups to avoid a snapshot migration.


  • Some of you created groups with a parent other than All Users or All Devices and with exclusion clauses, which means you have a group that is blocked by both #2 and #3. You’ll have to fix both to avoid a snapshot migration.
  • Some of you have nested groups with conflicting app intents. See #5 for more information.

If you had nested groups that were migrated with snapshots, you’ll know because you’ll see group names like Snapshot of <Intune group name>, Nested group.

We found two main scenarios where people used nested groups:

  1. You wanted to create a hierarchy of groups for visual organization and reporting
  2. You wanted to create an AND situation, for example everyone who is in Accounting AND in France, or Accounting AND the United States.

For #1, just re-target your deployments to the security groups that were nested.

Scenario #2 is a bit more complicated. If possible, create a dynamic Azure AD group based on attributes, not group membership, and redeploy everything to the new dynamic group. For example, ( -eq “France”) -and (user.department -eq “Accounting”) will work. If you were using nesting to deploy to everyone in a parent group All French Users and then to a sub group called All SAP Users, there’s no dynamic way to recreate that and you’ll have to figure out another way to get the right set of users.

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 accounts still have these, but we’re including it here just in case.

How to find and remove the Is Manager clause

We don’t add information to the group name for Is Manager snapshots – they will just be called Snapshot of <Intune group name>, Unsupported Configuration. If you look in the Message Center for the posts we sent in May, it will tell you if you had Is Manager clauses. You can recreate this by using dynamic groups where the rule is Direct Reports for {obectID_of_manager}. This is documented here:

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.

See How to find and fix conflicting app deployment rules to avoid a snapshot migration.

If you had conflicting app deployment rules, we’ll make sure there are two groups that are not in any sort of parent/child relationship and deploy the app to each group using the intent for the Silverlight group. Anyone in both groups would have the same app with different intent, and it will be resolved according to the table here:

Let’s say you had Outlook targeted as Required to All Users, and then targeted as Uninstall to the Outlook – Uninstall child group of All Users. The migration process will target Outlook as Required to All Users, and then create a group called Outlook – Uninstall and target the deployment as Uninstall to anyone in that group. If you have a user in both groups, the conflict resolution table says that if a “user required” app faces off against a “User Uninstall”, the result will be “required”.

Remember we told you in #3 that a nested group does not have All Users as the parent group? We found many accounts targeted the same app with different intents to both a nested group and the parent group. If you did that, and if you clean up your nested groups in #3, you may have already removed any conflicting app intents. If you don’t clean them up and get a snapshot migration, the nested group will get migrated as Snapshot of <Intune group name>, Nested group and then any apps deployed to the nested Intune group will be deployed to the static snapshot Azure AD group.

If you had a snapshot migration, go through each app deployment in the portal and look for any apps that have two deployment actions. Refer to the table in the link above to figure out what the result will be for anyone in both groups. If you are happy with that result, no further action is necessary, otherwise you’ll have to change your groups or targeting or both. If you find an app deployed to a snapshot group, evaluate if the static group will meet your business needs and, if not, create a dynamic Azure AD group.

6 –Using an Old Version (Prior To December 2016) of the On-Premises 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.

We don’t do snapshot migrations for any accounts with the old Exchange connector, we just migrate the account. The on-premises Exchange connector will stop working. If you are using conditional access, those policies will not be enforced until the on-prem Exchange connector has been updated – devices that move from compliant to non-compliant will not be blocked, and devices that move from non-compliant to compliant will not be allowed access. You should go in and update the Exchange connector as soon as possible.

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

Less than a dozen customers have this configuration. If we notified you that your migration was blocked by this issue, you should really enable self-service group management as soon as possible! If you don’t, we will have to migrate ALL of your groups as snapshot groups; if you want dynamic groups after migration, you will have to recreate every group and assign every policy to the new dynamic groups.

8 – Intune apps deployed to All EAS Managed devices

Devices that are managed by Exchanged Active Sync used to be able to get a mailbox policy deployed to them, even if the device was not enrolled for mobile device management. We stopped supporting that mailbox policy for EAS devices over a year ago. Mailbox policy was a special thing we built for EAS, but you’ve never been able to deploy any other type of policy to devices that are managed only by EAS; a device had to be dual-managed (managed by both EAS and MDM) before it could get any other type of policy. Even though we stopped supporting groups comprised of devices managed by EAS only, you might still have policies deployed to those groups. Since we don’t support those deployments, we can’t recreate that configuration with Azure groups. You should go through all of your groups and look for groups with criteria membership where Device type = mobile and where the option Specify the mobile devices to be included in the new group is set to Only include mobile devices that are managed by Exchange ActiveSync. You should either delete those groups or change the criteria to Only include mobile devices that are managed Microsoft Intune direct management.

How to find and fix Intune policy deployed to EAS-based device groups

If you have a device group called Snapshot of <Intune group name>, Unsupported Configuration, it could be an exclude group, or it could be an EAS group. To avoid confusion, it is much better to fix these prior to migration so you can still see the group intent. Afterwards, you’ll have to guess using the name of the group and the policies deployed if it was for excludes or EAS-managed devices.

The snapshotted group will contain only dual-managed devices, not devices that were only EAS-managed. If you had any mailbox policies, they were deleted during migration. Any other policies would be targeted at the snapshot group, but it will be a static group. If you need a dynamic group, create a new one in Azure AD and target your migrated policies to the dynamic group.

9 -  PFX Certificates Issued Using the Intune Certificate Connector

During the migration process, we identified a few dozen accounts that would have problems with certificate hashes after being migrated. In a few cases, the migration process would cause current PFX certificates on devices to be revoked and reissued. End users have to accept the new certs or they may lose access to workplace resources like WiFi or email. We put those accounts on hold and came up with a fix for the issue, but before the fix can take effect, all PFX policies have to be regenerated. You can regenerate the policy yourself, or you can wait, and we’ll do it for you. We recommend you do the regeneration yourself, so you can control the timing and make sure everyone in your organization is aware of the change.

How to regenerate PFX Certificates Issued Using the Intune Certificate Connector

We don’t do snapshot migrations for this issue. If you haven’t regenerated your PFX policies by September 18, we’ll regenerate them for you. All of your policies will still work, before and after migration, but during the week of September 18 some users may be prompted to re-enter their username and password. Also, Android users who use PFX and username/password authentication may need to reinstall their security credentials.

Next Steps

We hope this post helps you fix your migration issues and avoid a snapshot migration, or evaluate your snapshot migration groups to avoid issues in the future. After we have confirmed your account has migrated, we’ll notify you in the Office Message Center (confirmations are being sent daily as we get down to the last few accounts). If you had an outdated Exchange connector, update it. If you had other issues, look for groups that start with any of the Snapshot text shared above, and evaluate if they will meet your current needs, or if you need to create new, dynamic groups.

We look forward to getting you onto the new Intune on Azure experience as soon as possible!

Again, please see - How to tell if your Intune account has been migrated for additional migration information.



Comments (23)

  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

  8. We’ve been waiting for this. Couple of hours ago I get an notification about exclusions and nested groups. Fixed exclusions, but cannot find any nested group nor something that could trigger this warning. I am just interested if it could be because datasets for nested and excludes were swapped? Or could it be caused by groups created and used this way: 1: Create a group that use All Users/All Devices as the parent group. 2:Start group membership with All Users\All Devices in the Parent Group. 3:Include one or more security groups.


    1. Hi, Marcel, yes we did accidently swap some messaging between the two data sets. We pulled back any messages incorrectly sent, so what you have today should reflect what we know about your account. As long as the parent is either All Users or All Devices, and you are not using Exclude, you should be good. If you open a support ticket, they should be able to verify which issue(s) you have and give you the actual names of any nested or exclude groups.

  9. Betsy Getreu says:

    I opened a support ticket and received a call from an Intune tech. He told me I needed to create groups for users and devices that had no connection to All Users or All Devices. As far as I can tell, it is impossible to create a group that has no parent, so I am very confused. I created a group for users and another for devices after the first migration failure notice came through and made sure I had no policies at all. Still migration has no occurred. Now what?

    1. Hi, Betsy, you are correct that there is always a parent, and that parent should be All Users or All Devices. If you have any other group as the parent, that’s a nested group, and that’s a migration blocker. If the message in the Office Message Center said you have nested groups, and you should walk through this article to find them.
      (We had some false positives in the data, so we had to pull a few messages and repost to a few customers. If you double check everyone should have the right messages now.)

      In some cases, after customers are fixing their configuration issues, we find an issue on our side that we still need to fix before the migration can go through. That’s a very small number of people, but it has happened. If you wait a week or so and contact support again, we should be able to give you an update if we’re still seeing any configuration issues on your side or if it’s a bug on our side. We appreciate your patience!

  10. Joe says:

    We received the nested groups email and have since cleaned all of that up. We do have still two nested groups under all devices though which seem to have been automatically created and I am unable to delete. Specifically they are called “All Mobile Devices” and Corporate “Pre-enrolled devices”. Each has two child groups which cannot be deleted.
    Do you know if these will cause us any problems or not?

    I did contact support but they just said to read this article.

    1. Hi, Joe, Those should not cause problems, since those are built in groups.

  11. Niki Davies says:

    In response to #9
    Once I have amended the description in policies you state that some users will be prompted to enter there username and password.
    There are no screenshots for this behavior with iOS devices, there are for Android. Would I be able to get screenshots for our comms? Does the username/password request appear in company portal, the outlook app or on the home screen?

  12. Naresh doshi says:

    I need help on Intune
    as I a partner #1208662 I have 26 intune client and as I am globle admin I use to manage client computer update,cleing,scanig
    through my partner portal now I can not and if I try it goes to azure . I don’t see any clients computer. so can I see them for that I need

    1. Hm, from the description we can’t tell what the issue is. If you have a contact in our Partner organization, contact them. If not, the best we can suggest is opening a support case.

Skip to main content