MEMCM - Migration from On Premise to Intune - Part 5 - Migration of Collections

In this next part of the series we will look into the transitioning of the collection estate in your on premise SCCM into Intune to take advantage and map all of your deployments, policies and any additional customized settings you have within your Modern Workplace Management.

This particular part may be pretty straight forward - however there might be some little hurdles when it comes to the structural mapping when going through this transition so will cover as much detail as possible as well as outlining some best practices along the way.

In SCCM we have two forms of collections;

• Device Collections
• User Collections

Where you would have limiting collections to restrict which devices can be added into your collection, within Azure/Intune we don't have much of a equivalent to this.

So any device/user will be accessible if wanting to add any CI into an Azure AD group. Having said that the closest to a form of restriction to what you can add to an Azure AD Group can possibly be controlled using an Administrative Unit which can control which users can actually edit and add CIs to the group. But in terms of an actual limiting base for the CIs in the group itself there isn't really one.

Group nesting with groups that have dynamic rules added into other groups are other alternative methods which will be discussed in further details below.

This would apply more to do the query membership type rules discussed further in this article. This particular area has a slight draw back where you cannot set a scheduled time date to refresh groups which as it stands takes about 24 hours to do a complete refresh.

There is a workaround to force a refresh (interesting mapping for Update Membership in SCCM :) ) where you can either edit the name as a whitespace then delete then it will update. This will however trigger the group membership to update immediately where it may take longer in SCCM depending on how complicated your SCCM collection structure is.

So this is a straight forward add a single device or multiple devices into a collection with no specific rule in place just a straight forward explicit addition to the group so we will look into how its done in the on premise way and then investigate how its done within Intune.

On-Premise SCCM Method: Direct membership works with just creating a new collection and then adding a direct membership rule, or you can right click an existing collection and select add resources.

Intune Method 1: Add Members allow you to perform a similar function to the method described however in this case you have a list of all of the devices of both devices and user accounts

Intune Method 2: Bulk upload: Here you have an option to perform a bulk operation to inject the deployment group with all of the devices. So when migrating from your on premise collection you can grab an export of all of the devices by its UPN name and import using the template provided in Figure 1.2

A query membership in On Premise SCCM uses a WQL query which builds a logical condition as to which devices or users can be dynamically added into your collection.

So we will list out the mapping between the On Premise and Intune methods.

On Premise Method: Query Membership Rule - Create a WQL Query to build a conditional query to structure adding CIs in a dynamic state.

Intune Method: Dynamic Device/User: In this particular setting we set a rule which can detect various different settings on the CIs which we are using to build the dynamic query for. You can see this further in the examples in Figure 1.3 and Figure 1.4 which details a rule for picking up just Windows 10 20H2 machines. In addition we can also run a validation test so that we can see a preview of what devices will/wont be added to the Azure AD group which is great for troubleshooting.

In your On-Premise SCCM you will have membership rules such as to Include/Exclude groups from your device collection.

On Premise Method: Include/Exclude Memberships: Here we can select either method and then select the corresponding collection which you will add to these rules.

Intune Method: Group Memberships: There isn't an exclude membership rule but the Group Membership setting is the equivalent to do the Include membership rule which you would see in SCCM.

The best recommended practices for this section are pretty identical to how you would structure your collection designs within your SCCM. But we will try to optimize them for how you would do them within Intune to give a clearer picture.

Ideally the azure group naming should be clearly outlined so that they can be easily identified for what they look after. For example if we were creating a device collection for Zoom deployments something where an Azure AD group would have a naming convention such as <Application Name>-<Version Number>-<Install or Uninstall> so in translation;

• Zoom - 10.0.0.0 - Install
• Zoom - 10.0.0.0 - Uninstall

There might be cases where this is not avoidable, but where possible please avoid this! I've seen several estates where CIs can be parts of deployments where they are part of install and uninstall deployments of the same policy or application.

In these cases you can utilise the exclude group deployment options which setting an assignment which can be viewed in Figure 1.6.

The next part we will go into detail on how we perform the mapping and transitioning on the policies migration from client policies and your endpoint security settings.