Support tip: Targeting apps and policies with Windows Autopilot

[Intune_Support_Team]

Overview

Windows Autopilot is designed to both streamline and tailor your deployment flow to your users. By simplifying your deployment configuration, you'll experience higher levels of success, as well as greater user satisfaction during deployments. One of the key factors that can improve your success is to avoid targeting changes to policies and applications while devices are being provisioned. In this post, we highlight targeting guidelines to create successful Windows Autopilot experiences. First, let’s get a better understanding of how targeting impacts device provisioning in Intune.

How Intune processes changes to device membership and assignments

Intune recalculates device policy and application assignments as it learns about Security Group membership changes for devices, as well as the changes that you make in the Intune console. When assignment recalculation for a device begins, it takes a small amount of time before all the changes are applied. Changes made to device group memberships during device provisioning may have broader implications, potentially resulting in the service having a different view about device provisioning. This view may depend on when the device assignments are checked with respect to when the membership changes are detected, causing service issues. Examples include devices not being able to successfully complete provisioning or users reaching the desktop before the needed policies and applications are installed on the device.

Intune also recalculates device profile and application assignments when you make changes in the Intune console. These changes can impact the device as well. The impact of configuration changes to devices being provisioned are similar to the impacts described for device membership changes. To ensure that changes don’t negatively impact your devices, keep reading for tips and best practices.

Best practices for grouping in Windows Autopilot

Windows Autopilot supports the configuration of device policy and application assignments via the use of the Azure Active Directory (Azure AD) device object, which is pre-created for each device registration, and the object’s 'devicePhysicalIds' property. The 'devicePhysicalIds' property can be configured with attributes such as the 'OrderId', which can then be leveraged in Dynamic Security Grouping rules. The 'OrderId' for an Autopilot device can be configured at the time that a device is registered or later through Intune. See Create device groups for more information on Configuring the GroupTag for a device.

Autopilot also replicates the information contained in the 'devicePhysicalIds' property from the pre-created Azure AD device to the hybrid Azure AD device object for Autopilot hybrid configurations. This ensures that the memberships for the Autopilot device remain consistent as the device switches its identity from the pre-created Azure AD device to the hybrid Azure AD device.

Recommended grouping for Windows Autopilot

Leverage Windows Autopilot targeting support

By configuring dynamic security grouping rules that rely on the 'OrderId' attribute of the 'devicePhysicalIds' property of the Azure AD device, the likelihood that device assignments will be recalculated while devices are being provisioned is reduced. This is because dynamic security grouping rules rely on device attributes that can change while the device is being provisioned (Example: Device name). Making this configuration modification will also reduce the likelihood that device assignments will change when the devices transition from the pre-created Azure AD identity to the hybrid Azure AD identity for the Autopilot hybrid scenarios.

Please note that the use of “static” device properties such as “Manufacturer” to configure dynamic security group rules will also avoid the possibility of having device assignments be recalculated.

Planning for device configuration changes

Device provisioning should be taken into account when making changes to the policies and applications in Intune. Ideally, you should configure Autopilot to set up a small set of applications during device provisioning. This allows the process to reduce complexity and the possibility for errors, especially during device provisioning.

If you have any questions, please leave a comment below or reach out to us on Twitter @IntuneSuppTeam.

Post Updates:

01/03/23: Updated post to clarify the section: "Planning for device configuration changes".

[rs_ta]

Thank you for sharing, @Intune_Support_Team . Note typo in title - currently: "Targeting apps and polices" - should be: "Targeting apps and policies".

[AdamGell]

Ideally, you should configure Autopilot to set up a small set of policies and applications during device provisioning to allow the process to complete in a short amount of time and to reduce complexity and possibilities for errors. 

How do we restrict policies during ESP?

[MikkelLundKnudsen]

Talk about targeting here, if I can't seem to find a way to target primary users on a device, with either a Azure AD Dynamic Group, or a Filter - then how am I going to do that? :)

Any plans on extending parameters for either Dynamic Groups in Azure AD or filters?

[juan_alvarado74]

I learned the hard way to configure Autopilot with the bare minimum needed for a device to be able to connect to our VPN in order to complete the hybrid AD join. I initially attempted to to have Autopilot install the 11 applications every company issued device requires. Autopilot deployment failed time and time again. I had to take a step back and re-assess the situation. Why did I need Autopilot? To join a new remote employee's device to be joined to our on-premises AD without having to be on-premises. We have several ways to automate remote deployment of applications, but they all require the device to be joined to our domain.

I asked myself what applications were necessary for a remote employee to connect to our VPN, completing the offline domain join used by Autopilot. Only 3 of the 11 were absolutely necessary, Cisco AnyConnect VPN client, the Cisco Start Before Logon module, and our endpoint security software that must be installed before a device can access the VPN. I added our remote management application so the Help Desk could assist the user if necessary. I had to make Cisco AnyConnect a dependency for the SBL module so they would be installed in the right order, and Voila! Success.

When new devices are enrolled in Intune they are assigned to a New Device group using their serial number. The deployment profile is assigned to this group. Once the user logs in and the device completes the on-site AD domain join it is removed from the New Device group and is added to a group that all domain joined devices belong to. The remaining apps are assigned to this group and within 20 minutes or so after the user logs in they can begin work. The amount of time Autopilot saves me going forward was worth the effort. I use it to deploy the devices of employees that work at corporate office where I work as well. I sign in let it do the rest.

[AaronHall]

@juan_alvarado74 Another serious question to ask-- do you really need Hybrid join or can Azure AD Join suffice? In my situation, I quickly decided to NOT do Hybrid at all. The only tangible benefit it offered in my scenario was not having to recreate AD GPO as Intune Configuration Profiles, and I decided recreating once was ultimately better. Your mileage may vary, of course, but eliminating the dependency on VPN and on-prem AD meant no more broken domain trust issues for workstations where the user never/rarely connect to VPN. Autopilot is proving to be a much better experience too... better still with Windows 11 22H2 now requiring Internet connection during OOBE and not allowing a "local account" bypass.

[JuanitaBaptiste]

Hi @AdamGell while we can't restrict policies to ESP yet, policies may come down during or post OOBE but what we want to make sure is considered is that policies targeted are necessary and do not conflict with the OOBE flow. For example if you have SCEP certs targeted that aren't necessarily needed, it can impact the deployment if it fails. Today, ESP only tracks on these policies:

• SCEP certs & PFX certs
• VPN profiles & WIFI profiles
• Intune device ID policy (setting it on the client)
• Kiosk related policies

Those policies are not prioritized or front loaded, but we do block on it until those have applied, if applicable. 

[David Stowers]

Life would be much much easier if you could tell the ESP to only try to install certain apps and configs (even if they are assigned to the device) so they would instead be pushed post-OOBE.  At the moment I just let it fail and they magically work fine when ESP is finished.

[Marc Laflamme]

@David Stowers You can tell ESP to install certain apps using the Block feature. Is this what you're looking to do?

[TBJob]

Hi @Intune_Support_Team,

we use an approach which includes scripts to add the AAD device objects as members of AAD device groups which are then used for apps or policy deployments during Autopilot which circumvents changes in memberships during provisioning itself.

What do you think about assigning apps and policies to AAD user groups instead plus using Intune filters (where available) to narrow down the targeted devices? This would especially help as we do not need to transfer group memberships when the hardware changes.. Afaik apps and policies are only applied if the user is the primary user of the device (which would be the case during/after Autopilot) but not when the user signs in to another device, correct?

Thanks for your answer.

Best regards

TB