The Autopilot team has consolidated another set of FAQs:
- Is this a new version of Autopilot?
- Autopilot team: No. This is a new profile type for Autopilot. Our customers in government clouds required a different profile type, and in developing a solution for these customers, we have addressed other common requests from customers for new or different capabilities and made them available to all. We welcome your input, as this new profile type will continue to evolve over time.
- How are we going to do registration now, this is fundamental to our organization using Autopilot?
- Autopilot team: Continue using your current Autopilot registration flow – this new profile is not a replacement for Autopilot and is totally optional. Future capabilities will be developed to allow devices to be associated with a tenant, also called ‘tenant binding’ which will equate to today’s device registration process.
- Will there be OEM flows for device association with a tenant/tenant binding similar to today’s registration flow?
- Autopilot team: We are working on this, so that when the device association with a tenant/tenant binding capability is ready for GA, OEMS will have a process to use it.
- What’s the support plan or new innovation coming for Hybrid AD Join scenarios for this new profile?
- Autopilot team: Hybrid AD join is no longer recommended for use with Autopilot deployments. Autopilot device preparation profiles do not support Hybrid AD Join, but the existing Autopilot flows that do are still usable.
- Are you going to add the ability to orchestrate/sequence applications and policy?
- Autopilot team: To help the development and prioritization of this ability, we need more information about scenarios that need precise sequencing, as opposed to dependency modeling. Please add your scenarios to https://aka.ms/IntuneFeedback
- What about pre-provisioning and self-deploying modes?
- Autopilot team: Over time Autopilot device preparation profiles will support these modes, and have general parity with existing Autopilot capabilities (except for Hybrid AD Join).
- Since the new Device Preparation Policy will be targeted to users, how will we be able to handle the scenario where a user may be targeted with more than one profile?
- Autopilot team: Admins are able to define policy priority from the Device preparation policies screen.
From the Device preparation policies list screen make sure the ‘Priority’ column view is enabled under ‘Columns’
Set the priority of device preparation policies by dragging a higher priority policy to the above another, or a lower priority policy below another.
- What If a user is targeted for multiple profiles for multiple devices intended for the same user with a different use. If User 1 has device ‘A’ for knowledge work and device ‘B’ for front line work, how to apply the proper policy? I understand we could use Filters (for example based on hardware model), and then it would just work through the different profiles by priority. But what if hardware attributes cannot be used to distinguish between use cases?
- Autopilot team: Filters are the only way to currently set profile priority – but this may be possible when device association with a tenant/tenant binding is available.
- How will the new Autopilot device preparation profiles co-exist with ‘legacy’ Windows Autopilot Deployment profiles? If a device is targeted with a legacy profile and the user is targeted with the new profile type, how will OOBE work out which one to use?
- Autopilot team: If a device is registered, it will get Autopilot profile. If a device is not registered it will get the device preparation profile (even if Enrollment Status Page is assigned).
- If an app/script is added to the new profile type, will that only run during the ESP? For example, if the script is updated in the future, will it rerun on existing devices or will it only run on new devices during the ESP? It sounds to me like the behavior is the same as with the legacy AP profile, but in addition to Apps we can now also specify which Scripts we want to include behind the ESP?
- Autopilot team: Anything specified in the device preparation profile will run during the out-of-box experience (OOBE) only, as is the case with existing Autopilot profiles.
But, since that script is also assigned to the device security group, update it and it will re-run during the regular Intune syncs while the device is in use. Verify this updated script using reporting in the Scripts blade.
- Will this remove the need to add hardware hashes to new devices?
- Autopilot team: Not currently, but this process will change when device association with a tenant/tenant binding is available.
- Will you consider increasing the limits of limit of 10 apps and 10 scripts to support more complex configurations in large enterprises.
- Autopilot team: Once pre-provisioning is rolled out, this restriction will be removed. In the meantime, we welcome your input to help the development and prioritization of this change – share the number of apps and scripts you would like to deploy for user-driven deployments at https://aka.ms/IntuneFeedback
- Can you share some dates for the items in the ‘see what’s to come’ section of the blog, especially the device rename function?
- Autopilot team: Unfortunately, we are unable to share exact dates at this time. Rename functionality will be coming with device association with a tenant/tenant binding. Private preview will likely not be available before Q4 CY24 and we don't GA until next year.
- Will this remove the need to add hardware hashes to new devices?
- Autopilot team: If you are using Autopilot device preparation profiles, no hardware hashes are needed.
- How will we create Entra ID entries and use/target device extension attributes or group tags without a device hardware hash?
- Autopilot team: You can configure a static security group as part of device preparation profile policy configuration. On enrollment, devices will be added as member to the group and the policies/apps assigned to the group will be delivered to the device. This feature allows you to create multiple device preparation policies with different enrollment time groups and target different user groups based on location, department, etc.
- Are there plans for have a granular status reporting for both Autopilot ESP and overall Autopilot Deployment status?
- Autopilot team: Reporting improvements are among the features under consideration. To help the development and prioritization of this ability, please add your requests to aka.ms/IntuneFeedback
- Are you developing an option to wait for compliance status before granting access to the device?
- Autopilot team: Waiting for compliance is under investigation. To help the development and prioritization of this ability, please add your requests to aka.ms/IntuneFeedback
- Can we get easier control of language and region settings?
- Autopilot team: Development and prioritization decisions depend heavily on customer input – add your request to aka.ms/IntuneFeedback
- Are Autopilot device preparation policies GCCH compliant?
- Autopilot team: Yes, Autopilot device preparation policies are available in Government clouds GCC, GCC High, and DoD.
- Does the new Autopilot device preparation profile still use Trusted Platform Module (TPM) for Entra ID enrollment?
- Autopilot team: The existing Autopilot device preparation profile does not use TPM. Future scenarios may take advantage of TPM.
- Is there a plan to enable the ability to grant local admin permissions for device-assigned users with Windows Autopilot self-deploying mode? This would help with Federating Domains from Entra ID to third-party Identity Providers
- Autopilot team: There is no current plan to enable this ability. To suggest the development of new capabilities, please add your comments and requests to aka.ms/IntuneFeedback
- What versions of Windows are supported with Autopilot device preparation profile policies?
- Autopilot team: Autopilot device preparation profile policies support these versions:
Windows 11, version 23H2 with KB5035942 or later.
Windows 11, version 22H2 with KB5035942 or later.
- Can Cloud Service Providers (CSPs) or other Managed Service Providers add the corporate identifier or generate identifiers and push device serial numbers and model information via the Partner portal using Autopilot device preparation profiles?
- Autopilot team: No, these capabilities require direct access to your Intune tenant.
- If apps are added by a Device preparation profile policy, will those apps run for each user targeted with the policy who signs in to a given device?
- Autopilot team: No, apps included in the Device preparation profile policy are configured to install only during the out-of-box experience (OOBE).
- Can you enforce or specify device naming conventions with Autopilot device preparation policies
- Autopilot team: No. This capability is on our roadmap, however – to advocate for the prioritization of this ability, please add your requests to aka.ms/IntuneFeedback
- Is there a known issue where the device group assignment disappears from a profile after creation in certain circumstances?
- Does Windows Autopilot device preparation support deploying configuration profiles during OOBE?
- Autopilot team: Configuration profiles will be synced during OOBE but we are not specifically tracking them or waiting until they apply. At this time, we only ensure that the selected apps and scripts are applied during OOBE.
Microsoft