Windows Autopilot and Deployment (19 questions)
Go deeper on this topic in Windows Autopilot and Deployment Field Guide.
A device and its signed-in user are each in scope for a different custom Enrollment Status Page (ESP) profile, and a tenant default ESP profile also exists. The deployment is a standard user-driven Autopilot deployment. Which ESP profile applies, and how would that differ in a self-deploying deployment?
Correct answer: A. The highest-priority device-targeted profile applies first; in self-deploying and pre-provisioning flows only device-targeted profiles are evaluated because there is no user.
Intune resolves ESP profiles in order: the highest-priority profile targeted at the device, then (only when there is a user) the highest-priority profile targeted at the user, then the default profile. So in user-driven mode a device-targeted profile takes precedence over a user-targeted one. In self-deploying and pre-provisioning (technician) flows there is no user context, so only device-targeted ESP profiles are evaluated and user-targeted profiles are ignored.
Why the other options are wrong:
- B. ESP profile selection is by priority (set by dragging profiles in the list) and target type, not by creation date. Self-deploying mode differs precisely because it ignores user-targeted profiles.
- C. The device-targeted profile, not the user-targeted one, takes precedence in user-driven mode. And in self-deploying mode a device-targeted custom profile still applies if one is assigned; it is not automatically the default.
- D. The default profile applies only when no other profile is targeted at the device or user. When custom profiles are in scope, they win over the default.
Memory hook: ESP order: device profile first, then user profile, then default. No user (self-deploying/pre-prov) means device profiles only.
Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/windows/setup-status-page#prioritize-profiles
After configuring a Windows Autopilot user-driven deployment, an administrator finds that target devices join Microsoft Entra ID during OOBE but never enroll in Intune, receive no deployment profile, and never show the Enrollment Status Page. In the automatic enrollment configuration, MDM user scope is set to None. What is the effect of this setting, and what should it be?
Correct answer: D. With MDM user scope set to None, automatic MDM enrollment never fires, so the device joins Entra ID but is never enrolled in or managed by Intune; set it to Some or All.
The MDM user scope controls automatic MDM enrollment. When it is set to None, automatic enrollment does not occur, so an Autopilot user-driven device joins Microsoft Entra ID (using the user's credentials) and then stops: no Intune enrollment, no profile, no ESP. Setting MDM user scope to Some (scoped to a pilot group) or All lets automatic enrollment proceed. Automatic enrollment requires Microsoft Entra ID P1 or P2.
Why the other options are wrong:
- A. MDM user scope governs all automatic enrollment, not just BYOD. Autopilot devices do not bypass it; if it is None, even corporate devices will not auto-enroll.
- B. A missing deployment profile produces a generic OOBE, but the described symptom (Entra join succeeds, then no Intune management at all) is the signature of MDM user scope = None, which disables automatic enrollment entirely.
- C. MAM (WIP) user scope governs app-level management for personal devices; it does not enroll a device into Intune MDM. For a user in both scopes on a personal device the MAM scope can even take precedence and block MDM enrollment.
Memory hook: MDM user scope None = joins Entra, then stops. Set it to Some or All for Autopilot to enroll.
Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/windows/guide
A lab device was provisioned once with Windows Autopilot self-deploying mode. An engineer wipes it and tries to run it through Autopilot again, but provisioning now fails with error 0x80180014. The Autopilot profile and enrollment settings are unchanged. What must the engineer do so the device can be redeployed?
Correct answer: C. Delete the device record in Intune (Devices, then All devices, then select it, then Delete) before redeploying, because a self-deploying or pre-provisioned device can't automatically re-enroll through Autopilot.
A device provisioned with self-deploying mode (or pre-provisioning mode) can't automatically re-enroll through Windows Autopilot. When such a device is reused, reset, or redeployed, it fails with error 0x80180014. The fix is to delete the device record in the Intune admin center (Devices, then All devices, then select the device, then Delete), or use Unblock device on the Autopilot device record, before rerunning the deployment. A separate cause of 0x80180014 is Windows MDM enrollment being blocked by an enrollment restriction.
Why the other options are wrong:
- A. The 10-minute throttle applies to Autopilot device syncs after import, not to this per-device re-enrollment block. Waiting does not clear 0x80180014.
- B. The hardware hash and registration are intact and aren't the problem. Re-importing the hash does not clear the one-time enrollment block that self-deploying leaves behind.
- D. Changing the mode doesn't remove the existing Intune device record that is blocking re-enrollment, and it changes the deployment behavior unnecessarily.
Memory hook: Reused self-deploying/pre-provisioned device fails 0x80180014. Delete its Intune device record first.
Microsoft Learn: https://learn.microsoft.com/autopilot/self-deploying#requirements
A new corporate Windows 11 laptop shipped with many preinstalled OEM manufacturer apps ('bloatware'). An administrator wants an Intune remote action that removes installed apps to clean up the device, while offering the option to keep the signed-in user's files. Which action is designed for this?
Correct answer: C. Fresh Start (optionally with 'Retain user data on this device')
The Fresh Start action removes apps from a managed Windows device, which is specifically useful for removing preinstalled OEM apps that ship on a new PC. Choosing 'Retain user data on this device' keeps the device Microsoft Entra joined, automatically re-enrolls it in MDM at next sign-in, and preserves the user's Home folder while still removing apps and settings. If user data isn't retained, the device returns to a clean OOBE-completed state.
Why the other options are wrong:
- A. Retire removes company data and unenrolls the device. It doesn't remove preinstalled OEM apps or reinstall a clean Windows state.
- B. A full Wipe factory-resets everything and removes all apps and (by default) data. It's heavier than needed and doesn't target removing installed apps while optionally keeping user files.
- D. Autopilot Reset returns the device to its original IT-approved configuration for reassignment. It isn't the purpose-built strip-OEM-apps action and doesn't offer the Fresh Start retain-user-data behavior.
Memory hook: Strip OEM bloatware, optionally keep the user's files = Fresh Start (CleanPC).
Microsoft Learn: https://learn.microsoft.com/intune/device-management/actions/fresh-start
Your organization wants to move a fleet of Microsoft Entra hybrid joined Windows laptops to Microsoft Entra join (cloud-native). A colleague suggests running Autopilot Reset on each device to flip the join type in place. What is the accurate guidance?
Correct answer: A. There is no supported path to convert an existing hybrid joined device to Entra join without a full device wipe, and Autopilot Reset does not support hybrid joined devices
Microsoft states there is no supported process to convert an existing device from hybrid join to Entra join without a Windows reset (full wipe). Additionally, Autopilot Reset does not support hybrid joined devices, so it cannot perform the conversion. The supported approach is a full wipe and re-provision as Entra join.
Why the other options are wrong:
- B. dsregcmd /leave removes the join state but does not cleanly convert the device to Entra join; a reset and re-provision is required.
- C. Autopilot Reset does not support hybrid joined devices and cannot flip the join type in place.
- D. Reassigning an Autopilot profile does not re-join an already-provisioned device; join type is set at provisioning time.
Memory hook: Hybrid to Entra join means wipe and reprovision; Autopilot Reset won't touch hybrid.
Microsoft Learn: https://learn.microsoft.com/intune/solutions/cloud-native-endpoints/entra-join-types
An administrator has assigned two different Windows Autopilot device preparation policies to the same user group. During a user-driven deployment, the administrator needs to predict which policy the device will use. How does Windows Autopilot device preparation resolve which policy applies when a user is targeted by more than one?
Correct answer: A. The policy with the highest priority (highest in the Device preparation policies list, with the smallest number in the Priority column) applies; priority is changed by dragging policies in the list.
When multiple Windows Autopilot device preparation policies are deployed to a user, the policy with the highest priority applies. In the Device preparation policies list the highest-priority policy sits at the top and shows the smallest number in the Priority column, and you reorder policies (changing priority) by dragging them within the list. This is deliberately different from classic Windows Autopilot deployment profiles, where a device that lands in multiple assigned groups receives the oldest-created profile.
Why the other options are wrong:
- B. Device preparation does not merge policies. A single policy is selected by priority, and only that policy's selected apps and scripts deploy.
- C. Oldest-created-wins is the conflict rule for classic Windows Autopilot deployment profiles, not device preparation. Device preparation uses an explicit, drag-to-reorder priority list.
- D. Modification date is not the tiebreaker. Selection follows the priority ordering shown in the Device preparation policies list.
Memory hook: Device preparation = priority list (top wins, drag to reorder). Classic Autopilot = oldest-created profile wins.
Microsoft Learn: https://learn.microsoft.com/autopilot/device-preparation/tutorial/user-driven/entra-join-autopilot-policy#policy-priority
In your Windows Autopilot deployment profile you set "Allow pre-provisioned deployment" to No because you do not want technicians using the pre-provisioning (white glove) flow. During OOBE on a target device, a technician presses the Windows key five times and attempts the pre-provisioning path anyway. What happens?
Correct answer: A. Intune enforces the profile setting and pre-provisioning fails with error 0x80180005
Pressing the Windows key five times at OOBE can invoke the pre-provisioning path, but Intune enforces the "Allow pre-provisioned deployment" setting. When it is set to No, the pre-provisioning attempt fails with error 0x80180005 instead of continuing.
Why the other options are wrong:
- B. It does not silently fall back to user-driven mode; the pre-provisioning attempt errors out.
- C. The key shortcut can invoke the path, but the profile setting is enforced and blocks it.
- D. The five-key shortcut is not gated by ESP assignment; the block comes from the profile setting being No.
Memory hook: Pre-provision set to No means the white-glove attempt dies at 0x80180005.
Microsoft Learn: https://learn.microsoft.com/autopilot/profiles
An administrator configures an ESP profile with 'Install Windows quality updates' set to Yes. The target Windows 11 devices are enrolled but are NOT registered for Windows Autopilot. To which assignment must BOTH the Update Rings policy and the ESP profile be set so quality updates install during OOBE, and which Autopilot scenario cannot install them at all because it does not use the ESP?
Correct answer: D. All Devices; Windows Autopilot device preparation does not support it
For the 'Install Windows quality updates' ESP setting to work on non-Autopilot-registered devices, both the Update Rings policy and the ESP profile must be assigned to 'All Devices'. Additionally, Windows Autopilot device preparation does not use ESP at all, so this setting is not applicable and monthly security updates cannot be installed during OOBE for that scenario.
Why the other options are wrong:
- A. User-targeted assignments are not supported for the quality update installation feature. The ESP setting documentation specifically requires device-targeted (All Devices) assignment, not user-targeted assignment.
- B. Self-deploying mode is device-targeted and does support installing quality updates during OOBE, so this option's unsupported-scenario claim is false. Also, for non-Autopilot devices the assignment must be All Devices, not specific groups.
- C. Windows Autopilot user-driven mode does support the 'Install Windows quality updates' setting when the assignment and configuration requirements are met. The unsupported scenario is Windows Autopilot device preparation, not user-driven mode.
Memory hook: Quality updates during OOBE = All Devices assignment. Device preparation = no ESP = no quality updates.
Microsoft Learn: https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enrollment-status
During a Windows Autopilot pre-provisioned deployment, a technician completes the technician flow and sees a success screen. The device is resealed and shipped to the end user. The end user powers on the device but reports that several device-targeted apps that were assigned to the device, and should have installed during the technician flow, are missing when they reach the desktop. What configuration change would most directly prevent this outcome?
Correct answer: A. Ensure that the Enrollment Status Page (ESP) is enabled and configured to block device use until all apps are installed.
The technician flow inherits behavior from self-deploying mode and uses the ESP to hold the device in provisioning state. If the ESP is disabled or not configured to block on app installation, the Reseal button can appear before apps finish installing. Microsoft explicitly recommends keeping the ESP enabled for pre-provisioned deployments because the success screen only confirms enrollment success, not completion of app/config installation.
Why the other options are wrong:
- B. Changing to self-deploying mode would prevent user-account-based deployment entirely and is a different scenario. The pre-provisioned user-driven mode is appropriate here.
- C. Adding the user to the app-assignment group only affects user-targeted apps delivered during the user flow; it does not explain device-targeted apps missing after the technician flow, where the root cause is the ESP not holding the device until app installation completes.
- D. 'Allow pre-provisioned deployment' must already be enabled in the Autopilot profile for this scenario to work at all. Enabling it does not address apps missing after the technician flow completes.
Memory hook: ESP is the gate that holds the technician flow until apps land. Drop the gate and the device reseals half-provisioned.
Microsoft Learn: https://learn.microsoft.com/autopilot/tutorial/pre-provisioning/azure-ad-join-technician-flow#technician-flow-tips
An administrator creates an Enrollment Status Page (ESP) profile in Intune with 'Block device use until all apps and profiles are installed' set to Yes and 'Block device use until these required apps are installed' set to Selected with App1, App2, and App3 listed. The device also has App4 assigned but App4 is not in the blocking list. What happens if App4 fails to install during the device setup phase of the ESP?
Correct answer: A. The ESP ignores the App4 failure and the deployment can continue, with App4 installation retried in other flows
The ESP blocking app list filters which apps are tracked as blocking. If App4 is assigned to the device but not included in the 'Selected' blocking apps list, the ESP does not wait for App4 to complete. The deployment can succeed even if App4 fails. Importantly, for some app types (Win32, Microsoft Store, Enterprise app catalog apps), non-blocking apps are not installed during ESP at all and will install after the ESP completes.
Why the other options are wrong:
- B. Only the apps in the 'Selected' blocking list are required for ESP completion. App4, being outside that list, is not a blocking requirement even though it is assigned to the device.
- C. Intune does not remove app assignments based on ESP behavior. Assignment targets remain unchanged; the ESP simply does not track non-blocking apps during provisioning.
- D. The ESP only tracks apps in its blocking list. It does not wait for, or time out on, apps that are assigned to a device but not listed as blocking apps.
Memory hook: ESP blocks on only the list you name. Apps outside that list are invisible to the ESP gate.
Microsoft Learn: https://learn.microsoft.com/en-us/mem/intune/enrollment/windows-enrollment-status
An administrator creates an Enrollment Status Page (ESP) profile and sets 'Block device use until these required apps are installed' to 'Selected,' then adds App1, App2, and App3 to the blocking list. App3 and App4 are both assigned to the device as required apps. What happens during enrollment?
Correct answer: D. The ESP blocks only until App3 installs, because it is the only app in both the blocking list and the device assignment.
When 'Selected' apps are configured as blocking, the ESP uses the blocking app list as a filter against what is actually assigned to the device or user. In this scenario, App1 and App2 are in the blocking list but not assigned to the device, so they are not tracked. App3 is in both the blocking list and assigned as a required app, so the ESP waits for App3. App4 is assigned but not in the blocking list, so in non-pre-provisioning flows with Win32, Store, or Enterprise catalog apps, App4 may not install until after ESP completes.
Why the other options are wrong:
- A. The ESP does not block on App1 or App2 because they are in the blocking list but are not assigned to the device. The blocking list acts as a filter on the assigned apps, not as a standalone install mandate.
- B. App4 does get installed, just not necessarily during the ESP blocking phase. In user-driven and self-deploying modes, Win32, Store, and Enterprise catalog apps not in the blocking list install after the ESP completes.
- C. The 'Selected' blocking list filters which assigned apps the ESP waits for. It does not cause the ESP to wait for apps that are in the blocking list but not assigned (App1, App2), nor does it automatically add all assigned apps (App4) to the blocking requirement.
Memory hook: Blocking list = filter, not a grocery list. ESP only waits for apps that are BOTH in the blocking list AND assigned to the device.
Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/windows/setup-status-page#prioritize-profiles
A company is deploying shared kiosk devices using Windows Autopilot. The devices should provision automatically with no user interaction at all (including no language or keyboard selection prompts) when connected via Ethernet. Which Windows Autopilot deployment mode should the administrator choose?
Correct answer: C. Self-deploying mode
Windows Autopilot self-deploying mode requires little to no user interaction. When a device is connected via Ethernet, the entire provisioning process is fully automated with no prompts for language, locale, keyboard, or credentials. This mode is designed for kiosk, digital signage, and shared devices. It requires TPM 2.0 and is only supported with Microsoft Entra join (not hybrid join).
Why the other options are wrong:
- A. User-driven mode with Entra join still requires the user to enter Microsoft Entra credentials during OOBE. It is not fully automated for shared or kiosk devices with no user.
- B. User-driven hybrid join requires user credential input and also requires the Intune Connector for Active Directory. It is not designed for zero-touch kiosk provisioning.
- D. Pre-provisioning (white glove) mode is designed to split provisioning between a technician phase and a user phase, reducing end-user setup time. It is not a fully automated mode for kiosk devices.
Memory hook: Kiosk, no user = self-deploying. TPM 2.0 required. Entra join only.
Microsoft Learn: https://learn.microsoft.com/en-us/autopilot/self-deploying
During a Windows Autopilot self-deploying deployment, a device fails with error 0x800705B4. What is the most likely cause?
Correct answer: B. The device does not have TPM 2.0 support or TPM device attestation failed
Windows Autopilot self-deploying mode uses TPM 2.0 hardware to authenticate the device into the Microsoft Entra tenant without user credentials. If a device does not support TPM 2.0 (including Hyper-V virtual machines with virtual TPMs), the attestation process fails with the 0x800705B4 timeout error. This is a hard requirement for self-deploying mode.
Why the other options are wrong:
- A. Joining an incorrect tenant would produce authentication or enrollment errors after the attestation phase succeeds, not the 0x800705B4 timeout that occurs during TPM attestation.
- C. If the Autopilot profile was not assigned, the device would proceed through a standard Windows OOBE rather than failing with 0x800705B4. The profile must be assigned before deployment, but its absence produces a different experience, not this specific error.
- D. An ESP timeout produces a different error experience and error codes. The 0x800705B4 error specifically occurs during the device attestation phase before ESP is even reached.
Memory hook: 0x800705B4 = TPM timeout. Self-deploying requires real TPM 2.0 - virtual TPMs fail here.
Microsoft Learn: https://learn.microsoft.com/en-us/autopilot/self-deploying
In an Enrollment Status Page profile, an administrator wants that if a tracked app fails during provisioning, the end user is given a button to bypass the ESP and start using the device rather than being forced to reset it. The administrator also wants to raise how long the ESP waits before showing a timeout error. Which two ESP settings should be configured?
Correct answer: D. Set 'Allow users to use device if installation error occurs' to Yes, and increase 'Show an error when installation takes longer than specified number of minutes' above its 60-minute default.
'Allow users to use device if installation error occurs' = Yes gives users the option to bypass the ESP and use the device when an installation fails, as opposed to 'Allow users to reset device if installation error occurs,' which offers a reset instead. The ESP timeout is controlled by 'Show an error when installation takes longer than specified number of minutes,' which defaults to 60 minutes; enter a higher value to allow more time before the timeout error appears. Both are configured on the ESP profile's Settings page.
Why the other options are wrong:
- A. Setting progress display to No hides the ESP entirely, and a custom message only changes the error text. Neither provides a bypass button or extends the timeout window.
- B. 'Only show page to devices provisioned by OOBE' and log collection control where the ESP appears and diagnostics, not whether users can bypass on failure or how long the timeout is.
- C. 'Allow users to reset device if installation error occurs' offers a reset, which is exactly what the admin wants to avoid, and the blocking-app scope does not control the bypass or timeout behavior described.
Memory hook: Bypass-on-failure = 'Allow users to use device if installation error occurs' (Yes). Timeout = 'Show an error when installation takes longer than...' (default 60 min).
Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/windows/setup-status-page#create-new-profile
An organization has enabled co-management. Before moving compliance management for the whole fleet to Intune, the team wants to shift the Compliance policies workload to Intune for only a small set of test machines defined by a Configuration Manager collection. On the co-management Workloads tab, which slider setting does this, and what must be defined?
Correct answer: D. Set the workload to Pilot Intune; define the pilot collection on the Staging tab of the co-management properties.
On the co-management Workloads tab, moving a workload slider to Pilot Intune switches that workload to Intune only for the devices in the pilot collection, which you specify on the Staging tab of the co-management properties. Setting the slider to Intune instead switches the workload for all co-managed Windows devices. Pilot Intune is the staged/test setting; Intune is the all-devices setting. Each workload can use a different pilot collection.
Why the other options are wrong:
- A. Configuration Manager keeps the workload with ConfigMgr (no switch to Intune at all), and co-management pilots use a Configuration Manager collection, not a Microsoft Entra dynamic group.
- B. Setting the workload to Intune switches it for all co-managed devices, not just a test subset. Piloting to a subset uses Pilot Intune plus a Configuration Manager pilot collection, not an Intune assignment filter.
- C. Leaving the slider on Configuration Manager doesn't move any authority to Intune. Co-management workload switching is done in the Configuration Manager co-management properties, not solely from the Intune console.
Memory hook: Pilot Intune = switch the workload for the pilot collection (set on the Staging tab). Intune = switch it for all co-managed devices.
Microsoft Learn: https://learn.microsoft.com/intune/configmgr/comanage/how-to-switch-workloads#switch-workloads
A device is a member of two Microsoft Entra security groups, and each group has a different Windows Autopilot deployment profile assigned to it. Neither profile is the tenant default. Which profile does the device receive?
Correct answer: B. The oldest created of the two profiles.
When a device belongs to multiple groups that each have a Windows Autopilot deployment profile assigned, Intune resolves the conflict by applying the oldest created profile. The creation date, visible in the Created field under Essentials on the profile, is the tiebreaker, not the newest profile, group size, or assignment order. This trips up engineers who assume the most recently created profile wins.
Why the other options are wrong:
- A. This is the common wrong assumption. Autopilot does not prefer the newest profile; the oldest created profile wins the conflict.
- C. Group membership size has no bearing on Autopilot profile conflict resolution. The deciding factor is which profile was created first.
- D. A conflict between two assigned profiles does not drop the device to a bare OOBE. Intune deterministically selects the oldest profile.
Memory hook: Two Autopilot profiles collide, the oldest created profile wins. Check the Created date.
Microsoft Learn: https://learn.microsoft.com/autopilot/profiles#windows-autopilot-profile-priority
You want new Autopilot Windows devices to stay locked on the Enrollment Status Page until three specific business-critical apps finish installing, but you do not want the ESP to wait on every other assigned app. Which ESP setting achieves this?
Correct answer: A. Set "Block device use until these required apps are installed if they're assigned to the user/device" and select the three apps (up to 100 can be chosen)
The ESP lets you either block on all apps and profiles, or specify a filtered blocking list via "Block device use until these required apps are installed." You can choose up to 100 apps; the ESP then waits only for the listed apps that are also assigned to the user or device, not for every assigned app.
Why the other options are wrong:
- B. "Only show page to devices provisioned by OOBE" controls who sees the ESP, not which apps block, and it is not an app list.
- C. That waits on every assigned app and profile, which is exactly what you are trying to avoid.
- D. The timeout only controls when an installation error is shown; it does not choose which apps block.
Memory hook: Wait on just some apps? Use the 'required apps' list (up to 100), not 'all apps.'
Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/windows/setup-status-page
An administrator sets up Windows Autopilot device preparation. A user-driven deployment completes and users reach the desktop, but none of the apps or PowerShell scripts selected in the device preparation policy are installed, and the devices never appear in the target device security group. Which misconfiguration is the most likely cause?
Correct answer: D. The target device security group is missing the Intune Provisioning Client as an owner, or the group has 'Microsoft Entra roles can be assigned to the group' set to Yes.
Device preparation relies on Enrollment Time Grouping: at enrollment, Intune writes the device into the named static security group so assigned apps, scripts, and policies apply. For this to work, the Intune Provisioning Client service principal (AppId f1346770-5b25-470b-88bd-d5744ab7952c) must be an owner of that group, and the group must have 'Microsoft Entra roles can be assigned to the group' set to No. If the owner is missing or the group is role-assignable, the device never joins the group, so nothing assigned to it is delivered. The admin also needs the 'Enrollment time device membership assignment' RBAC permission.
Why the other options are wrong:
- A. Device preparation policies are correctly assigned to a user group by design, and the deployment reaching the desktop shows the policy applied. The failure is the device not joining the target group, not a device-group assignment.
- B. Device preparation deliberately requires no hardware-hash pre-registration. Missing hashes cannot be the cause because hashes are not used in this model.
- C. Apps for device preparation must be both selected in the policy and assigned to the device security group. But the described symptom, the device never joining the group at all, points to the Enrollment Time Grouping owner or role-assignable misconfiguration, not an app assignment gap.
Memory hook: No apps and device not in group = Intune Provisioning Client not owner, or the group is role-assignable (it must be No).
Microsoft Learn: https://learn.microsoft.com/intune/device-enrollment/setup-time-grouping
An organization ships Microsoft Entra hybrid join Autopilot devices directly to remote employees who have no corporate network connectivity at first boot. To let these devices complete the on-premises domain join over a VPN, which Autopilot deployment profile setting must be changed, and what companion requirement applies?
Correct answer: C. Set 'Skip Domain Connectivity Check' to Yes, and deploy a supported VPN solution via Intune (not one that uses user certificates or a UWP Store plug-in).
For off-premises Microsoft Entra hybrid join, set Skip Domain Connectivity Check to Yes so provisioning does not fail when a domain controller cannot be pinged. This does not remove the need to reach a DC; it relies on a VPN that Intune deploys and configures before the user signs in. The VPN must be deployable through Intune and cannot be one that uses user certificates or a non-Microsoft UWP VPN plug-in from the Store, because the user context is not established when the connection must be made.
Why the other options are wrong:
- A. Leaving the setting at No requires direct DC connectivity and fails for a remote device with no LAN or VPN path. That is precisely the scenario the Yes setting plus a VPN addresses.
- B. Self-deploying mode supports only Microsoft Entra join and no user. It cannot perform a hybrid domain join, so it does not satisfy the requirement to domain-join these devices.
- D. 'Convert all targeted devices to Autopilot' only registers devices with the Autopilot deployment service. It has nothing to do with domain-controller connectivity during the hybrid join.
Memory hook: Remote hybrid join = Skip Domain Connectivity Check: Yes + an Intune-deployed VPN (no user-cert or UWP VPNs).
Microsoft Learn: https://learn.microsoft.com/autopilot/user-driven#user-driven-mode-for-microsoft-entra-hybrid-join