Intune Migration Blockers for Grouping & Targeting


By Alvin Tsou | PM, Intune

This is the third major update to this blog post. So far, we’ve been encouraging you (some of you for over seven months now!) 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. We are starting to do migrations for those customers who have not fixed your migration issues. For many of you, it may be easier to fix post-migration than find the migration issues prior to migration. This update will tell you what you need to know about migrations going forward. We’ve also added another issue to list of configurations that could block a small number of accounts – having Intune apps deployed to the group All EAS Managed devices. It’s #8 below.

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: https://aka.ms/intune_stillworkingon.

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 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 to avoid a snapshot migration.

If you’re impacted by this, we sent you a message in the Message Center saying we’d be starting these after June 30. We’re waiting a bit longer to start these snapshot migrations because we are going to release a self-service reporting tool to help you figure out what you need to fix. We’ll provide more information in the Message Center when we have the tool ready. Until then, you can still fix the issues and get migrated without waiting.

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 https://docs.microsoft.com/en-us/intune/device-profile-assign. 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.

Notes:

  • 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, (user.country -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: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-accessmanagement-groups-with-advanced-rules#supported-properties

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:

https://docs.microsoft.com/en-us/intune/apps-deploy#changes-to-how-you-assign-apps-to-groups-in-the-intune-preview

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 manage.microsoft.com 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

We aren’t going to start forcing accounts with this issue into migration yet. We’ll provide more detail when we do about what follow up actions to take.

8 – Intune apps deployed to All EAS Managed devices

We stopped supporting the group All EAS Managed devices over a year ago, but some organizations still have deployments targeted to that group. Since we don’t support that group, we can’t recreate that configuration with Azure groups. You should go through all of your apps and make sure nothing is deployed to All EAS Managed devices.

We aren’t going to start forcing accounts with this issue into migration yet. We’ll provide more detail when we do about what follow up actions to take.

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 occur typically weekly). 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 (20)

  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 http://aka.ms/intunesupport.

  6. Francesco says:

    Hello
    How do i know when my Tenant will be migrated?
    Thanks

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

      1. Francesco says:

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

        1. Hi, Francesco, you can go to http://aka.ms/intunesupport 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 http://aka.ms/intunesupport.

  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.

    Thanks,

    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. https://blogs.technet.microsoft.com/intunesupport/2017/05/18/nested-groups-fix-your-intune-migration-configuration-issues/.
      (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.

Skip to main content