Much like System Center Configuration Manager, Microsoft Endpoint Manager (MEM) and InTune can be extremely complex to manage. Here are some tips for designing a scalable, manageable MEM environment. This is part 1 of a series. In this post I cover initial AAD group planning and creation.
Azure Active Directory (AAD) groups can be used to manage MEM assignments in much the same way as OUs are used to manage Group Policy assignments in a traditional Active Directory. In order to be successful, significant thought must be given to the groups you will be using to manage your users and devices. Whether you are designing a greenfield environment or planning to better manage a legacy deployment, groups are a good staring point. As best practice, you should:
· Decide on a group naming convention
· Keep Device and User groups separate
· Use Dynamic groups where appropriate (e.g. where you want a policy to apply
based on device names)
Below is an example of the groups I tend to create prior to any other activity. I often use the below naming format for consistency and clarity:
<PREFIX>-<DeviceOS>-<USER/DEVICE>-<ASSIGNED/DYNAMIC>-<DESCRIPTION> In the below examples I have included the query syntax for dynamic groups.
Intune-Win10-Devices-Dynamic-Intune-Managed
As the name says, this is a dynamic group containing all Windows Intune managed devices, this can be useful if you want to globally assign a setting without pushing it to ‘all devices’. In practice, I rarely use this group for assignment of policies, because it tends to be too broad, but its a useful catch-all.
Rules Syntax
| (device.managementType -eq “MDM”) and (device.deviceOSType -startsWith “Windows”) |
InTune-Win10-Devices-Dynamic-AutoPilot-Enabled
This dynamic device group holds all autopilot enabled devices.
Rules Syntax
| (device.devicePhysicalIDs -any _ -contains “[ZTDId]”) |
InTune-Win10-Devices-Dynamic-AutoPilot-Enabled-<GROUPTAG>
Becoming more granular, this dynamic device group holds all autopilot enabled devices which are members of a specified Grouptag, this group is useful for assigning deployment profiles and managing policies which you wish to apply at the Grouptag / business unit level
Rules Syntax
| (device.devicePhysicalIds -any _ -eq “[OrderID]:<GROUPTAG>”) |
InTune-User-Assigned-Licence-Assignment
In order to enrol a device into MDM management or perform Autopilot deployment, the enrolling user must have an Intune and Azure AD P1 licence assigned. If not assigned elsewhere, Groups can be used to assign these licences as shown below. By adding users to, or nesting existing groups into this group, the required licence can be deployed.
InTune-User-Assigned-Enrolment-Allow
This group wont be required in all cases. As standard, all users are allowed to enrol devices in InTune and perform Autopilot activities. However some organisations prefer to restrict this to certain groups via the MDM configuration (below). By adding users to, or nesting existing groups into this group, the required MDM user scope can be assigned
InTune-Win10-Devices-Dynamic-Updates-StandardRing
This group is used to assign the standard update ring policy to production devices. This policy can be applied to pretty much all devices you want to manage updates for. Fast ring devices can be prevented from taking this policy via an exclusion. We’ll talk about update policies later. For more information on update rings, please refer to the below article:
https://docs.microsoft.com/en-us/mem/intune/protect/windows-update-for-business-configure
Rules Syntax
In this example, we are selecting devices managed by MDM, and which are using the prefix naming convention which is assigned by an Autopilot deployment profile. This way, we capture all devices built using our deployment profile. This query can be customised to meet your needs.
| (device.managementType -eq “MDM”) and (device.displayName -startsWith “<EXAMPLE>”) |
InTune-Win10-Devices-Assigned-Updates-FastRing
This group is used to assign the fast update ring policy to production devices. This group will be explicitly excluded from the Standard Ring policy, therefore devices which are members of this group will not receive the standard ring policy, and we can apply a separate ‘fast ring’ policy to this group.
InTune-Win10-Device-<Dynamic/Assigned>-BitLocker-On
This group may not be required, but Bitlocker can make IT admins very nervous, so I like to manage the Bitlocker policy assignment via a specific group. This can be dynamic or assigned depending on your preference. If dynamic, you can use similar queries to those shown above.
InTune-Win10-Device-Dynamic-Required-Apps-<GROUPTAG>
This group is used to assign a standard set of core applications to newly built Autopilot devices with a specific Grouptag. Perhaps as importantly, it is also used to remove built-in Microsoft apps such as the Xbox game bar from corporate devices using the Windows Store for Business (which is going away soon, and I’ve not seen any information on how apps should be removed going forward. If you have any thoughts on this please leave me a comment!). The rule syntax simply uses the GroupTag to deploy these apps because:
1) We know this is an autopilot device if it has a Grouptag
2) Grouptags can be a useful container for building different device profiles (e.g Finance, Marketing), which have different application sets
Rules Syntax
The query here is the same as for the Autopilot Grouptag devices, so you could simply use that group for deployment, or nest it into this new group rather than using a dynamic query. Personally, I like to have groups for each specific function, so that there is less scope for confusion about what a group is doing, and we are less likely to see administrative changes which break our functions.
| (device.devicePhysicalIds -any _ -eq “[OrderID]:<GROUPTAG>”) |
InTune-User-Assigned-Optional-Apps-<DEPARTMENT>
Multiple similar groups with the above naming convention can be created, suffixed with a department name. Adding users to this group will allow optional applications to be advertised to users via the company portal.
In the next blog, I will look at creating the basic policy structure for Windows device and application management, which will leverage the groups created here.