Autopilot Scenarios
In brief
The page description, scenario table formatting, punctuation, and terminology were updated for clearer presentation, including replacing “utilizes” with “uses.”
What Intune admins need to know
Administrators can continue using the guidance; no action is indicated.
This summary was assembled from the tracked documentation change. Verify important details in the full Microsoft Learn article.
Documentation change
The comparison below shows only the changed extract. Use the full-page view for complete context.
feedback_system: Standard
permissioned-type: public
uhfHeaderId: MSDocsHeader-Windows
description: DescribesLearn about the different Windows Autopilot scenarios.scenarios due to different environments, different configurations, and different needs.
ms.date: 2025-06-13T00:2026-10-23T00:00:00.0000000Z
ms.topic: tutorial
ms.collection:
- essentials-get-started
Due to different environments, different configurations, and different needs, Windows Autopilot offers several different scenarios. The following table summarizes the scenarios that are available in Windows Autopilot:
| Scenario | Purpose | Description |
|---|---|---|
| Windows Autopilot user-driven mode | Device for a single user | User runs deployment |
| Windows Autopilot for pre-provisioned | Device for a single user | Deployment is split between IT admin/OEM/reseller and user |
| Windows Autopilot self-deploying mode | Kiosk device or device for multiple users | Deployment is completely automated |
| Windows Autopilot for existing devices | Prepare device where Windows OS needs to be reinstalled for a Windows Autopilot deployment | |
| Windows Autopilot Reset | Resets an existing device back to the factory default installation of Windows |
Note
Note
The Windows Autopilot for existing devices scenario is a method to completely reinstall Windows on a device in preparation to run a Windows Autopilot deployment. HoweverHowever, the Windows Autopilot for existing devices scenario itself isn't technically a Windows Autopilot deployment. After the Windows Autopilot for existing devices process completes, it automatically runs a Windows Autopilot scenario.
The abovepreceding table lists what the Windows Autopilot for existing devices scenario can potentially support. However, aA given Windows Autopilot scenario might not always be supported oncewhen the Windows Autopilot for existing devices scenario completes.
Scenario pros and cons
| Scenario | Pros | Cons |
|---|---|---|
| User-driven | • Requires no interaction from |
• Takes longer for user than the pre-provisioned scenario since user has to go through both device ESP and user ESP. |
| Pre-provisioned | • Faster for user since IT |
• Requires interaction by IT |
| Self-deploying | • Requires no interaction from user or |
• Can't assign a user to the device. • User ESP doesn't run during the Windows Autopilot deployment since no user is assigned. • Requires TPM attestation so only works on physical devices with supported TPM (doesn't work in VMs even with virtual TPM). • Doesn't support Microsoft Entra hybrid join devices. |
| Existing devices | • Can use custom images. • Can use ConfigMgr task sequences. • Can reinstall a fresh copy of Windows in cases of severe corruption in Windows installation. • Good scenario to upgrade a device from domain joined or Microsoft Entra hybrid join to Microsoft Entra join. | • Requires Microsoft Configuration Manager. • Not an actual Windows Autopilot deployment so doesn't work on its own - only works alongside one a supported Windows Autopilot scenario. • Takes longer since device has to undergo both task sequence and Windows Autopilot deployment. • JSON file only supports user-driven Windows Autopilot scenarios. • Pre-provisioning and self-deploying |
| Reset | • Easily allows resetting an existing broken or repurposed device to a business ready state. | • Doesn't work if there's severe corruption in Windows installation. • Doesn't support Microsoft Entra hybrid join devices. |
Microsoft Entra join and Microsoft Entra hybrid join vs. Windows Autopilot scenarios
- Device identities being used going forward.
- Possible device identities being used in the future.
Microsoft recommends deploying new devices as cloud-native using Microsoft Entra join. Deploying new devices as Microsoft Entra hybrid join devices isn't recommended, including through Windows Autopilot. Microsoft Entra join provides the best user experience. However, currentCurrent environment configurations and restrictions might require the continued use of on-premises Active Directory.
In scenarios where on-premises Active Directory is still needed, Microsoft Entra hybrid join can be used. However, considerConsider moving new devices to Microsoft Entra join while keeping existing devices on Microsoft Entra hybrid join. Microsoft Entra hybrid join can also be seen as a way to transition from on-premises Active Directory to purely Microsoft Entra ID.
Also keep in mind that for the Windows Autopilot deployments that support Microsoft Entra hybrid join, Microsoft Entra hybrid join requires connectivity to a domain controller. If the device undergoing a Windows Autopilot deployment is a remote device and isn't able to connect to a domain controller either on-premises or via a VPN connection, then only Microsoft Entra join is an option.
For more information on Microsoft Entra join versus Microsoft Entra hybrid join, see the following articles:
- Microsoft Entra joined vs. Microsoft Entry hybrid joined in cloud-native endpoints
. - What is a device identity?.
- Learn more about cloud-native endpoints
. - Tutorial: Set up and configure a cloud-native Windows endpoint with Microsoft Intune
. - How to: Plan your Microsoft Entra join implementation
. - A framework for Windows endpoint management transformation
. - Understanding hybrid Azure AD and co-management scenarios
. - Success with remote Windows Autopilot and hybrid Azure Active Directory join
.
Which Windows Autopilot scenario to use
WhichThe Windows Autopilot scenario should be usedyou use depends on various factorsfactors, including the environment and the needs of theyour organization. The first thing to account for isConsider which type of device identity (Microsoft Entra ID or hybrid Microsoft Entra ID) isyour environment currently being used in the environment. Whichuses. The device identity is being used mayyou use can restrict which Windows Autopilot scenarios you can be useduse in theyour environment.
The following guide makes general suggestions on which Windows Autopilot scenario to use:
- Windows Autopilot user-driven supports both Microsoft Entra join and Microsoft Entra hybrid join.
- The device is intended to be used primarily by a single user.
IfYou need to ship and deliver the deviceneeds to be shipped and delivereddirectly to theend-end user without IT admin intervention.If theThe OEM or reselleris unable tocan't perform the technician flow of the Windows Autopilot pre-provision scenario.If virtualVirtual machines (VMs) need to undergo the Windows Autopilot deployment process.
Pre-provisioned
- Windows Autopilot for pre-provisioned supports both Microsoft Entra join and Microsoft Entra hybrid join.
- The device is intended to be used primarily by a single user.
TheYou need to minimize the deployment time that theend-end userexperiences needs to be minimized.experiences.Is anAn IT admin, an OEM, or a resellerable tocan handle the technician flow and the first half of the deployment. If an IT admin handles the technician flow,thenyou might need to first ship the devicemay need to be first shippedto the IT admin to perform the technician flow, followed by shipping or delivering the deviceshipped or deliveredto theend-end user.- In Microsoft Entra hybrid join scenarios, if the OEM or reseller is performing the technician flow, their environment must have connectivity to a domain controller for the organization.
- Windows Autopilot for pre-provisioned uses TPM attestation for authentication during the technician
flowflow, so only devices that have a supported TPM are supported. For this reason, virtual machines (VMs) aren't supported even when the VM has a virtual TPM.
Self-deploying mode
Reset
- Windows Autopilot Reset isn't a Windows Autopilot deployment itself, but a method to reset an existing Windows Autopilot device to a
businessbusiness-ready state. - The device needs to be registered as a Windows Autopilot device.
- Windows Autopilot Reset only supports existing Microsoft Entra join devices. It doesn't support existing Microsoft Entra hybrid join devices.
WhenUse when the current Windows installation is in a stable non-corrupted state. If the Windows installation is in a corrupted state, use Windows Autopilot for existing devices instead.WhenUse when you need to repurpose thedevice needs to repurposed,device, such as forexample toa new user.WhenUse when you need to reset the deviceneeds to be resetto resolve ongoing problems on the device. Sometimes it's better and quicker to reset a device than to troubleshoot and fixon goingongoing problems on the device.
Next steps: Scenario walkthroughs
The following list contains links to Windows Autopilot scenario walkthroughs. The walkthroughs contain step by step-by-step instructions on how to configure each of the Windows Autopilot scenarios:
Windows Autopilot user-driven mode:
Windows Autopilot for pre-provisioned deployment:
@@ -13,8 +13,8 @@ feedback_product_url: https://feedbackportal.microsoft.com/feedback/forum/ef1d6d feedback_system: Standard permissioned-type: public uhfHeaderId: MSDocsHeader-Windows-description: Describes the different Windows Autopilot scenarios.-ms.date: 2025-06-13T00:00:00.0000000Z+description: Learn about the different Windows Autopilot scenarios due to different environments, different configurations, and different needs.+ms.date: 2026-10-23T00:00:00.0000000Z ms.topic: tutorial ms.collection: - essentials-get-started@@ -47,13 +47,13 @@ platformId: 1cca9729-ccd6-814a-43e9-0dbf12ba54ce Due to different environments, different configurations, and different needs, Windows Autopilot offers several different scenarios. The following table summarizes the scenarios that are available in Windows Autopilot:
-| **Scenario** | **Purpose** | **Description** |
+| Scenario | Purpose | Description |
| --- | --- | --- |
| **Windows Autopilot user-driven mode** | Device for a single user | User runs deployment |
| **Windows Autopilot for pre-provisioned** | Device for a single user | Deployment is split between IT admin/OEM/reseller and user |
| **Windows Autopilot self-deploying mode** | Kiosk device or device for multiple users | Deployment is completely automated |
-| **Windows Autopilot for existing devices** | Prepare device where Windows OS needs to be reinstalled for a Windows Autopilot deployment | Utilizes Microsoft Configuration Manager to install a fresh Windows OS on an existing device before running a Windows Autopilot deployment |
-| **Windows Autopilot Reset** | Resets an existing device back to the factory default installation of Windows | Utilizes the existing installation of Windows on a device to rebuild Windows and restore it back to the factory installation of Windows |
+| **Windows Autopilot for existing devices** | Prepare device where Windows OS needs to be reinstalled for a Windows Autopilot deployment | Uses Microsoft Configuration Manager to install a fresh Windows OS on an existing device before running a Windows Autopilot deployment |
+| **Windows Autopilot Reset** | Resets an existing device back to the factory default installation of Windows | Uses the existing installation of Windows on a device to rebuild Windows and restore it back to the factory installation of Windows |
Note
@@ -77,9 +77,9 @@ The following table compares the different capabilities for each Windows Autopil
Note
-The **Windows Autopilot for existing devices** scenario is a method to completely reinstall Windows on a device in preparation to run a Windows Autopilot deployment. However the Windows Autopilot for existing devices scenario itself isn't technically a Windows Autopilot deployment. After the Windows Autopilot for existing devices process completes, it automatically runs a Windows Autopilot scenario.
+The **Windows Autopilot for existing devices** scenario is a method to completely reinstall Windows on a device in preparation to run a Windows Autopilot deployment. However, the Windows Autopilot for existing devices scenario itself isn't technically a Windows Autopilot deployment. After the Windows Autopilot for existing devices process completes, it automatically runs a Windows Autopilot scenario.
-The above table lists what the Windows Autopilot for existing devices scenario can potentially support. However, a given Windows Autopilot scenario might not always be supported once the **Windows Autopilot for existing devices** scenario completes.
+The preceding table lists what the Windows Autopilot for existing devices scenario can potentially support. A given Windows Autopilot scenario might not always be supported when the **Windows Autopilot for existing devices** scenario completes.
## Scenario pros and cons
@@ -87,10 +87,10 @@ The following table describes the pros and cons of each Windows Autopilot scenar
| **Scenario** | **Pros** | **Cons** |
| --- | --- | --- |
-| **User-driven** | • Requires no interaction from admin/OEM/reseller. • Doesn't require [TPM attestation](/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation) so works on physical devices and VMs. | • Takes longer for user than the pre-provisioned scenario since user has to go through both device ESP and user ESP. |
-| **Pre-provisioned** | • Faster for user since IT admin/OEM/reseller handles bulk of device ESP during the technician flow. | • Requires interaction by IT admin/OEM/reseller. • Requires [TPM attestation](/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation) during technician flow so only works on physical devices with supported TPM (doesn't work in VMs even with virtual TPM). |
-| **Self-deploying** | • Requires no interaction from user or admin/OEM/reseller. | • Can't assign a user to the device. • User ESP doesn't run during the Windows Autopilot deployment since no user is assigned. • Requires [TPM attestation](/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation) so only works on physical devices with supported TPM (doesn't work in VMs even with virtual TPM). • Doesn't support Microsoft Entra hybrid join devices. |
-| **Existing devices** | • Can use custom images. • Can use ConfigMgr task sequences. • Can reinstall a fresh copy of Windows in cases of severe corruption in Windows installation. • Good scenario to upgrade a device from domain joined or Microsoft Entra hybrid join to Microsoft Entra join. | • Requires Microsoft Configuration Manager. • Not an actual Windows Autopilot deployment so doesn't work on its own - only works alongside one a supported Windows Autopilot scenario. • Takes longer since device has to undergo both task sequence and Windows Autopilot deployment. • JSON file only supports user-driven Windows Autopilot scenarios. • Pre-provisioning and self-deploying AWindows utopilot scenarios are only supported when the device is already a Windows Autopilot device and there's a Windows Autopilot profile assigned to the device. |
+| **User-driven** | • Requires no interaction from admin, OEM, or reseller. • Doesn't require [TPM attestation](/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation) so works on physical devices and VMs. | • Takes longer for user than the pre-provisioned scenario since user has to go through both device ESP and user ESP. |
+| **Pre-provisioned** | • Faster for user since IT admin, OEM, or reseller handles bulk of device ESP during the technician flow. | • Requires interaction by IT admin, OEM, or reseller. • Requires [TPM attestation](/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation) during technician flow so only works on physical devices with supported TPM, not on VMs even with virtual TPM. |
+| **Self-deploying** | • Requires no interaction from user or admin, OEM, or reseller. | • Can't assign a user to the device. • User ESP doesn't run during the Windows Autopilot deployment since no user is assigned. • Requires [TPM attestation](/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation) so only works on physical devices with supported TPM (doesn't work in VMs even with virtual TPM). • Doesn't support Microsoft Entra hybrid join devices. |
+| **Existing devices** | • Can use custom images. • Can use ConfigMgr task sequences. • Can reinstall a fresh copy of Windows in cases of severe corruption in Windows installation. • Good scenario to upgrade a device from domain joined or Microsoft Entra hybrid join to Microsoft Entra join. | • Requires Microsoft Configuration Manager. • Not an actual Windows Autopilot deployment so doesn't work on its own - only works alongside one a supported Windows Autopilot scenario. • Takes longer since device has to undergo both task sequence and Windows Autopilot deployment. • JSON file only supports user-driven Windows Autopilot scenarios. • Pre-provisioning and self-deploying Windows Autopilot scenarios are only supported when the device is already a Windows Autopilot device and there's a Windows Autopilot profile assigned to the device. |
| **Reset** | • Easily allows resetting an existing broken or repurposed device to a business ready state. | • Doesn't work if there's severe corruption in Windows installation. • Doesn't support Microsoft Entra hybrid join devices. |
## Microsoft Entra join and Microsoft Entra hybrid join vs. Windows Autopilot scenarios
@@ -101,24 +101,26 @@ Microsoft Entra join and Microsoft Entra hybrid join aren't Windows Autopilot sc - Device identities being used going forward.
- Possible device identities being used in the future.
-Microsoft recommends deploying new devices as cloud-native using Microsoft Entra join. Deploying new devices as Microsoft Entra hybrid join devices isn't recommended, including through Windows Autopilot. Microsoft Entra join provides the best user experience. However, current environment configurations and restrictions might require the continued use of on-premises Active Directory. In scenarios where on-premises Active Directory is still needed, Microsoft Entra hybrid join can be used. However, consider moving new devices to Microsoft Entra join while keeping existing devices on Microsoft Entra hybrid join. Microsoft Entra hybrid join can also be seen as a way to transition from on-premises Active Directory to purely Microsoft Entra ID.
+Microsoft recommends deploying new devices as cloud-native using Microsoft Entra join. Deploying new devices as Microsoft Entra hybrid join devices isn't recommended, including through Windows Autopilot. Microsoft Entra join provides the best user experience. Current environment configurations and restrictions might require the continued use of on-premises Active Directory.
+
+In scenarios where on-premises Active Directory is still needed, Microsoft Entra hybrid join can be used. Consider moving new devices to Microsoft Entra join while keeping existing devices on Microsoft Entra hybrid join. Microsoft Entra hybrid join can also be seen as a way to transition from on-premises Active Directory to purely Microsoft Entra ID.
Also keep in mind that for the Windows Autopilot deployments that support Microsoft Entra hybrid join, Microsoft Entra hybrid join requires connectivity to a domain controller. If the device undergoing a Windows Autopilot deployment is a remote device and isn't able to connect to a domain controller either on-premises or via a VPN connection, then only Microsoft Entra join is an option.
For more information on Microsoft Entra join versus Microsoft Entra hybrid join, see the following articles:
-- [Microsoft Entra joined vs. Microsoft Entry hybrid joined in cloud-native endpoints](/en-us/intune/solutions/cloud-native-endpoints/azure-ad-joined-hybrid-azure-ad-joined).
+- [Microsoft Entra joined vs. Microsoft Entry hybrid joined in cloud-native endpoints](/en-us/intune/solutions/cloud-native-endpoints/azure-ad-joined-hybrid-azure-ad-joined)
- [What is a device identity?](/en-us/azure/active-directory/devices/overview).
-- [Learn more about cloud-native endpoints](/en-us/intune/solutions/cloud-native-endpoints/cloud-native-endpoints-overview).
-- [Tutorial: Set up and configure a cloud-native Windows endpoint with Microsoft Intune](/en-us/intune/solutions/cloud-native-endpoints/cloud-native-windows-endpoints).
-- [How to: Plan your Microsoft Entra join implementation](/en-us/azure/active-directory/devices/device-join-plan).
-- [A framework for Windows endpoint management transformation](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/a-framework-for-windows-endpoint-management-transformation/ba-p/2460684).
-- [Understanding hybrid Azure AD and co-management scenarios](https://techcommunity.microsoft.com/t5/microsoft-endpoint-manager-blog/understanding-hybrid-azure-ad-join-and-co-management/ba-p/2221201).
-- [Success with remote Windows Autopilot and hybrid Azure Active Directory join](https://techcommunity.microsoft.com/t5/intune-customer-success/success-with-remote-windows-autopilot-and-hybrid-azure-active/ba-p/2749353).
+- [Learn more about cloud-native endpoints](/en-us/intune/solutions/cloud-native-endpoints/cloud-native-endpoints-overview)
+- [Tutorial: Set up and configure a cloud-native Windows endpoint with Microsoft Intune](/en-us/intune/solutions/cloud-native-endpoints/cloud-native-windows-endpoints)
+- [How to: Plan your Microsoft Entra join implementation](/en-us/azure/active-directory/devices/device-join-plan)
+- [A framework for Windows endpoint management transformation](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/a-framework-for-windows-endpoint-management-transformation/ba-p/2460684)
+- [Understanding hybrid Azure AD and co-management scenarios](https://techcommunity.microsoft.com/t5/microsoft-endpoint-manager-blog/understanding-hybrid-azure-ad-join-and-co-management/ba-p/2221201)
+- [Success with remote Windows Autopilot and hybrid Azure Active Directory join](https://techcommunity.microsoft.com/t5/intune-customer-success/success-with-remote-windows-autopilot-and-hybrid-azure-active/ba-p/2749353)
## Which Windows Autopilot scenario to use
-Which Windows Autopilot scenario should be used depends on various factors including the environment and the needs of the organization. The first thing to account for is which type of device identity (Microsoft Entra ID or hybrid Microsoft Entra ID) is currently being used in the environment. Which device identity is being used may restrict which Windows Autopilot scenarios can be used in the environment.
+The Windows Autopilot scenario you use depends on various factors, including the environment and the needs of your organization. Consider which type of device identity (Microsoft Entra ID or hybrid Microsoft Entra ID) your environment currently uses. The device identity you use can restrict which Windows Autopilot scenarios you can use in your environment.
The following guide makes general suggestions on which Windows Autopilot scenario to use:
@@ -126,18 +128,18 @@ The following guide makes general suggestions on which Windows Autopilot scenari
- Windows Autopilot user-driven supports both Microsoft Entra join and Microsoft Entra hybrid join.
- The device is intended to be used primarily by a single user.
-- If the device needs to be shipped and delivered directly to the end-user without IT admin intervention.
-- If the OEM or reseller is unable to perform the technician flow of the Windows Autopilot pre-provision scenario.
-- If virtual machines (VMs) need to undergo the Windows Autopilot deployment process.
+- You need to ship and deliver the device directly to the end user without IT admin intervention.
+- The OEM or reseller can't perform the technician flow of the Windows Autopilot pre-provision scenario.
+- Virtual machines (VMs) need to undergo the Windows Autopilot deployment process.
### Pre-provisioned
- Windows Autopilot for pre-provisioned supports both Microsoft Entra join and Microsoft Entra hybrid join.
- The device is intended to be used primarily by a single user.
-- The deployment time that the end-user experiences needs to be minimized.
-- Is an IT admin, an OEM, or a reseller able to handle the technician flow and the first half of the deployment. If an IT admin handles the technician flow, then the device may need to be first shipped to the IT admin to perform the technician flow, followed by the device shipped or delivered to the end-user.
+- You need to minimize the deployment time that the end user experiences.
+- An IT admin, an OEM, or a reseller can handle the technician flow and the first half of the deployment. If an IT admin handles the technician flow, you might need to first ship the device to the IT admin to perform the technician flow, followed by shipping or delivering the device to the end user.
- In Microsoft Entra hybrid join scenarios, if the OEM or reseller is performing the technician flow, their environment must have connectivity to a domain controller for the organization.
-- Windows Autopilot for pre-provisioned uses [TPM attestation](/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation) for authentication during the technician flow so only devices that have a supported TPM are supported. For this reason, virtual machines (VMs) aren't supported even when the VM has a virtual TPM.
+- Windows Autopilot for pre-provisioned uses [TPM attestation](/en-us/windows-server/identity/ad-ds/manage/component-updates/tpm-key-attestation) for authentication during the technician flow, so only devices that have a supported TPM are supported. For this reason, virtual machines (VMs) aren't supported even when the VM has a virtual TPM.
### Self-deploying mode
@@ -159,21 +161,23 @@ The following guide makes general suggestions on which Windows Autopilot scenari
### Reset
-- Windows Autopilot Reset isn't a Windows Autopilot deployment itself, but a method to reset an existing Windows Autopilot device to a business ready state.
+- Windows Autopilot Reset isn't a Windows Autopilot deployment itself, but a method to reset an existing Windows Autopilot device to a business-ready state.
- The device needs to be registered as a Windows Autopilot device.
- Windows Autopilot Reset only supports existing Microsoft Entra join devices. It doesn't support existing Microsoft Entra hybrid join devices.
-- When the current Windows installation is in a stable non-corrupted state. If the Windows installation is in a corrupted state, use Windows Autopilot for existing devices instead.
-- When the device needs to repurposed, for example to a new user.
-- When the device needs to be reset to resolve ongoing problems on the device. Sometimes it's better and quicker to reset a device than to troubleshoot and fix on going problems on the device.
+- Use when the current Windows installation is in a stable non-corrupted state. If the Windows installation is in a corrupted state, use Windows Autopilot for existing devices instead.
+- Use when you need to repurpose the device, such as for a new user.
+- Use when you need to reset the device to resolve ongoing problems on the device. Sometimes it's better and quicker to reset a device than to troubleshoot and fix ongoing problems on the device.
## Next steps: Scenario walkthroughs
-The following list contains links to Windows Autopilot scenario walkthroughs. The walkthroughs contain step by step instructions on how to configure each of the Windows Autopilot scenarios:
+The following list contains links to Windows Autopilot scenario walkthroughs. The walkthroughs contain step-by-step instructions on how to configure each of the Windows Autopilot scenarios:
1. Windows Autopilot user-driven mode:
+
1. [Microsoft Entra join](user-driven/azure-ad-join-workflow).
2. [Microsoft Entra hybrid join](user-driven/hybrid-azure-ad-join-workflow).
2. Windows Autopilot for pre-provisioned deployment:
+
1. [Microsoft Entra join](pre-provisioning/azure-ad-join-workflow).
2. [Microsoft Entra hybrid join](pre-provisioning/hybrid-azure-ad-join-workflow).
3. [Windows Autopilot self-deploying mode](self-deploying/self-deploying-workflow).