C
ClaudiaZH2021
Since the Microsoft endpoint management team introduced device filters to the Intune management console, administrators have increasingly embraced them for policy and application deployment assignments. Device filters have significantly enhanced deployment performance and reduced latency in assignments workload. Their impact is most pronounced in large Intune environments, such as those with over thousands of devices. Besides their excellent performance, administrators appreciate their ease of use.
However, while device filters offer numerous advantages compared to traditional Azure AD device groups and user groups, their usage requires careful consideration.
Device filters are created based on device properties like device name, device model, device manufacturer, and device category. In theory, device filters should be evaluated at enrollment and when the device checks in with the Intune service. However, the timing of enrollment evaluation and device check-in can be somewhat tricky in real-time device management environments.
Scenario one:
A policy is applied to the Intune "All devices" virtual group with a device filter set to "exclude" as below picture. At the moment of enrollment evaluation, if the properties in the device filter rule are not set on the device, a newly enrolled device might be evaluated as having null values for those properties, and the policy is applied successfully. However, during the next device check-in (possibly just seconds later), the device's filter properties have been updated, returning the expected evaluation results. If the policy applied is tattooed (“tattooed” means that the policy is permanently applied to the registry and do not revert back to their original state even when the policy is removed or set to “not defined”) or persistent, it won't be automatically removed. This can lead to significant device management issues, which can also occur during application deployments.
A common example of this device filter usage issue relates to Microsoft Teams Rooms Windows devices (MTRW). Many customers enroll their MTRW devices in Azure AD, which are then managed by Intune. One of the prerequisites for using MTRW devices is that autologon should be enabled, meaning that no device lock policies, like password policies, should be applied to these devices. Administrators often use a device filter with device models or device names set to "exclude" in password policies. However, after the MTRW device is enrolled, the password policy is still applied during the enrollment moment because the device properties in the filter rule are not available. This triggers the application of Exchange ActiveSync (EAS) settings to the device. At the next device check-in, the device is successfully evaluated with the filter and excluded from the password policy. However, the EAS settings are tattooed, permanently disrupting the MTRW autologon functionality.
To address this issue, consider the following solution: When using a device filter to exclude devices in policies or application deployments, include an additional line in the regular device property rule as "device.property -eq $null." This addition effectively prevents the issue mentioned above. When a new device is enrolled without device properties available for evaluation, "$null" is presented for evaluation, and the device is excluded as expected. For example, here's a filter example you can use for excluding MTRW devices from password policy:
((device.deviceName -startsWith "cf-") and (device.deviceName -contains "-MTR")) or (device.model -eq "10V50000US") or (device.model -eq $null).
When it comes to using device filters as "include," be cautious when assigning policies or applications to device groups or Intune virtual group "all devices." These groups experience workloads high-performance during device enrollment. If tattooed settings or applications are applied to devices before the device filter is evaluated, administrators may face challenges in troubleshooting which devices unexpectedly received these settings. In most cases, user group assignments with device filter as "include" provide a more accurate targeting result than device groups with device filters. If the policy is applied to user group with device filter, during the enrollment moment, the enrollment will need to evaluate user membership with user login information first before device filter is evaluated, so the devices get enough time to present their properties for filter evaluation. However, there can still be timing challenges between user login and device property evaluation.
Scenario two:
where using device filters as "include" is not recommended is when combining "all devices" assignments with device filters as "include" and Azure AD devices groups as "exclude" as below screenshot. Azure AD device groups have membership evaluation latency, and deploying tattooed settings in this combination may lead to devices in the excluded group receiving the settings before Azure AD membership is evaluated.
For example, suppose an admin needs to disable USB debugging settings for most Android Teams devices, but allow some exceptions for special purposes. The admin may use the following steps to achieve this:
The devices in the exclude group will also have their USB debugging settings disabled if the admin follows these steps. This is because there is a delay in the device group evaluation, and the “all devices” group and the device filter take precedence over it. The setting in those devices is irreversible and cannot be recovered by a full synchronization later. Therefore, the admin should be very careful when applying this policy and avoid affecting the devices in the exclude group.
In summary, when creating and managing assignments in Intune, it's crucial to consider which assignments are suitable for different scenarios:
Many thanks to Jerry AboueInasr, you did a great job in providing test scenarios and validating the new solutions for device filters. I learned a lot from your insights and suggestions. Thank you for your valuable contribution!
Continue reading...
However, while device filters offer numerous advantages compared to traditional Azure AD device groups and user groups, their usage requires careful consideration.
Device filters are created based on device properties like device name, device model, device manufacturer, and device category. In theory, device filters should be evaluated at enrollment and when the device checks in with the Intune service. However, the timing of enrollment evaluation and device check-in can be somewhat tricky in real-time device management environments.
Scenario one:
A policy is applied to the Intune "All devices" virtual group with a device filter set to "exclude" as below picture. At the moment of enrollment evaluation, if the properties in the device filter rule are not set on the device, a newly enrolled device might be evaluated as having null values for those properties, and the policy is applied successfully. However, during the next device check-in (possibly just seconds later), the device's filter properties have been updated, returning the expected evaluation results. If the policy applied is tattooed (“tattooed” means that the policy is permanently applied to the registry and do not revert back to their original state even when the policy is removed or set to “not defined”) or persistent, it won't be automatically removed. This can lead to significant device management issues, which can also occur during application deployments.
A common example of this device filter usage issue relates to Microsoft Teams Rooms Windows devices (MTRW). Many customers enroll their MTRW devices in Azure AD, which are then managed by Intune. One of the prerequisites for using MTRW devices is that autologon should be enabled, meaning that no device lock policies, like password policies, should be applied to these devices. Administrators often use a device filter with device models or device names set to "exclude" in password policies. However, after the MTRW device is enrolled, the password policy is still applied during the enrollment moment because the device properties in the filter rule are not available. This triggers the application of Exchange ActiveSync (EAS) settings to the device. At the next device check-in, the device is successfully evaluated with the filter and excluded from the password policy. However, the EAS settings are tattooed, permanently disrupting the MTRW autologon functionality.
To address this issue, consider the following solution: When using a device filter to exclude devices in policies or application deployments, include an additional line in the regular device property rule as "device.property -eq $null." This addition effectively prevents the issue mentioned above. When a new device is enrolled without device properties available for evaluation, "$null" is presented for evaluation, and the device is excluded as expected. For example, here's a filter example you can use for excluding MTRW devices from password policy:
((device.deviceName -startsWith "cf-") and (device.deviceName -contains "-MTR")) or (device.model -eq "10V50000US") or (device.model -eq $null).
When it comes to using device filters as "include," be cautious when assigning policies or applications to device groups or Intune virtual group "all devices." These groups experience workloads high-performance during device enrollment. If tattooed settings or applications are applied to devices before the device filter is evaluated, administrators may face challenges in troubleshooting which devices unexpectedly received these settings. In most cases, user group assignments with device filter as "include" provide a more accurate targeting result than device groups with device filters. If the policy is applied to user group with device filter, during the enrollment moment, the enrollment will need to evaluate user membership with user login information first before device filter is evaluated, so the devices get enough time to present their properties for filter evaluation. However, there can still be timing challenges between user login and device property evaluation.
Scenario two:
where using device filters as "include" is not recommended is when combining "all devices" assignments with device filters as "include" and Azure AD devices groups as "exclude" as below screenshot. Azure AD device groups have membership evaluation latency, and deploying tattooed settings in this combination may lead to devices in the excluded group receiving the settings before Azure AD membership is evaluated.
For example, suppose an admin needs to disable USB debugging settings for most Android Teams devices, but allow some exceptions for special purposes. The admin may use the following steps to achieve this:
- Set the assignment to “all devices”.
- Set the Android Teams device filter to “include”.
- Create an Azure AD device group with the devices that need USB debugging enabled and add it to the device filter as “exclude”.
- Apply the policy.
The devices in the exclude group will also have their USB debugging settings disabled if the admin follows these steps. This is because there is a delay in the device group evaluation, and the “all devices” group and the device filter take precedence over it. The setting in those devices is irreversible and cannot be recovered by a full synchronization later. Therefore, the admin should be very careful when applying this policy and avoid affecting the devices in the exclude group.
In summary, when creating and managing assignments in Intune, it's crucial to consider which assignments are suitable for different scenarios:
- Use device group assignments with a device filter as "exclude" and include device.property -eq $null to prevent unexpected devices from receiving settings or applications.
- Avoid using the combination of "all devices" assignments and device filters as "include" with Azure AD devices groups as "exclude" for tattooed settings or applications deployment.
- Exercise caution when using user or device groups with device filters as "include" for tattooed settings and applications assignments.
- For tattooed settings and applications, consider using user groups or device groups for assignments.
Many thanks to Jerry AboueInasr, you did a great job in providing test scenarios and validating the new solutions for device filters. I learned a lot from your insights and suggestions. Thank you for your valuable contribution!
Continue reading...