From d303a13a164ac23f6d8c955bf2e78da6aa8f1861 Mon Sep 17 00:00:00 2001 From: Greg Lindsay Date: Wed, 5 Aug 2020 10:43:40 -0700 Subject: [PATCH] migrate content to mem --- .openpublishing.redirection.json | 120 +++++ windows/deployment/TOC.yml | 4 +- windows/deployment/index.yml | 6 +- windows/deployment/windows-autopilot/TOC.md | 35 +- .../windows-autopilot/add-devices.md | 184 -------- .../autopilot-device-guidelines.md | 47 -- .../windows-autopilot/autopilot-faq.md | 165 ------- .../windows-autopilot/autopilot-mbr.md | 421 ------------------ .../windows-autopilot/autopilot-support.md | 37 -- .../windows-autopilot/autopilot-update.md | 48 -- .../deployment/windows-autopilot/bitlocker.md | 54 --- .../windows-autopilot/deployment-process.md | 27 -- .../windows-autopilot/dfci-management.md | 70 --- .../windows-autopilot/enrollment-status.md | 39 -- .../windows-autopilot/existing-devices.md | 324 -------------- windows/deployment/windows-autopilot/index.md | 78 ---- .../deployment/windows-autopilot/index.yml | 38 ++ .../windows-autopilot/known-issues.md | 89 ---- .../windows-autopilot/policy-conflicts.md | 45 -- .../deployment/windows-autopilot/profiles.md | 49 -- .../windows-autopilot/registration-auth.md | 94 ---- .../windows-autopilot/self-deploying.md | 74 --- .../windows-autopilot/troubleshooting.md | 164 ------- .../windows-autopilot/user-driven.md | 148 ------ .../windows-autopilot/white-glove.md | 120 ----- .../windows-autopilot-requirements.md | 145 ------ .../windows-autopilot-reset.md | 138 ------ .../windows-autopilot-scenarios.md | 76 ---- .../windows-autopilot-whats-new.md | 64 --- .../windows-autopilot/windows-autopilot.md | 62 --- 30 files changed, 164 insertions(+), 2801 deletions(-) delete mode 100644 windows/deployment/windows-autopilot/add-devices.md delete mode 100644 windows/deployment/windows-autopilot/autopilot-device-guidelines.md delete mode 100644 windows/deployment/windows-autopilot/autopilot-faq.md delete mode 100644 windows/deployment/windows-autopilot/autopilot-mbr.md delete mode 100644 windows/deployment/windows-autopilot/autopilot-support.md delete mode 100644 windows/deployment/windows-autopilot/autopilot-update.md delete mode 100644 windows/deployment/windows-autopilot/bitlocker.md delete mode 100644 windows/deployment/windows-autopilot/deployment-process.md delete mode 100644 windows/deployment/windows-autopilot/dfci-management.md delete mode 100644 windows/deployment/windows-autopilot/enrollment-status.md delete mode 100644 windows/deployment/windows-autopilot/existing-devices.md delete mode 100644 windows/deployment/windows-autopilot/index.md create mode 100644 windows/deployment/windows-autopilot/index.yml delete mode 100644 windows/deployment/windows-autopilot/known-issues.md delete mode 100644 windows/deployment/windows-autopilot/policy-conflicts.md delete mode 100644 windows/deployment/windows-autopilot/profiles.md delete mode 100644 windows/deployment/windows-autopilot/registration-auth.md delete mode 100644 windows/deployment/windows-autopilot/self-deploying.md delete mode 100644 windows/deployment/windows-autopilot/troubleshooting.md delete mode 100644 windows/deployment/windows-autopilot/user-driven.md delete mode 100644 windows/deployment/windows-autopilot/white-glove.md delete mode 100644 windows/deployment/windows-autopilot/windows-autopilot-requirements.md delete mode 100644 windows/deployment/windows-autopilot/windows-autopilot-reset.md delete mode 100644 windows/deployment/windows-autopilot/windows-autopilot-scenarios.md delete mode 100644 windows/deployment/windows-autopilot/windows-autopilot-whats-new.md delete mode 100644 windows/deployment/windows-autopilot/windows-autopilot.md diff --git a/.openpublishing.redirection.json b/.openpublishing.redirection.json index c806d9395d..0aba8575cb 100644 --- a/.openpublishing.redirection.json +++ b/.openpublishing.redirection.json @@ -16294,6 +16294,126 @@ "source_path": "windows/privacy/windows-personal-data-services-configuration.md", "redirect_url": "https://docs.microsoft.com/windows/privacy/windows-10-and-privacy-compliance", "redirect_document_id": false + }, + { + "source_path": "windows/deployment/windows-autopilot/add-devices.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/add-devices", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/autopilot-device-guidelines.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/autopilot-device-guidelines", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/autopilot-faq.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/autopilot-faq", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/autopilot-mbr.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/autopilot-mbr", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/utopilot-support.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/utopilot-support", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/autopilot-update.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/autopilot-update", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/bitlocker.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/bitlocker", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/deployment-process.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/deployment-process", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/dfci-management.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/dfci-management", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/enrollment-status.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/enrollment-status", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/existing-devices.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/existing-devices", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/known-issues.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/known-issues", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/policy-conflicts.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/policy-conflicts", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/profiles.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/profiles", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/registration-auth.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/registration-auth", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/self-deploying.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/self-deploying", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/troubleshooting.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/troubleshooting", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/user-driven.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/user-driven", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/white-glove.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/white-glove", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/windows-autopilot-requirements.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/windows-autopilot-requirements", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/windows-autopilot-reset.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/windows-autopilot-reset", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/windows-autopilot-scenarios.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/windows-autopilot-scenarios", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/windows-autopilot-whats-new.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/windows-autopilot-whats-new", + "redirect_document_id": true + }, + { + "source_path": "windows/deployment/windows-autopilot/windows-autopilot.md", + "redirect_url": "https://docs.microsoft.com/mem/autopilot/windows-autopilot", + "redirect_document_id": true } ] } \ No newline at end of file diff --git a/windows/deployment/TOC.yml b/windows/deployment/TOC.yml index bd4751ea90..edcc70baaa 100644 --- a/windows/deployment/TOC.yml +++ b/windows/deployment/TOC.yml @@ -74,8 +74,6 @@ href: update/waas-branchcache.md - name: Prepare your deployment tools items: - - name: Register devices for deployment with Windows Autopilot - href: windows-autopilot/add-devices.md - name: Prepare for deployment with MDT href: deploy-windows-mdt/prepare-for-windows-deployment-with-mdt.md - name: Prepare for deployment with Configuration Manager @@ -94,7 +92,7 @@ - name: Deploy Windows 10 items: - name: Deploy Windows 10 with Autopilot - href: windows-autopilot/windows-autopilot-scenarios.md + href: windows-autopilot/index.md - name: Deploy Windows 10 with Configuration Manager items: - name: Deploy to a new device diff --git a/windows/deployment/index.yml b/windows/deployment/index.yml index 4383221147..91a4c1fe76 100644 --- a/windows/deployment/index.yml +++ b/windows/deployment/index.yml @@ -13,7 +13,7 @@ metadata: ms.collection: windows-10 author: greg-lindsay #Required; your GitHub user alias, with correct capitalization. ms.author: greglin #Required; microsoft alias of author; optional team alias. - ms.date: 06/09/2020 #Required; mm/dd/yyyy format. + ms.date: 08/05/2020 #Required; mm/dd/yyyy format. localization_priority: medium # linkListType: architecture | concept | deploy | download | get-started | how-to-guide | learn | overview | quickstart | reference | tutorial | video | whats-new @@ -53,7 +53,7 @@ landingContent: - linkListType: deploy links: - text: Deploy Windows 10 with Autopilot - url: windows-autopilot/windows-autopilot-scenarios.md + url: https://docs.microsoft.com/mem/autopilot - text: Assign devices to servicing channels url: update/waas-servicing-channels-windows-10-updates.md - text: Deploy Windows updates with Configuration Manager @@ -71,7 +71,7 @@ landingContent: - text: Basics of Windows updates, channels, and tools url: update/get-started-updates-channels-tools.md - text: Overview of Windows Autopilot - url: windows-autopilot/windows-autopilot.md + url: https://docs.microsoft.com/mem/autopilot/windows-autopilot # Card - title: Support remote work diff --git a/windows/deployment/windows-autopilot/TOC.md b/windows/deployment/windows-autopilot/TOC.md index 9b7c22ee03..b2e8164e4c 100644 --- a/windows/deployment/windows-autopilot/TOC.md +++ b/windows/deployment/windows-autopilot/TOC.md @@ -1,33 +1,2 @@ -# [Windows Autopilot deployment](index.md) -# [What's new](windows-autopilot-whats-new.md) -# Understanding Windows Autopilot -## [Overview](windows-autopilot.md) -## [Requirements](windows-autopilot-requirements.md) -## [Scenarios and capabilities](windows-autopilot-scenarios.md) -## [Get started](demonstrate-deployment-on-vm.md) - -# Deployment scenarios -## [Deployment processes](deployment-process.md) -## [User-driven mode](user-driven.md) -## [Self-deploying mode](self-deploying.md) -## [Windows Autopilot Reset](windows-autopilot-reset.md) -## [White glove](white-glove.md) -## [Support for existing devices](existing-devices.md) - -# Administering Windows Autopilot -## [Registering devices](add-devices.md) -## [Configuring device profiles](profiles.md) -## [Enrollment Status Page](enrollment-status.md) -## [BitLocker encryption](bitlocker.md) -## [DFCI management](dfci-management.md) -## [Windows Autopilot update](autopilot-update.md) -## [Troubleshooting](troubleshooting.md) -## [Policy conflicts](policy-conflicts.md) -## [Known issues](known-issues.md) - -# Support -## [FAQ](autopilot-faq.md) -## [Contacts](autopilot-support.md) -## [Registration authorization](registration-auth.md) -## [Device guidelines](autopilot-device-guidelines.md) -## [Motherboard replacement](autopilot-mbr.md) +# [Windows Autopilot deployment](index.yml) +## [Get started](demonstrate-deployment-on-vm.md) \ No newline at end of file diff --git a/windows/deployment/windows-autopilot/add-devices.md b/windows/deployment/windows-autopilot/add-devices.md deleted file mode 100644 index 24429cf361..0000000000 --- a/windows/deployment/windows-autopilot/add-devices.md +++ /dev/null @@ -1,184 +0,0 @@ ---- -title: Adding devices -ms.reviewer: -manager: laurawi -description: How to add devices to Windows Autopilot -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Adding devices to Windows Autopilot - -**Applies to** - -- Windows 10 - -Before deploying a device using Windows Autopilot, the device must be registered with the Windows Autopilot deployment service. Ideally, this would be performed by the OEM, reseller, or distributor from which the devices were purchased, but this can also be done by the organization by collecting the hardware identity and uploading it manually. - -## OEM registration - -When you purchase devices directly from an OEM, that OEM can automatically register the devices with the Windows Autopilot deployment service. For the list of OEMs that currently support this, see the "Participant device manufacturers and resellers" section of the [Windows Autopilot information page](https://aka.ms/windowsautopilot). - -Before an OEM can register devices on behalf of an organization, the organization must grant the OEM permission to do so. This process is initiated by the OEM, with approval granted by an Azure AD global administrator from the organization. See the "Customer Consent" section of the [Customer consent page](https://docs.microsoft.com/windows/deployment/windows-autopilot/registration-auth#oem-authorization). - -> [!Note] -> While the hardware hashes are generated as part of the OEM device manufacturing process, these should not be provided directly to customers or CSP partners. Instead, the OEM should register devices on the customer's behalf. In cases where devices are being registered by CSP partners, OEMs may provide PKID information to those partners to support the device registration process. - -## Reseller, distributor, or partner registration - -Customers may purchase devices from resellers, distributors, or other partners. As long as these resellers, distributors, and partners are part of the [Cloud Solution Partners (CSP) program](https://partner.microsoft.com/cloud-solution-provider), they too can register devices on behalf of the customer. - -As with OEMs, CSP partners must be granted permission to register devices on behalf of an organization. This follows the process described on the [Customer consent page](https://docs.microsoft.com/windows/deployment/windows-autopilot/registration-auth#csp-authorization). The CSP partner initiates a request to establish a relationship with the organization, with approval granted by a global administrator from the organization. Once approved, CSP partners add devices using [Partner Center](https://partner.microsoft.com/pcv/dashboard/overview), either directly through the web site or via available APIs that can automate the same tasks. - -Windows Autopilot does not require delegated administrator permissions when establishing the relationship between the CSP partner and the organization. As part of the approval process performed by the global administrator, the global administrator can choose to uncheck the "Include delegated administration permissions" checkbox. - -> [!Note] -> While resellers, distributors, or partners could boot each new Windows device to obtain the hardware hash (for purposes of providing them to customers or direct registration by the partner), this is not recommended. Instead, these partners should register devices using the PKID information obtained from the device packaging (barcode) or obtained electronically from the OEM or upstream partner (e.g. distributor). - -## Automatic registration of existing devices - -If an existing device is already running a supported version of Windows 10 semi-annual channel and enrolled in an MDM service such an Intune, that MDM service can ask the device for the hardware ID (also known as a hardware hash). Once it has that, it can automatically register the device with Windows Autopilot. - -For instructions on how to do this with Microsoft Intune, see [Create an Autopilot deployment profile](https://docs.microsoft.com/intune/enrollment-autopilot#create-an-autopilot-deployment-profile) documentation describing the "Convert all targeted devices to Autopilot" setting. - -Also note that when using the [Windows Autopilot for existing devices](https://docs.microsoft.com/windows/deployment/windows-autopilot/existing-devices) scenario, it is not necessary to pre-register the devices with Windows Autopilot. Instead, a configuration file (AutopilotConfigurationFile.json) containing all the Windows Autopilot profile settings is used; the device can be registered with Windows Autopilot after the fact using the same "Convert all targeted devices to Autopilot" setting. - -## Manual registration - -To perform manual registration of a device, you must first capture its hardware ID (also known as a hardware hash). Once this process has completed, the resulting hardware ID can be uploaded to the Windows Autopilot service. Because this process requires booting the device into Windows 10 in order to obtain the hardware ID, this is intended primarily for testing and evaluation scenarios. - -> [!Note] -> Customers can only register devices with a hardware hash. Other methods (PKID, tuple) are available through OEMs or CSP partners as described in the previous sections. - -## Device identification - -To define a device to the Windows Autopilot deployment service, a unique hardware ID for the device needs to be captured and uploaded to the service. While this step is ideally done by the hardware vendor (OEM, reseller, or distributor), automatically associating the device with an organization, it is also possible to do this through a harvesting process that collects the device from within a running Windows 10 installation. - -The hardware ID, also commonly referred to as a hardware hash, contains several details about the device, including its manufacturer, model, device serial number, hard drive serial number, and many other attributes that can be used to uniquely identify that device. - -Note that the hardware hash also contains details about when it was generated, so it will change each time it is generated. When the Windows Autopilot deployment service attempts to match a device, it considers changes like that, as well as more substantial changes such as a new hard drive, and is still able to match successfully. But substantial changes to the hardware, such as a motherboard replacement, would not match, so a new hash would need to be generated and uploaded. - -### Collecting the hardware ID from existing devices using Microsoft Endpoint Configuration Manager - -Microsoft Endpoint Configuration Manager automatically collects the hardware hashes for existing Windows 10 devices. For more information, see [Gather information from Configuration Manager for Windows Autopilot](https://docs.microsoft.com/configmgr/comanage/how-to-prepare-win10#windows-autopilot). You can extract the hash information from Configuration Manager into a CSV file. - -> [!Note] -> Before uploading the CSV file on Intune, please make sure that the first row contains the device serial number, Windows product ID, hardware hash, group tag, and assigned user. If there is header information on the top of CSV file, please delete that header information. See details at [Enroll Windows devices in Intune](https://docs.microsoft.com/intune/enrollment/enrollment-autopilot). - -### Collecting the hardware ID from existing devices using PowerShell - -The hardware ID, or hardware hash, for an existing device is available through Windows Management Instrumentation (WMI), as long as that device is running a supported version of Windows 10 semi-annual channel. To help gather this information, as well as the serial number of the device (useful to see at a glance the machine to which it belongs), a PowerShell script called [Get-WindowsAutoPilotInfo.ps1 has been published to the PowerShell Gallery website](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo). - -To use this script, you can download it from the PowerShell Gallery and run it on each computer, or you can install it directly from the PowerShell Gallery. To install it directly and capture the hardware hash from the local computer, use the following commands from an elevated Windows PowerShell prompt: - -```powershell -md c:\\HWID -Set-Location c:\\HWID -Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted -Install-Script -Name Get-WindowsAutoPilotInfo -Get-WindowsAutoPilotInfo.ps1 -OutputFile AutoPilotHWID.csv -``` - -The commands can also be run remotely, as long as WMI permissions are in place and WMI is accessible through the Windows Firewall on that remote computer. See the [Get-WindowsAutoPilotInfo](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo) script’s help (using “Get-Help Get-WindowsAutoPilotInfo.ps1”) for more information about running the script. - ->[!IMPORTANT] ->Do not connect devices to the Internet prior to capturing the hardware ID and creating an Autopilot device profile. This includes collecting the hardware ID, uploading the .CSV into MSfB or Intune, assigning the profile, and confirming the profile assignment. Connecting the device to the Internet before this process is complete will result in the device downloading a blank profile that is stored on the device until it is explicity removed. In Windows 10 version 1809, you can clear the cached profile by restarting OOBE. In previous versions, the only way to clear the stored profile is to re-install the OS, reimage the PC, or run **sysprep /generalize /oobe**.
->After Intune reports the profile ready to go, only then should the device be connected to the Internet. - ->[!NOTE] ->If OOBE is restarted too many times it can enter a recovery mode and fail to run the Autopilot configuration. You can identify this scenario if OOBE displays multiple configuration options on the same page, including language, region, and keyboard layout. The normal OOBE displays each of these on a separate page. The following value key tracks the count of OOBE retries:
->**HKCU\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\UserOOBE**
->To ensure OOBE has not been restarted too many times, you can change this value to 1. - -## Registering devices - - - - -Once the hardware IDs have been captured from existing devices, they can be uploaded through a variety of means. See the detailed documentation for each available mechanism. - -- [Microsoft Intune](https://docs.microsoft.com/intune/enrollment-autopilot). This is the preferred mechanism for all customers. -- [Partner Center](https://msdn.microsoft.com/partner-center/autopilot). This is used by CSP partners to register devices on behalf of customers. -- [Microsoft 365 Business & Office 365 Admin](https://support.office.com/article/Create-and-edit-AutoPilot-profiles-5cf7139e-cfa1-4765-8aad-001af1c74faa). This is typically used by small and medium businesses (SMBs) who manage their devices using Microsoft 365 Business. -- [Microsoft Store for Business](https://docs.microsoft.com/microsoft-store/add-profile-to-devices#manage-autopilot-deployment-profiles). You might already be using MSfB to manage your apps and settings. - -A summary of each platform's capabilities is provided below.
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Platform/PortalRegister devices?Create/Assign profileAcceptable DeviceID
OEM Direct APIYES - 1000 at a time maxNOTuple or PKID
Partner CenterYES - 1000 at a time maxYES34Tuple or PKID or 4K HH
IntuneYES - 500 at a time max1YES124K HH
Microsoft Store for BusinessYES - 1000 at a time maxYES44K HH
Microsoft 365 BusinessYES - 1000 at a time maxYES34K HH
- ->1Microsoft recommended platform to use
->2Intune license required
->3Feature capabilities are limited
->4Device profile assignment will be retired from MSfB and Partner Center in the coming months
- - -Also see the following topics for more information about device IDs: -- [Device identification](#device-identification) -- [Windows Autopilot device guidelines](https://docs.microsoft.com/windows/deployment/windows-autopilot/autopilot-device-guidelines) -- [Add devices to a customer account](https://docs.microsoft.com/partner-center/autopilot) - - -## Summary - -When deploying new devices using Windows Autopilot, the following steps are required: - -1. [Register devices](#registering-devices). Ideally, this step is performed by the OEM, reseller, or distributor from which the devices were purchased, but this can also be done by the organization by collecting the hardware identity and uploading it manually. -2. [Configure device profiles](profiles.md), specifying how the device should be deployed and what user experience should be presented. -3. Boot the device. When the device is connected to a network with internet access, it will contact the Windows Autopilot deployment service to see if the device is registered, and if it is, it will download profile settings such as the [Enrollment Status page](enrollment-status.md), which are used to customize the end user experience. - -## Other configuration settings - -- [Bitlocker encryption settings](bitlocker.md): You can configure the BitLocker encryption settings to be applied before automatic encryption is started. diff --git a/windows/deployment/windows-autopilot/autopilot-device-guidelines.md b/windows/deployment/windows-autopilot/autopilot-device-guidelines.md deleted file mode 100644 index 7784e955ea..0000000000 --- a/windows/deployment/windows-autopilot/autopilot-device-guidelines.md +++ /dev/null @@ -1,47 +0,0 @@ ---- -title: Windows Autopilot device guidelines -ms.reviewer: -manager: laurawi -description: Learn all about hardware, firmware, and software best practices for Windows Autopilot deployment. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Windows Autopilot device guidelines - -**Applies to** - -- Windows 10 - -## Hardware and firmware best practice guidelines for Windows Autopilot - -All devices used with Windows Autopilot should meet the [minimum hardware requirements](https://docs.microsoft.com/windows-hardware/design/minimum/minimum-hardware-requirements-overview) for Windows 10. - -The following additional best practices ensure that devices can easily be provisioned by organizations as part of the Windows Autopilot deployment process: -- Ensure that the TPM 2.0 is enabled and in a good state (not in Reduced Functionality Mode) by default on devices intended for Windows Autopilot self-deploying mode. -- The OEM provisions unique tuple info (SmbiosSystemManufacturer, SmbiosSystemProductName, SmbiosSystemSerialNumber) or PKID + SmbiosSystemSerialNumber into the [SMBIOS fields](https://docs.microsoft.com/windows-hardware/drivers/bringup/smbios) per Microsoft specification (Manufacturer, Product Name and Serial Number stored in SMBIOS Type 1 04h, Type 1 05h and Type 1 07h). -- The OEM uploads 4K Hardware Hashes obtained using OA3 Tool RS3+ run in Audit mode on full OS to Microsoft via CBR report prior to shipping devices to an Autopilot customer or channel partner. -- As a best practice, Microsoft requires that OEM shipping drivers are published to Windows Update within 30 days of the CBR being submitted, and system firmware and driver updates are published to Windows Update within 14 days -- The OEM ensures that the PKID provisioned in the SMBIOS is passed on to the channel. - -## Software best practice guidelines for Windows Autopilot - -- The Windows Autopilot device should be preinstalled with only a Windows 10 base image plus drivers. -- You can preinstall your licensed version of Office, such as [Microsoft 365 Apps for enterprise](https://docs.microsoft.com/deployoffice/about-office-365-proplus-in-the-enterprise). -- Unless explicitly requested by the customer, no other preinstalled software should be included. - - Per OEM Policy, Windows 10 features, including built-in apps, should not be disabled or removed. - -## Related topics - -[Windows Autopilot customer consent](registration-auth.md)
-[Motherboard replacement scenario guidance](autopilot-mbr.md)
diff --git a/windows/deployment/windows-autopilot/autopilot-faq.md b/windows/deployment/windows-autopilot/autopilot-faq.md deleted file mode 100644 index 1cbfeeb11b..0000000000 --- a/windows/deployment/windows-autopilot/autopilot-faq.md +++ /dev/null @@ -1,165 +0,0 @@ ---- -title: Windows Autopilot FAQ -ms.reviewer: This topic provides OEMs, partners, administrators, and end users with answers to some frequently asked questions about deploying Windows 10 with Windows Autopilot. -manager: laurawi -description: Support information for Windows Autopilot -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: low -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Windows Autopilot FAQ - -**Applies to: Windows 10** - -This article provides OEMs, partners, administrators, and end users with answers to some frequently asked questions about deploying Windows 10 with Windows Autopilot. - -A [glossary](#glossary) of abbreviations used in this article is provided at the end. - - -## Microsoft Partner Center - -| Question | Answer | -| --- | --- | -| In the Partner Center, does the Tenant ID need to be provided with every device file upload? Is it needed to allow the business customer to access their devices in Microsoft Store for Business (MSfB)? | No. Providing the Tenant ID is a one-time entry in the Partner Center that can be reused with future device uploads. | -| How does the customer or tenant know that their devices are ready to be claimed in MSfB? | After the device file upload is completed in the Partner Center, the tenant can see the devices available for Windows Autopilot setup in MSfB. The OEM needs to advise the tenant to access MSfB. Autonotification from MSfB to the tenant is being developed. | -| How does a customer authorize an OEM or Channel Partner to register Autopilot devices on the customer’s behalf? | Before an OEM or Channel Partner can register a device for Autopilot on behalf of a customer, the customer must first give them consent. The consent process begins with the OEM or Channel Partner sending a link to the customer that directs the customer to a consent page in MSfB. For more information, see [Registration](registration-auth.md). | -| Are there any restrictions if a business customer has registered devices in MSfB and later wants those devices to be managed by a Cloud Solution Provider (CSP) using the Partner Center? | The devices will need to be deleted in MSfB by the business customer before the CSP can upload and manage them in the Partner Center. | -| Does Windows Autopilot support removing the option to enable a local administrator account? | Windows Autopilot doesn’t support removing the local admin account. However, it does support restricting the user performing Azure Active Directory (Azure AD) domain join in OOBE to a standard account (versus an administrator account by default).| -| How can I test the Windows Autopilot CSV file in the Partner Center? | Only CSP Partners have access to the Partner Center portal. If you are a CSP, you can create a Sales agent user account that has access to devices for testing the file. This can be done today in the Partner Center.

For more information, see [Create user accounts and set permissions](https://msdn.microsoft.com/partner-center/create-user-accounts-and-set-permissions). | -| Must I become a CSP to participate in Windows Autopilot? | Top volume OEMs do not, as they can use the OEM Direct API. All others who choose to use MPC to register devices must become CSPs in order to access MPC. | -| Do the different CSP levels have all the same capabilities when it comes to Windows Autopilot? | For purposes of Windows Autopilot, there are three different types of CSPs, each with different levels of authority and access:

1. Direct CSP: Gets direct authorization from the customer to register devices.

2. Indirect CSP Provider: Gets implicit permission to register devices through the relationship their CSP Reseller partner has with the customer. Indirect CSP Providers register devices through Microsoft Partner Center.

3. Indirect CSP Reseller: Gets direct authorization from the customer to register devices. At the same time, their indirect CSP Provider partner also gets authorization, which means that either the Indirect Provider or the Indirect Reseller can register devices for the customer. However, the Indirect CSP Reseller must register devices through the MPC UI (manually uploading CSV file), whereas the Indirect CSP Provider has the option to register devices using the MPC APIs. | - - -## Manufacturing - -| Question | Answer | -| --- | --- | -| What changes need to be made in the factory OS image for customer configuration settings? |No changes are required on the factory floor to enable Windows Autopilot deployment. | -| What version of the OA3 tool meets Windows Autopilot deployment requirements? | Windows Autopilot can work with any version of the OA3 tool. We recommend using a supported version of Windows 10 semi-annual channel to generate the 4K hardware hash. | -| At the time of placing an order, do customers need to be state whether they want it with or without Windows Autopilot options? | Yes, if they want Windows Autopilot, they will want a supported version of Windows 10 semi-annual channel. Also, they will want to receive the CSV file or have the file upload (that is, registration) completed on their behalf. | -| Does the OEM need to manage or collect any custom imaging files from customers and perform any image uploads to Microsoft? | No change, OEMs just send the CBRs as usual to Microsoft. No images are sent to Microsoft to enable Windows Autopilot. Windows Autopilot only customizes OOBE and allows policy configurations (disables admin account, for example). | -| Are there any customer impacts to upgrading from Windows 8 to Windows 10? | The devices must be running a supported version of Windows 10 semi-annual channel to enroll in Windows Autopilot deployment. Otherwise, there are no impacts. | -| Will there be any change to the existing CBR with 4K hardware hash? | No. | -| What new information needs to be sent from the OEM to Microsoft? | Nothing, unless the OEM opts to register the device on the customer’s behalf, in which case they would upload the device ID using a CSV file into Microsoft Partner Center, or use the OEM Direct API. | -| Is there a contract or amendment for an OEM to participate in Windows Autopilot Deployment? | No. | - -## CSV schema - -| Question | Answer | -| --- | --- | -| Can a comma be used in the CSV file? | No. | -| What error messages can a user expect to see in the Partner Center or MSfB when uploading a file? | See the In Microsoft Store for Business section of this guide. | -| Is there a limit to the number of devices that can be listed in the CSV file? | Yes, the CSV file can only contain 1,000 devices to apply to a single profile. If more than 1,000 devices need to be applied to a profile, the devices need to be uploaded through multiple CSV files. | -| Does Microsoft have any recommendations on how an OEM should provide the CSV file to their customers? | We recommend encrypting the CSV file when sending to the business customer to self-register their Windows Autopilot devices (either through MPC, MSfB, or Intune). | - - -## Hardware hash - -| Question | Answer | -| --- | --- | -| Must every hardware hash submitted by the OEM contain the SMBIOS UUID (universally unique identifier), MAC (media access control) address, and unique disk serial number (if using Windows 10 OEM Activation 3.0 tool)? | Yes. Since Windows Autopilot is based on the ability to uniquely identify devices applying for cloud configuration, it is critical to submit hardware hashes that meet the outlined requirement. | -| What is the reason for needing the SMBIOS UUID, MAC Address, and Disk Serial Number in the hardware hash details? | For creating the hardware hash, these are the fields that are needed to identify a device, as parts of the device are added or removed. Since we don’t have a unique identifier for Windows devices, this is the best logic to identify a device. | -| What is difference between OA3 hardware hash, 4K hardware hash, and Windows Autopilot hardware hash? | None. They’re different names for the same thing. The OA3 tool output is called the OA3 Hash, which is 4K in size, which is usable for the Windows Autopilot deployment scenario. Note: When using an older, unsupported Windows version OA3Tool, you get a different sized Hash, which may not be used for Windows Autopilot deployment. | -| What is the thought around parts replacement and repair for the NIC (network interface controller) and Disk? Will the hardware hash become invalid? | Yes. If you replace parts, you need to gather the new hardware hash, though it depends on what is replaced, and the characteristics of the parts. For example, if you replace the TPM or motherboard, it’s a new device and you must have new hardware hash. If you replace one network card, it’s probably not a new device, and the device will function with the old hardware hash. However, as a best practice, you should assume the old hardware hash is invalid and get a new hardware hash after any hardware changes. This is recommended anytime you replace parts. | - -## Motherboard replacement - -| Question | Answer | -| --- | --- | -| How does Autopilot handle motherboard replacement scenarios? | Motherboard replacement is out for scope for Autopilot. Any device that is repaired or serviced in a way that alters the ability to identify the device for Windows Autopilot must go through the normal OOBE process, and manually select the right settings or apply a custom image, as is the case today.

To reuse the same device for Windows Autopilot after a motherboard replacement, the device would need to be de-registered from Autopilot, the motherboard replaced, a new 4K HH harvested, and then re-registered using the new 4K hardware hash (or device ID).

**Note**: An OEM will not be able to use the OEM Direct API to re-register the device, since the OEM Direct API only accepts a tuple or PKID. In this case, the OEM would either have to send the new 4K hardware hash information using a CSV file to customer, and let customer reregister the device using MSfB or Intune.| - -## SMBIOS - -| Question | Answer | -| --- | --- | -| Any specific requirement to SMBIOS UUID? | It must be unique as specified in the Windows 10 hardware requirements. | -| What is the requirement on the SMBIOS table to meet the Windows Autopilot hardware hash need? | It must meet all the Windows 10 hardware requirements. Additional details may be found [here](https://msdn.microsoft.com/library/jj128256(v=vs.85).aspx). | -| If the SMBIOS supports UUID and Serial Number, is it enough for the OA3 tool to generate the hardware hash? | No. At a minimum, the following SMBIOS fields need to be populated with unique values: ProductKeyID SmbiosSystemManufacturer SmbiosSystemProductName SmbiosSystemSerialNumber SmbiosSkuNumber SmbiosSystemFamily MacAddress SmbiosUuid DiskSerialNumber TPM EkPub | - -## Technical interface - -| Question | Answer | -| --- | --- | -| What is the interface to get the MAC Address and Disk Serial Number? How does the OA tool get MAC and Disk Serial #? | Disk serial number is found from IOCTL_STORAGE_QUERY_PROPERTY with StorageDeviceProperty/PropertyStandardQuery. Network MAC address is IOCTL_NDIS_QUERY_GLOBAL_STATS from OID_802_3_PERMANENT_ADDRESS. However the method for performing this operation varies depending on the scenario. | -| Follow up clarification: If we have 2-3 MACs on the system, how does OA Tool choose which MAC Address and Disk Serial Number are on the system since there are multiple instances of each? If a platform has LAN And WLAN, which MAC is chosen? | In short, all available values are used. In detail, there may be specific usage rules. The system disk serial number is more important than the other disks available. Network interfaces that are removable should not be used if detected as they are removable. LAN vs WLAN should not matter, as both will be used. | - -## The end-user experience - -|Question|Answer| -|----|-----| -|How do I know that I received Autopilot?|You can tell that you received Windows Autopilot (as in the device received a configuration but has not yet applied it) when you skip the selection page (as seen below), and are immediately taken to a generic or customized sign-in page.| -|Windows Autopilot didn’t work, what do I do now?| Questions and actions to assist in troubleshooting: Did a screen not get skipped? Did a user end up as an admin when configured not to? Remember that Azure AD Admins will be local admins regardless of whether Windows Autopilot is configured to disable local admin Collection information: run licensingdiag.exe and send the .cab (Cabinet) file that is generated to AutopilotHelp@microsoft.com. If possible, collect an ETL from Windows Performance Recorder (WPR). Often in these cases, users are not signing into the right Azure AD tenant, or are creating local user accounts. For a complete list of support options, refer to [Windows Autopilot support](autopilot-support.md). | -| If an Administrator makes changes to an existing profile, will the changes take effect on devices that have that profile assigned to them that have already been deployed? |No. Windows Autopilot profiles are not resident on the device. They are downloaded during OOBE, the settings defined at the time are applied. Then, the profile is discarded on the device. If the device is reimaged or reset, the new profile settings will take effect the next time the device goes through OOBE.| -|What is the experience if a device isn’t registered or if an IT Admin doesn’t configure Windows Autopilot prior to an end user attempting to self-deploy? |If the device isn’t registered, it will not receive the Windows Autopilot experience and the end user will go through normal OOBE. The Windows Autopilot configurations will not be applied until the user runs through OOBE again, after registration. If a device is started before an MDM profile is created, the device will go through standard OOBE experience. The IT Admin would then have to manually enroll that device into the MDM, after which the next time that device is reset, it will go through the Windows Autopilot OOBE experience.| -|Why didn't I receive a customized sign-in screen during Autopilot? |Tenant branding must be configured in portal.azure.com to receive a customized sign-in experience.| -|What happens if a device is registered with Azure AD but does not have a Windows Autopilot profile assigned? |The regular Azure AD OOBE will occur since no Windows Autopilot profile was assigned to the device.| -|How can I collect logs on Autopilot?|The best way to collect logs on Windows Autopilot performance is to collect a WPR trace during OOBE. The XML file (WPRP extension) for this trace may be provided upon request.| - -## MDM - -| Question | Answer | -| --- | --- | -| Must we use Intune for our MDM? | No, any MDM will work with Autopilot, but others probably won’t have the same full suite of Windows Autopilot features as Intune. You’ll get the best experience from Intune. | -| Can Intune support Win32 app preinstalls? | Yes. Starting with the Windows 10 October Update (version 1809), Intune supports Win32 apps using .msi (and .msix) wrappers. | -| What is co-management? | Co-management is when you use a combination of a cloud MDM tool (Intune) and an on-premises configuration tool like Microsoft Endpoint Configuration Manager. You only need to use the Configuration Manager if Intune can’t support what you want to do with your profile. If you choose to co-manage using Intune + Configuration Manager, you do it by including a Configuration Manager agent in your Intune profile. When that profile is pushed to the device, the device will see the Configuration Manager agent and go out to the Configuration Manager to pull down any additional profile settings. | -| Must we use Microsoft Endpoint Configuration Manager for Windows Autopilot | No. Co-management (described above) is optional. | - - -## Features - -| Question | Answer | -| --- | --- | -| Self-deploying mode | A new version of Windows Autopilot where the user only turns on the device, and nothing else. It’s useful for scenarios where a standard user account isn’t needed (for example, shared devices, or KIOSK devices). | -| Hybrid Azure Active Directory join | Allows Windows Autopilot devices to connect to an on-premises Active Directory domain controller (in addition to being Azure AD joined). | -| Windows Autopilot reset | Removes user apps and settings from a device, but maintains Azure AD domain join and MDM enrollment. Useful for when transferring a device from one user to another. | -| Personalization | Adds the following to the OOBE experience: A personalized welcome message can be created. A username hint can be added Sign-in page text can be personalized. The company’s logo can be included | -| [Autopilot for existing devices](existing-devices.md) | Offers an upgrade path to Windows Autopilot for all existing Windows 7- and Windows 8-based devices. | - - - -## General - -|Question|Answer -|------------------|-----------------| -|If I wipe the machine and restart, will I still receive Windows Autopilot?|Yes, if the device is still registered for Windows Autopilot and is running a supported version of Windows 10 semi-annual channel, it will receive the Windows Autopilot experience.| -|Can I harvest the device fingerprint on existing machines?|Yes, if the device is running a supported version of Windows 10 semi-annual channel, you can harvest device fingerprints for registration. There are no plans to backport the functionality to legacy releases and no way to harvest them on devices running unsupported versions of Windows.| -|Is Windows Autopilot supported on other SKUs, for example, Surface Hub, HoloLens, Windows Mobile.|No, Windows Autopilot isn’t supported on other SKUs.| -|Does Windows Autopilot work after MBR or image reinstallation?|Yes.| -| Can machines that have reimaged a few times go through Autopilot? What does the error message "This user is not authorized to enroll" mean? Error code 801c0003. |There are limits to the number of devices a particular Azure AD user can enroll in Azure AD, as well as the number of devices that are supported per user in Intune. (These are configurable but not infinite.) You’ll run into this frequently if you reuse the devices, or even if you roll back to previous virtual machine snapshots.| -|What happens if a device is registered to a malicious agent? |By design, Windows Autopilot does not apply a profile until the user signs in with the matching tenant for the configured profile using the Azure AD sign-in process. What occurs is illustrated below. If badguys.com registers a device owned by contoso.com, at worst, the user would be directed to sign into badguys.com. When the user enters their email/password, the sign-in information is redirected through Azure AD to the proper Azure AD authentication and the user is prompted to then sign into contoso.com. Since contoso.com does not match badguys.com as the tenant, the Windows Autopilot profile will not be applied and the regular Azure AD OOBE will occur.| -|Where is the Windows Autopilot data stored? |Windows Autopilot data is stored in the United States (US), not in a sovereign cloud, even when the Azure AD tenant is registered in a sovereign cloud. This is applicable to all Windows Autopilot data, regardless of the portal leveraged to deploy Autopilot.| -|Why is Windows Autopilot data stored in the US and not in a sovereign cloud?|It is not customer data that we store, but business data that enables Microsoft to provide a service, therefore it is okay for the data to reside in the US. Customers can stop subscribing to the service at any time, and, in that event, the business data is removed by Microsoft.| -|How many ways are there to register a device for Windows Autopilot|There are six ways to register a device, depending on who is doing the registering:

1. OEM Direct API (only available to TVOs)
2. MPC using the MPC API (must be a CSP)
3. MPC using manual upload of CSV file in the UI (must be a CSP)
4. MSfB using CSV file upload
5. Intune using CSV file upload
6. Microsoft 365 Business portal using CSV file upload| -|How many ways are there to create a Windows Autopilot profile?|There are four ways to create and assign a Windows Autopilot profile:

1. Through MPC (must be a CSP)
2. Through MSfB
3. Through Intune (or another MDM)
4. Microsoft 365 Business portal

Microsoft recommends creation and assignment of profiles through Intune. | -| What are some common causes of registration failures? |1. Bad or missing hardware hash entries can lead to faulty registration attempts
2. Hidden special characters in CSV files.

To avoid this issue, after creating your CSV file, open it in Notepad to look for hidden characters or trailing spaces or other corruptions.| -| Is Autopilot supported on IoT devices? | Autopilot is not supported on IoT Core devices, and there are currently no plans to add this support. Autopilot is supported on Windows 10 IoT Enterprise SAC devices. Autopilot is supported on Windows 10 Enterprise LTSC 2019 and above; it is not supported on earlier versions of LTSC.| -| Is Autopilot supported in all regions/countries? | Autopilot only supports customers using global Azure. Global Azure does not include the three entities listed below:
- Azure Germany
- Azure China 21Vianet
- Azure Government
So, if a customer is set up in global Azure, there are no region restrictions. For example, if Contoso uses global Azure but has employees working in China, the Contoso employees working in China would be able to use Autopilot to deploy devices. If Contoso uses Azure China 21Vianet, the Contoso employees would not be able to use Autopilot.| -| I need to register a device that's been previously registered to another organisation. | Partners registering devices through partner center can also deregister the device if it's moving between different customer tenants. If this isn't possible, as a last resort you can raise a ticket through the Intune "Help and Support" node and our support teams will assist you. | - -## Glossary - -| Term | Meaning | -| --- | --- | -| CSV | Comma Separated Values (File type similar to Excel spreadsheet) | -| MPC | Microsoft Partner Center | -| MDM | Mobile Device Management | -| OEM | Original Equipment Manufacturer | -| CSP | Cloud Solution Provider | -| MSfB | Microsoft Store for Business | -| Azure AD | Azure Active Directory | -| 4K HH | 4K hardware hash | -| CBR | Computer Build Report | -| EC | Enterprise Commerce | -| DDS | Device Directory Service | -| OOBE | Out of the Box Experience | -| UUID | Universally Unique Identifier | diff --git a/windows/deployment/windows-autopilot/autopilot-mbr.md b/windows/deployment/windows-autopilot/autopilot-mbr.md deleted file mode 100644 index 28c376ab92..0000000000 --- a/windows/deployment/windows-autopilot/autopilot-mbr.md +++ /dev/null @@ -1,421 +0,0 @@ ---- -title: Windows Autopilot motherboard replacement -ms.reviewer: -manager: laurawi -description: Windows Autopilot deployment MBR scenarios -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Windows Autopilot motherboard replacement scenario guidance - -**Applies to** - -- Windows 10 - -This document offers guidance for Windows Autopilot device repair scenarios that Microsoft partners can use in Motherboard Replacement (MBR) situations, and other servicing scenarios. - -Repairing Autopilot enrolled devices is complex, as it tries to balance OEM requirements with Windows Autopilot requirements. Specifically, OEM’s require strict uniqueness across motherboards, MAC addresses, etc., while Windows Autopilot requires strict uniqueness at the Hardware ID level for each device to enable successful registration. The Hardware ID does not always accommodate all the OEM hardware component requirements, thus these requirements are sometimes at odds, causing issues with some repair scenarios. - -**Motherboard Replacement (MBR)** - -If a motherboard replacement is needed on a Windows Autopilot device, the following process is recommended: - -1. [Deregister the device](#deregister-the-autopilot-device-from-the-autopilot-program) from Windows Autopilot -2. [Replace the motherboard](#replace-the-motherboard) -3. [Capture a new device ID (4K HH)](#capture-a-new-autopilot-device-id-4k-hh-from-the-device) -4. [Reregister the device](#reregister-the-repaired-device-using-the-new-device-id) with Windows Autopilot -5. [Reset the device](#reset-the-device) -6. [Return the device](#return-the-repaired-device-to-the-customer) - -Each of these steps is described below. - -## Deregister the Autopilot device from the Autopilot program - -Before the device arrives at the repair facility, it must be deregistered by the entity that registered it. Only the entity that registered the device can deregister it. This might be the customer IT Admin, the OEM, or the CSP partner. If the IT Admin registered the device, they likely did so via Intune (or possibly the Microsoft Store for Business). In that case, they should deregister the device from Intune (or MSfB). This is necessary because devices registered in Intune will not show up in MPC. However, if the OEM or CSP partner registered the device, they likely did so via the Microsoft Partner Center (MPC). In that case, they should deregister the device from MPC, which will also remove it from the customer IT Admin’s Intune account. Below, we describe the steps an IT Admin would go through to deregister a device from Intune, and the steps an OEM or CSP would go through to deregister a device from MPC. - -**NOTE**: When possible, an OEM or CSP should register Autopilot devices, rather than having the customer do it. This will avoid problems where OEMs or CSPs may not be able to deregister a device if, for example, a customer leasing a device goes out of business before deregistering it themselves. - -**EXCEPTION**: If a customer grants an OEM permission to register devices on their behalf via the automated consent process, then an OEM can use the API to deregister devices they didn’t register themselves (instead, the customer registered the devices). But keep in mind that this would only remove those devices from the Autopilot program, it would not disenroll them from Intune or disjoin them from AAD. The customer must do those steps, if desired, through Intune. - -### Deregister from Intune - -To deregister an Autopilot device from Intune, an IT Admin would: - -1. Sign in to their Intune account -2. Navigate to Intune > Groups > All groups -3. Remove the desired device from its group -4. Navigate to Intune > Devices > All devices -5. Select the checkbox next to the device you want to delete, then click the Delete button on the top menu -6. Navigate to Intune > Devices > Azure AD devices -7. Select the checkbox next to the device you want to delete, then click the Delete button along the top menu -8. Navigate to Intune > Device enrollment > Windows enrollment > Devices -9. Select the checkbox next to the device you want to deregister -10. Click the extended menu icon (“…”) on the far right end of the line containing the device you want to deregister in order to expose an additional menu with the option to “unassign user” -11. Click “Unassign user” if the device was previously assigned to a user; if not, this option will be grayed-out and can be ignored -12. With the unassigned device still selected, click the Delete button along the top menu to remove this device - -**NOTE**: These steps deregister the device from Autopilot, but also unenroll the device from Intune, and disjoin the device from AAD. While it may appear that only deregistering the device from Autopilot is needed, there are certain barriers in place within Intune that necessitate all the steps above be done, which is best practice anyway in case the device gets lost or becomes unrecoverable, to eliminate the possibility of orphaned devices existing in the Autopilot database, or Intune, or AAD. If a device gets into an unrecoverable state, you can contact the appropriate [Microsoft support alias](autopilot-support.md) for assistance. - -The deregistration process will take about 15 minutes. You can accelerate the process by clicking the “Sync” button, then “Refresh” the display until the device is no longer present. - -More details on deregistering devices from Intune can be found [here](https://docs.microsoft.com/intune/enrollment-autopilot#create-an-autopilot-device-group). - -### Deregister from MPC - -To deregister an Autopilot device from the Microsoft Partner Center (MPC), a CSP would: - -1. Log into MPC -2. Navigate to Customer > Devices -3. Select the device to be deregistered and click the “Delete device” button - -![devices](images/devices.png) - -**NOTE**: Deregistering a device from Autopilot in MPC does only that; it does not also unenroll the device from the MDM (Intune), nor does it disjoin the device from AAD. Therefore, if possible, the OEM/CSP ideally should work with the customer IT Admin to have the device fully removed per the Intune steps in the previous section. - -Alternatively, an OEM partner that has integrated the OEM Direct APIs can deregister a device by calling the AutopilotDeviceRegistration API with the TenantID and TenantDomain fields left blank in the request call. - -Because the repair facility will not have access to the user’s login credentials, the repair facility will have to reimage the device as part of the repair process. This means that the customer should do three things before sending the device off for repair: -1. Copy all important data off the device. -2. Let the repair facility know which version of Windows they should reinstall after the repair. -3. If applicable, let the repair facility know which version of Office they should reinstall after the repair. - -## Replace the motherboard - -Technicians replace the motherboard (or other hardware) on the broken device. A replacement DPK is injected. - -Repair and key replacement processes vary between facilities. Sometimes repair facilities receive motherboard spare parts from OEMs that have replacement DPKs already injected, but sometimes not. Sometimes repair facilities receive fully-functional BIOS tools from OEMs, but sometimes not. This means that the quality of the data in the BIOS after an MBR varies. To ensure the repaired device will still be Autopilot-capable following its repair, the new (post-repair) BIOS should be able to successfully gather and populate the following information at a minimum: - -- DiskSerialNumber -- SmbiosSystemSerialNumber -- SmbiosSystemManufacturer -- SmbiosSystemProductName -- SmbiosUuid -- TPM EKPub -- MacAddress -- ProductKeyID -- OSType - -**NOTE**: For simplicity, and because processes vary between repair facilities, we have excluded many of the additional steps often used in an MBR, such as: -- Verify that the device is still functional -- Disable BitLocker* -- Repair the Boot Configuration Data (BCD) -- Repair and verify the network driver operation - -*BitLocker can be suspended rather than disabled if the technician has the ability to resume it after the repair. - -## Capture a new Autopilot device ID (4K HH) from the device - -Repair technicians must sign in to the repaired device to capture the new device ID. Assuming the repair technician does NOT have access to the customer’s login credentials, they will have to reimage the device in order to gain access, per the following steps: - -1. The repair technician creates a [WinPE bootable USB drive](https://docs.microsoft.com/windows-hardware/manufacture/desktop/oem-deployment-of-windows-10-for-desktop-editions#create-a-bootable-windows-pe-winpe-partition). -2. The repair technician boots the device to WinPE. -3. The repair technician [applies a new Windows image to the device](https://docs.microsoft.com/windows-hardware/manufacture/desktop/work-with-windows-images). - - **NOTE**: Ideally, the same version of Windows should be reimaged onto the device that was originally on the device, so some coordination will be required between the repair facility and customer to capture this information at the time the device arrives for repair. This might include the customer sending the repair facility a customized image (.ppk file) via a USB stick, for example. - -4. The repair technician boots the device into the new Windows image. -5. Once on the desktop, the repair technician captures the new device ID (4K HH) off the device using either the OA3 Tool or the PowerShell script, as described below. - -Those repair facilities with access to the OA3 Tool (which is part of the ADK) can use the tool to capture the 4K Hardware Hash (4K HH). - -Alternatively, the [WindowsAutoPilotInfo PowerShell script](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo) can be used to capture the 4K HH by following these steps: - -1. Install the script from the [PowerShell Gallery](https://www.powershellgallery.com/packages/Get-WindowsAutoPilotInfo) or from the command line (command line installation is shown below). -2. Navigate to the script directory and run it on the device when the device is either in Full OS or Audit Mode. See the following example. - - ```powershell - md c:\HWID - Set-Location c:\HWID - Set-ExecutionPolicy -Scope Process -ExecutionPolicy Unrestricted -Force - Install-Script -Name Get-WindowsAutopilotInfo -Force - Get-WindowsAutopilotInfo.ps1 -OutputFile AutopilotHWID.csv - ``` - ->If you are prompted to install the NuGet package, choose **Yes**.
->If, after installing the script you get an error that Get-WindowsAutopilotInfo.ps1 is not found, verify that C:\Program Files\WindowsPowerShell\Scripts is present in your PATH variable.
->If the Install-Script cmdlet fails, verify that you have the default PowerShell repository registered (**Get-PSRepository**) or register the default repository with **Register-PSRepository -Default -Verbose**. - -The script creates a .csv file that contains the device information, including the complete 4K HH. Save this file so that you can access it later. The service facility will use this 4K HH to reregister device as described below. Be sure to use the -OutputFile parameter when saving the file, which ensures that file formatting is correct. Do not attempt to pipe the command output to a file manually. - -**NOTE**: If the repair facility does not have the ability to run the OA3 tool or PowerShell script to capture the new 4K HH, then the CSP (or OEM) partners must do this for them. Without some entity capturing the new 4K HH, there is no way to reregister this device as an Autopilot device. - - -## Reregister the repaired device using the new device ID - -If an OEM is not able to reregister the device, then the repair facility or CSP should reregister the device using MPC, or the customer IT Admin should be advised to reregister the device via Intune (or MSfB). Both ways of reregistering a device are shown below. - -### Reregister from Intune - -To reregister an Autopilot device from Intune, an IT Admin would: -1. Sign in to Intune. -2. Navigate to Device enrollment > Windows enrollment > Devices > Import. -3. Click the **Import** button to upload a csv file containing the device ID of the device to be reregistered (the device ID was the 4K HH captured by the PowerShell script or OA3 tool described previously in this document). - -The following video provides a good overview of how to (re)register devices via MSfB.
- -> [!VIDEO https://www.youtube.com/embed/IpLIZU_j7Z0] - -### Reregister from MPC - -To reregister an Autopilot device from MPC, an OEM or CSP would: - -1. Sign in to MPC. -2. Navigate to the Customer > Devices page and click the **Add devices** button to upload the csv file. - -![device](images/device2.png)
-![device](images/device3.png) - -In the case of reregistering a repaired device through MPC, the uploaded csv file must contain the 4K HH for the device, and not just the PKID or Tuple (SerialNumber + OEMName + ModelName). If only the PKID or Tuple was used, the Autopilot service would be unable to find a match in the Autopilot database, since no 4K HH info was ever previously submitted for this essentially “new” device, and the upload will fail, likely returning a ZtdDeviceNotFound error. So, again, only upload the 4K HH, not the Tuple or PKID. - -**NOTE**: When including the 4K HH in the csv file, you do NOT also need to include the PKID or Tuple. Those columns may be left blank, as shown below: - -![hash](images/hh.png) - -## Reset the device - -Since the device was required to be in Full OS or Audit Mode to capture the 4K HH, the repair facility must reset the image back to a pre-OOBE state before returning it to the customer. One way this can be accomplished is by using the built-in reset feature in Windows, as follows: - -On the device, go to Settings > Update & Security > Recovery and click on Get started. Under Reset this PC, select Remove everything and Just remove my files. Finally, click on Reset. - -![reset](images/reset.png) - -However, it’s likely the repair facility won’t have access to Windows because they lack the user credentials to sign in, in which case they need to use other means to reimage the device, such as the [Deployment Image Servicing and Management tool](https://docs.microsoft.com/windows-hardware/manufacture/desktop/oem-deployment-of-windows-10-for-desktop-editions#use-a-deployment-script-to-apply-your-image). - -## Return the repaired device to the customer - -After completing the previous steps, the repaired device can now be returned to the customer, and will be auto-enrolled into the Autopilot program on first boot-up during OOBE. - -**NOTE**: If the repair facility did NOT reimage the device, they could be sending it back in a potentially broken state (e.g., there’s no way to log into the device because it’s been dissociated from the only known user account), in which case they should tell the organization that they need to fix the registration and OS themselves. - -**IMPORTANT**: A device can be “registered” for Autopilot prior to being powered-on, but the device isn’t actually “deployed” to Autopilot (i.e., enabled as an Autopilot device) until it goes through OOBE, which is why resetting the device back to a pre-OOBE state is a required step. - -## Specific repair scenarios - -This section covers the most common repair scenarios, and their impact on Autopilot enablement. - -NOTES ON TEST RESULTS: - -- Scenarios below were tested using Intune only (no other MDMs were tested). -- In most test scenarios below, the repaired and reregistered device needed to go through OOBE again for Autopilot to be enabled. -- Motherboard replacement scenarios often result in lost data, so repair centers or customers should be reminded to back up data (if possible) prior to repair. -- In the cases where a repair facility does not have the ability to write device info into the BIOS of the repaired device, new processes need to be created to successfully enable Autopilot. -- Repaired device should have the Product Key (DPK) preinjected in the BIOS before capturing the new 4K HH (device ID) - -In the following table:
-- Supported = **Yes**: the device can be reenabled for Autopilot -- Supported = **No**: the device cannot be reenabled for Autopilot - - -
ScenarioSupportedMicrosoft Recommendation -
Motherboard Replacement (MBR) in generalYesThe recommended course of action for MBR scenarios is: - -1. Autopilot device is deregistered from the Autopilot program -2. The motherboard is replace -3. The device is reimaged (with BIOS info and DPK reinjected)* -4. A new Autopilot device ID (4K HH) is captured off the device -5. The repaired device is reregistered for the Autopilot program using the new device ID -6. The repaired device is reset to boot to OOBE -7. The repaired device is shipped back to the customer - -*It’s not necessary to reimage the device if the repair technician has access to the customer’s login credentials. It’s technically possible to do a successful MBR and Autopilot re-enablement without keys or certain BIOS info (e.g., serial #, model name, etc.), but doing so is only recommended for testing/educational purposes. - -
MBR when motherboard has a TPM chip (enabled) and only one onboard network card (that also gets replaced)Yes - -1. Deregister damaged device -2. Replace motherboard -3. Reimage device (to gain access), unless you have access to customers’ login credentials -4. Write device info into BIOS -5. Capture new 4K HH -6. Reregister repaired device -7. Reset device back to OOBE -8. Go through Autopilot OOBE (customer) -9. Autopilot successfully enabled - -
MBR when motherboard has a TPM chip (enabled) and a second network card (or network interface) that is not replaced along with the motherboardNoThis scenario is not recommended, as it breaks the Autopilot experience, because the resulting Device ID will not be stable until after TPM attestation has completed, and even then registration may give incorrect results because of ambiguity with MAC Address resolution. -
MBR where the NIC card, HDD, and WLAN all remain the same after the repairYes - -1. Deregister damaged device -2. Replace motherboard (with new RDPK preinjected in BIOS) -3. Reimage device (to gain access), unless you have access to customers’ login credentials -4. Write old device info into BIOS (same s/n, model, etc.)* -5. Capture new 4K HH -6. Reregister repaired device -7. Reset device back to OOBE -8. Go through Autopilot OOBE (customer) -9. Autopilot successfully enabled - -*Note that for this and subsequent scenarios, rewriting old device info would not include the TPM 2.0 endorsement key, as the associated private key is locked to the TPM device - -
MBR where the NIC card remains the same, but the HDD and WLAN are replacedYes - -1. Deregister damaged device -2. Replace motherboard (with new RDPK preinjected in BIOS) -3. Insert new HDD and WLAN -4. Write old device info into BIOS (same s/n, model, etc.) -5. Capture new 4K HH -6. Reregister repaired device -7. Reset device back to OOBE -8. Go through Autopilot OOBE (customer) -9. Autopilot successfully enabled - -
MBR where the NIC card and WLAN remains the same, but the HDD is replacedYes - -1. Deregister damaged device -2. Replace motherboard (with new RDPK preinjected in BIOS) -3. Insert new HDD -4. Write old device info into BIOS (same s/n, model, etc.) -5. Capture new 4K HH -6. Reregister repaired device -7. Reset device back to OOBE -8. Go through Autopilot OOBE (customer) -9. Autopilot successfully enabled - -
MBR where only the MB is replaced (all other parts remain same) but new MB was taken from a previously used device that had NOT been Autopilot-enabled before.Yes - -1. Deregister damaged device -2. Replace motherboard (with new RDPK preinjected in BIOS) -3. Reimage device (to gain access), unless you have access to customers’ login credentials -4. Write old device info into BIOS (same s/n, model, etc.) -5. Capture new 4K HH -6. Reregister repaired device -7. Reset device back to OOBE -8. Go through Autopilot OOBE (customer) -9. Autopilot successfully enabled - -
MBR where only the MB is replaced (all other parts remain same) but new MB was taken from a previously used device that HAD been Autopilot-enabled before.Yes - -1. Deregister old device from which MB will be taken -2. Deregister damaged device (that you want to repair) -3. Replace motherboard in repair device with MB from other Autopilot device (with new RDPK preinjected in BIOS) -4. Reimage device (to gain access), unless you have access to customers’ login credentials -5. Write old device info into BIOS (same s/n, model, etc.) -6. Capture new 4K HH -7. Reregister repaired device -8. Reset device back to OOBE -9. Go through Autopilot OOBE (customer) -10. Autopilot successfully enabled - -NOTE: The repaired device can also be used successfully as a normal, non-Autopilot device. - -
BIOS info excluded from MBR deviceNoRepair facility does not have BIOS tool to write device info into BIOS after MBR. - -1. Deregister damaged device -2. Replace motherboard (BIOS does NOT contain device info) -3. Reimage and write DPK into image -4. Capture new 4K HH -5. Reregister repaired device -6. Create Autopilot profile for device -7. Go through Autopilot OOBE (customer) -8. Autopilot FAILS to recognize repaired device - -
MBR when there is no TPM chipYesThough we do not recommend enabling Autopilot devices without a TPM chip (which is recommended for BitLocker encryption), it is possible to enable an Autopilot device in “standard user” mode (but NOT Self-deploying mode) that does not have a TPM chip. In this case, you would: - -1. Deregister damaged device -2. Replace motherboard -3. Reimage device (to gain access), unless you have access to customers’ login credentials -4. Write old device info into BIOS (same s/n, model, etc.) -5. Capture new 4K HH -6. Reregister repaired device -7. Reset device back to OOBE -8. Go through Autopilot OOBE (customer) -9. Autopilot successfully enabled - -
New DPK written into image on repaired Autopilot device with a new MBYesRepair facility replaces normal MB on damaged device. MB does not contain any DPK in the BIOS. Repair facility writes DPK into image after MBR. - -1. Deregister damaged device -2. Replace motherboard – BIOS does NOT contain DPK info -3. Reimage device (to gain access), unless you have access to customers’ login credentials -4. Write device info into BIOS (same s/n, model, etc.) -5. Capture new 4K HH -6. Reset or reimage device to pre-OOBE and write DPK into image -7. Reregister repaired device -8. Go through Autopilot OOBE -9. Autopilot successfully enabled - -
New Repair Product Key (RDPK)YesUsing a motherboard with a new RDPK preinjected results in a successful Autopilot refurbishment scenario. - -1. Deregister damaged device -2. Replace motherboard (with new RDPK preinjected in BIOS) -3. Reimage or rest image to pre-OOBE -4. Write device info into BIOS -5. Capture new 4K HH -6. Reregister repaired device -7. Reimage or reset image to pre-OOBE -8. Go through Autopilot OOBE -9. Autopilot successfully enabled - -
No Repair Product Key (RDPK) injectedNoThis scenario violates Microsoft policy and breaks the Windows Autopilot experience. -
Reimage damaged Autopilot device that was not deregistered prior to repairYes, but the device will still be associated with previous tenant ID, so should only be returned to same customer - -1. Reimage damaged device -2. Write DPK into image -3. Go through Autopilot OOBE -4. Autopilot successfully enabled (to previous tenant ID) - -
Disk replacement from a non-Autopilot device to an Autopilot deviceYes - -1. Do not deregister damaged device prior to repair -2. Replace HDD on damaged device -3. Reimage or reset image back to OOBE -4. Go through Autopilot OOBE (customer) -5. Autopilot successfully enabled (repaired device recognized as its previous self) - -
Disk replacement from one Autopilot device to another Autopilot deviceMaybeIf the device from which the HDD is taken was itself previously deregistered from Autopilot, then that HDD can be used in a repair device. But if the HDD was never previously deregistered from Autopilot before being used in a repaired device, the newly repaired device will not have the proper Autopilot experience. - -Assuming the used HDD was previously deregistered (before being used in this repair): - -1. Deregister damaged device -2. Replace HDD on damaged device using a HDD from another deregistered Autopilot device -3. Reimage or rest the repaired device back to a pre-OOBE state -4. Go through Autopilot OOBE (customer) -5. Autopilot successfully enabled - -
Non-Microsoft network card replacement NoWhether from a non-Autopilot device to an Autopilot device, from one Autopilot device to another Autopilot device, or from an Autopilot device to a non-Autopilot device, any scenario where a 3rd party (not onboard) Network card is replaced will break the Autopilot experience, and is not recommended. -
A device repaired more than 3 timesNoAutopilot is not supported when a device is repeatedly repaired, so that whatever parts NOT replaced become associated with too many parts that have been replaced, which would make it difficult to uniquely identify that device in the future. -
Memory replacementYesReplacing the memory on a damaged device does not negatively affect the Autopilot experience on that device. No de/reregistration is needed. The repair technician simply needs to replace the memory. -
GPU replacementYesReplacing the GPU(s) on a damaged device does not negatively affect the Autopilot experience on that device. No de/reregistration is needed. The repair technician simply needs to replace the GPU. -
- ->When scavenging parts from another Autopilot device, we recommend unregistering the scavenged device from Autopilot, scavenging it, and then NEVER REGISTERING THE SCAVENGED DEVICE (AGAIN) FOR AUTOPILOT, because reusing parts this way may cause two active devices to end up with the same ID, with no possibility of distinguishing between the two. - -**NOTE**: The following parts may be replaced without compromising Autopilot enablement or requiring special additional repair steps: -- Memory (RAM or ROM) -- Power Supply -- Video Card -- Card Reader -- Sound card -- Expansion card -- Microphone -- Webcam -- Fan -- Heat sink -- CMOS battery - -Other repair scenarios not yet tested and verified include: -- Daughterboard replacement -- CPU replacement -- Wifi replacement -- Ethernet replacement - -## FAQ - -| Question | Answer | -| --- | --- | -| If we have a tool that programs product information into the BIOS after the MBR, do we still need to submit a CBR report for the device to be Autopilot-capable? | No. Not if the in-house tool writes the minimum necessary information into the BIOS that the Autopilot program looks for to identify the device, as described earlier in this document. | -| What if only some components are replaced rather than the full motherboard? | While it’s true that some limited repairs do not prevent the Autopilot algorithm from successfully matching the post-repair device with the pre-repair device, it is best to ensure 100% success by going through the MBR steps above even for devices that only needed limited repairs. | -| How does a repair technician gain access to a broken device if they don’t have the customer’s login credentials? | The technician will have to reimage the device and use their own credentials during the repair process. | - -## Related topics - -[Device guidelines](autopilot-device-guidelines.md)
diff --git a/windows/deployment/windows-autopilot/autopilot-support.md b/windows/deployment/windows-autopilot/autopilot-support.md deleted file mode 100644 index 762aab67e5..0000000000 --- a/windows/deployment/windows-autopilot/autopilot-support.md +++ /dev/null @@ -1,37 +0,0 @@ ---- -title: Windows Autopilot support -description: Find out who to contact for help with your Windows Autopilot installation. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: low -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.reviewer: -manager: laurawi -ms.collection: M365-modern-desktop -ms.topic: article ---- - -# Windows Autopilot support information - -**Applies to: Windows 10** - -The following table displays support information for the Windows Autopilot program. - -Before contacting the resources listed below for Windows Autopilot-related issues, check the [Windows Autopilot FAQ](autopilot-faq.md). - -| Audience | Support contact | -|------------|---------------------------------------| -| OEM or Channel Partner registering devices as a CSP (via MPC) | Use the help resources available in MPC. Whether you are a named partner or a channel partner (distributor, reseller, SI, etc.), if you’re a CSP registering Autopilot devices through MPC (either manually or through the MPC API), your first-line of support should be the help resources within MPC. | -| OEM registering devices using OEM Direct API | Contact MSOEMOPS@microsoft.com. Response time depends on priority:
Low – 120 hours
Normal – 72 hours
High – 24 hours
Immediate – 4 hours | -| Enterprise customers | Contact your Technical Account Manager (TAM), or Account Technology Strategist (ATS), or Customer Service Support (CSS) representative. | -| End-user | Contact your IT administrator. | -| Microsoft Partner Center (MPC) users | Use the [help resources](https://partner.microsoft.com/support) available in MPC. | -| Microsoft Store for Business (MSfB) users | Use the help resources available in MSfB. | -| Intune users | From the Microsoft Azure portal, click [Help + support](https://portal.azure.com/#blade/Microsoft_Azure_Support/HelpAndSupportBlade/overview). | -| Microsoft 365 Business | Support is accessible directly through the Microsoft 365 Business portal when logged in: https://support.microsoft.com/en-us. | -| Queries relating to MDA testing | Contact MDAHelp@microsoft.com. | \ No newline at end of file diff --git a/windows/deployment/windows-autopilot/autopilot-update.md b/windows/deployment/windows-autopilot/autopilot-update.md deleted file mode 100644 index db4094b8a8..0000000000 --- a/windows/deployment/windows-autopilot/autopilot-update.md +++ /dev/null @@ -1,48 +0,0 @@ ---- -title: Windows Autopilot update -ms.reviewer: -manager: laurawi -description: Windows Autopilot update -keywords: Autopilot, update, Windows 10 -ms.prod: w10 -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: deploy -ms.localizationpriority: medium -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Windows Autopilot update - -**Applies to** - -- Windows 10, version 1903 - -Windows Autopilot update enables you to get the latest Autopilot features and critical issue fixes without the need to move to latest Windows OS version. With Autopilot update, organizations can keep their current OS version and still benefit from new Autopilot features and bug fixes. - -During the Autopilot deployment process, Windows Autopilot update has been added as a new node after the critical [Windows Zero Day Patch (ZDP) update](https://docs.microsoft.com/windows-hardware/customize/desktop/windows-updates-during-oobe) check. During the update process, Windows Autopilot devices reach out to Windows Update to check for a new Autopilot update. If there is an Autopilot update available, the device will download and install the update, then restart automatically. See the following example. - - ![Autopilot update 1](images/update1.png)
- ![Autopilot update 2](images/update2.png)
- ![Autopilot update 3](images/update3.png) - -The following diagram illustrates a typical Windows Autopilot deployment orchestration during the Out of Box Experience (OOBE) with the new Windows Autopilot update node. - - ![Autopilot update flow](images/update-flow.png) - -## Release cadence - -- When an Autopilot update is available, it is typically released on the 4th Tuesday of the month. The update could be released on a different week if there is an exception. -- A knowledge base (KB) article will also be published to document the changes that are included in the update. - -For a list of released updates, see [Autopilot update history](windows-autopilot-whats-new.md#windows-autopilot-update-history). - -## See also - -[Windows Update during OOBE](https://docs.microsoft.com/windows-hardware/customize/desktop/windows-updates-during-oobe)
-[What's new in Windows Autopilot](windows-autopilot-whats-new.md)
\ No newline at end of file diff --git a/windows/deployment/windows-autopilot/bitlocker.md b/windows/deployment/windows-autopilot/bitlocker.md deleted file mode 100644 index 542243d569..0000000000 --- a/windows/deployment/windows-autopilot/bitlocker.md +++ /dev/null @@ -1,54 +0,0 @@ ---- -title: Setting the BitLocker encryption algorithm for Autopilot devices -ms.reviewer: -manager: laurawi -description: Microsoft Intune provides a comprehensive set of configuration options to manage BitLocker on Windows 10 devices. -keywords: Autopilot, BitLocker, encryption, 256-bit, Windows 10 -ms.prod: w10 -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: deploy -ms.localizationpriority: medium -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Setting the BitLocker encryption algorithm for Autopilot devices - -**Applies to** - -- Windows 10 - -With Windows Autopilot, you can configure the BitLocker encryption settings to be applied before automatic encryption is started. This ensures that the default encryption algorithm isn't applied automatically when this is not the desired setting. Other BitLocker policies that must be applied prior to encryption can also be delivered before automatic BitLocker encryption begins. - -The BitLocker encryption algorithm is used when BitLocker is first enabled, and sets the strength to which full volume encryption should occur. Available encryption algorithms are: AES-CBC 128-bit, AES-CBC 256-bit, XTS-AES 128-bit, or XTS-AES 256-bit encryption. The default value is XTS-AES 128-bit encryption. See [BitLocker CSP](https://docs.microsoft.com/windows/client-management/mdm/bitlocker-csp) for information about the recommended encryption algorithms to use. - -To ensure the desired BitLocker encryption algorithm is set before automatic encryption occurs for Autopilot devices: - -1. Configure the [encryption method settings](https://docs.microsoft.com/intune/endpoint-protection-windows-10#windows-encryption) in the Windows 10 Endpoint Protection profile to the desired encryption algorithm. -2. [Assign the policy](https://docs.microsoft.com/intune/device-profile-assign) to your Autopilot device group. - - **IMPORTANT**: The encryption policy must be assigned to **devices** in the group, not users. -3. Enable the Autopilot [Enrollment Status Page](https://docs.microsoft.com/windows/deployment/windows-autopilot/enrollment-status) (ESP) for these devices. - - **IMPORTANT**: If the ESP is not enabled, the policy will not apply before encryption starts. - -An example of Microsoft Intune Windows Encryption settings is shown below. - - ![BitLocker encryption settings](images/bitlocker-encryption.png) - -**Note**: A device that is encrypted automatically will need to be decrypted prior to changing the encryption algorithm. - -The settings are available under Device Configuration -> Profiles -> Create profile -> Platform = Windows 10 and later, Profile type = Endpoint protection -> Configure -> Windows Encryption -> BitLocker base settings, Configure encryption methods = Enable. - -**Note**: It is also recommended to set Windows Encryption -> Windows Settings -> Encrypt = **Require**. - -## Requirements - -Windows 10, version 1809 or later. - -## See also - -[BitLocker overview](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-overview) diff --git a/windows/deployment/windows-autopilot/deployment-process.md b/windows/deployment/windows-autopilot/deployment-process.md deleted file mode 100644 index 6723d50e35..0000000000 --- a/windows/deployment/windows-autopilot/deployment-process.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: Windows 10 deployment process posters -description: View and download Windows 10 deployment process flows for Microsoft Endpoint Configuration Manager and Windows Autopilot. -ms.reviewer: -manager: laurawi -ms.audience: itpro -author: greg-lindsay -keywords: upgrade, in-place, configuration, deploy -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -audience: itpro -author: greg-lindsay -ms.topic: article ---- - -# Windows Autopilot deployment process - -**Applies to** -- Windows 10 - -Windows Autopilot deployment processes are summarized in the poster below. The poster is two pages in portrait mode (11x17). Click the image below to view a PDF in your browser. - -[![Deploy Windows 10 with Autopilot](../media/windows10-autopilot-flowchart.png)](../media/Windows10AutopilotFlowchart.pdf) - -**Note**: The Windows Autopilot for existing devices process is included in the [Microsoft Endpoint Configuration Manager deployment poster](../windows-10-deployment-posters.md#deploy-windows-10-with-microsoft-endpoint-configuration-manager). \ No newline at end of file diff --git a/windows/deployment/windows-autopilot/dfci-management.md b/windows/deployment/windows-autopilot/dfci-management.md deleted file mode 100644 index 550420a264..0000000000 --- a/windows/deployment/windows-autopilot/dfci-management.md +++ /dev/null @@ -1,70 +0,0 @@ ---- -title: DFCI Management -ms.reviewer: -manager: laurawi -description: With Windows Autopilot Deployment and Intune, you can manage UEFI (BIOS) settings after they're enrolled by using the Device Firmware Configuration Interface (DFCI) -keywords: Autopilot, DFCI, UEFI, Windows 10 -ms.prod: w10 -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: deploy -ms.localizationpriority: medium -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# DFCI Management - -**Applies to** - -- Windows 10 - -With Windows Autopilot Deployment and Intune, you can manage Unified Extensible Firmware Interface (UEFI) settings after they're enrolled by using the Device Firmware Configuration Interface (DFCI). DFCI [enables Windows to pass management commands](https://docs.microsoft.com/windows/client-management/mdm/uefi-csp) from Intune to UEFI to Autopilot deployed devices. This allows you to limit end user's control over BIOS settings. For example, you can lock down the boot options to prevent users from booting up another OS, such as one that doesn't have the same security features. - -If a user reinstalls a previous Windows version, install a separate OS, or format the hard drive, they can't override DFCI management. This feature can also prevent malware from communicating with OS processes, including elevated OS processes. DFCI’s trust chain uses public key cryptography, and doesn't depend on local UEFI password security. This layer of security blocks local users from accessing managed settings from the device’s UEFI menus. - -For an overview of DFCI benefits, scenarios, and prerequisites, see [Device Firmware Configuration Interface (DFCI) Introduction](https://microsoft.github.io/mu/dyn/mu_plus/DfciPkg/Docs/Dfci_Feature/). - -## DFCI management lifecycle - -The DFCI management lifecycle can be viewed as UEFI integration, device registration, profile creation, enrollment, management, retirement, and recovery. See the following figure. - - ![Lifecycle](images/dfci.png) - -## Requirements - -- Windows 10, version 1809 or later and a supported UEFI is required. -- The device manufacturer must have DFCI added to their UEFI firmware in the manufacturing process, or as a firmware update that you install. Work with your device vendors to determine the [manufacturers that support DFCI](#oems-that-support-dfci), or the firmware version needed to use DFCI. -- The device must be managed with Microsoft Intune. For more information, see [Enroll Windows devices in Intune using Windows Autopilot](https://docs.microsoft.com/intune/enrollment/enrollment-autopilot). -- The device must be registered for Windows Autopilot by a [Microsoft Cloud Solution Provider (CSP) partner](https://partner.microsoft.com/membership/cloud-solution-provider), or registered directly by the OEM. - ->[!IMPORTANT] ->Devices manually registered for Autopilot (such as by [importing from a csv file](https://docs.microsoft.com/intune/enrollment/enrollment-autopilot#add-devices)) are not allowed to use DFCI. By design, DFCI management requires external attestation of the device’s commercial acquisition through an OEM or a Microsoft CSP partner registration to Windows Autopilot. When your device is registered, its serial number is displayed in the list of Windows Autopilot devices. - -## Managing DFCI profile with Windows Autopilot - -There are four basic steps in managing DFCI profile with Windows Autopilot: - -1. Create an Autopilot Profile -2. Create an Enrollment status page profile -3. Create a DFCI profile -4. Assign the profiles - -See [Create the profiles](https://docs.microsoft.com/intune/configuration/device-firmware-configuration-interface-windows#create-the-profiles) and [Assign the profiles, and reboot](https://docs.microsoft.com/intune/configuration/device-firmware-configuration-interface-windows#assign-the-profiles-and-reboot) for details. - -You can also [change existing DFCI settings](https://docs.microsoft.com/intune/configuration/device-firmware-configuration-interface-windows#update-existing-dfci-settings) on devices that are in use. In your existing DFCI profile, change the settings and save your changes. Since the profile is already assigned, the new DFCI settings take effect when next time the device syncs or the device reboots. - -## OEMs that support DFCI - -- [Microsoft Surface](https://docs.microsoft.com/surface/surface-manage-dfci-guide) - -Additional OEMs are pending. - -## See also - -[Microsoft DFCI Scenarios](https://microsoft.github.io/mu/dyn/mu_plus/DfciPkg/Docs/Scenarios/DfciScenarios/)
-[Windows Autopilot and Surface devices](https://docs.microsoft.com/surface/windows-autopilot-and-surface-devices)
\ No newline at end of file diff --git a/windows/deployment/windows-autopilot/enrollment-status.md b/windows/deployment/windows-autopilot/enrollment-status.md deleted file mode 100644 index 11a393eada..0000000000 --- a/windows/deployment/windows-autopilot/enrollment-status.md +++ /dev/null @@ -1,39 +0,0 @@ ---- -title: Windows Autopilot Enrollment Status Page -ms.reviewer: -manager: laurawi -description: Gives an overview of the Enrollment Status Page capabilities, configuration -keywords: Autopilot Plug and Forget, Windows 10 -ms.prod: w10 -ms.mktglfcycl: deploy -ms.sitesec: library -ms.pagetype: deploy -ms.localizationpriority: medium -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Windows Autopilot Enrollment Status Page - -**Applies to** - -- Windows 10, version 1803 and later - -The Enrollment Status Page (ESP) displays the status of the complete device configuration process when an MDM managed user signs into a device for the very first time. The ESP will help users understand the progress of device provisioning and ensures the device has met the organizations desired state before the user can access the desktop for the first time. - -The ESP will track the installation of applications, security policies, certificates and network connections. Within Intune, an administrator can deploy ESP profiles to a licensed Intune user and configure specific settings within the ESP profile; a few of these settings are: force the installation of specified applications, allow users to collect troubleshooting logs, specify what a user can do if device setup fails. For more information, see how to set up the [Enrollment Status Page in Intune](https://docs.microsoft.com/intune/windows-enrollment-status). - - ![Enrollment Status Page](images/enrollment-status-page.png) - - -## More information - -For more information on configuring the Enrollment Status Page, see the [Microsoft Intune documentation](https://docs.microsoft.com/intune/windows-enrollment-status).
-For details about the underlying implementation, see the [FirstSyncStatus details in the DMClient CSP documentation](https://docs.microsoft.com/windows/client-management/mdm/dmclient-csp).
-For more information about blocking for app installation: -- [Blocking for app installation using Enrollment Status Page](https://blogs.technet.microsoft.com/mniehaus/2018/12/06/blocking-for-app-installation-using-enrollment-status-page/). -- [Support Tip: Office C2R installation is now tracked during ESP](https://techcommunity.microsoft.com/t5/Intune-Customer-Success/Support-Tip-Office-C2R-installation-is-now-tracked-during-ESP/ba-p/295514). diff --git a/windows/deployment/windows-autopilot/existing-devices.md b/windows/deployment/windows-autopilot/existing-devices.md deleted file mode 100644 index 2ea6052a20..0000000000 --- a/windows/deployment/windows-autopilot/existing-devices.md +++ /dev/null @@ -1,324 +0,0 @@ ---- -title: Windows Autopilot for existing devices -description: Modern desktop deployment with Windows Autopilot enables you to easily deploy the latest version of Windows 10 to your existing devices. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.reviewer: mniehaus -manager: laurawi -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - -# Windows Autopilot for existing devices - -**Applies to: Windows 10** - -Modern desktop deployment with Windows Autopilot enables you to easily deploy the latest version of Windows 10 to your existing devices. The apps you need for work can be automatically installed. Your work profile is synchronized, so you can resume working right away. - -This topic describes how to convert Windows 7 or Windows 8.1 domain-joined computers to Windows 10 devices joined to either Azure Active Directory or Active Directory (Hybrid Azure AD Join) by using Windows Autopilot. - ->[!NOTE] ->Windows Autopilot for existing devices only supports user-driven Azure Active Directory and Hybrid Azure AD profiles. Self-deploying profiles are not supported. - -## Prerequisites - -- A currently supported version of Microsoft Endpoint Configuration Manager current branch or technical preview branch. -- The [Windows ADK](https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit) 1803 or later - - For more information on Configuration Manager support, see [Support for Windows 10 ADK](https://docs.microsoft.com/configmgr/core/plan-design/configs/support-for-windows-10#windows-10-adk). -- Assigned Microsoft Intune Licenses -- Azure Active Directory Premium -- Windows 10 version 1809 or later imported into Configuration Manager as an Operating System Image - - **Important**: See [Known issues](known-issues.md) if you are using Windows 10 1903 with Configuration Manager’s built-in **Windows Autopilot existing device** task sequence template. Currently, one of the steps in this task sequence must be edited to work properly with Windows 10, version 1903. - -## Procedures - -### Configure the Enrollment Status Page (optional) - -If desired, you can set up an [enrollment status page](https://docs.microsoft.com/windows/deployment/windows-autopilot/enrollment-status) for Autopilot using Intune. - -To enable and configure the enrollment and status page: - -1. Open [Intune in the Azure portal](https://aka.ms/intuneportal). -2. Access **Intune > Device enrollment > Windows enrollment** and [Set up an enrollment status page](https://docs.microsoft.com/intune/windows-enrollment-status). -3. Access **Azure Active Directory > Mobility (MDM and MAM) > Microsoft Intune** and [Configure automatic MDM enrollment](https://docs.microsoft.com/configmgr/mdm/deploy-use/enroll-hybrid-windows#enable-windows-10-automatic-enrollment) and configure the MDM user scope for some or all users. - -See the following examples. - -![enrollment status page](images/esp-config.png)

-![mdm](images/mdm-config.png) - -### Create the JSON file - ->[!TIP] ->To run the following commands on a computer running Windows Server 2012/2012 R2 or Windows 7/8.1, you must first download and install the [Windows Management Framework](https://www.microsoft.com/download/details.aspx?id=54616). - -1. On an Internet connected Windows PC or server, open an elevated Windows PowerShell command window -2. Enter the following lines to install the necessary modules - - #### Install required modules - - ```powershell - Install-PackageProvider -Name NuGet -MinimumVersion 2.8.5.201 -Force - Install-Module AzureAD -Force - Install-Module WindowsAutopilotIntune -Force - Install-Module Microsoft.Graph.Intune -Force - ``` - -3. Enter the following lines and provide Intune administrative credentials - - Be sure that the user account you specify has sufficient administrative rights. - - ```powershell - Connect-MSGraph - ``` - The user and password for your account will be requested using a standard Azure AD form. Type your username and password and then click **Sign in**. -
See the following example: - - ![Azure AD authentication](images/pwd.png) - - If this is the first time you’ve used the Intune Graph APIs, you’ll also be prompted to enable read and write permissions for Microsoft Intune PowerShell. To enable these permissions: - - Select **Consent on behalf or your organization** - - Click **Accept** - -4. Next, retrieve and display all the Autopilot profiles available in the specified Intune tenant in JSON format: - - #### Retrieve profiles in Autopilot for existing devices JSON format - - ```powershell - Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON - ``` - - See the following sample output: (use the horizontal scroll bar at the bottom to view long lines) - 
-    PS C:\> Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON
-    {
-        "CloudAssignedTenantId":  "1537de22-988c-4e93-b8a5-83890f34a69b",
-        "CloudAssignedForcedEnrollment":  1,
-        "Version":  2049,
-        "Comment_File":  "Profile Autopilot Profile",
-        "CloudAssignedAadServerData":  "{\"ZeroTouchConfig\":{\"CloudAssignedTenantUpn\":\"\",\"ForcedEnrollment\":1,\"CloudAssignedTenantDomain\":\"M365x373186.onmicrosoft.com\"}}",
-        "CloudAssignedTenantDomain":  "M365x373186.onmicrosoft.com",
-        "CloudAssignedDomainJoinMethod":  0,
-        "CloudAssignedOobeConfig":  28,
-        "ZtdCorrelationId":  "7F9E6025-1E13-45F3-BF82-A3E8C5B59EAC"
-    }
- - Each profile is encapsulated within braces **{ }**. In the previous example, a single profile is displayed. - - See the following table for a description of properties used in the JSON file. - - - | Property | Description | - |------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| - | Version (number, optional) | The version number that identifies the format of the JSON file. For Windows 10 1809, the version specified must be 2049. | - | CloudAssignedTenantId (guid, required) | The Azure Active Directory tenant ID that should be used. This is the GUID for the tenant, and can be found in properties of the tenant. The value should not include braces. | - | CloudAssignedTenantDomain (string, required) | The Azure Active Directory tenant name that should be used, for example: tenant.onmicrosoft.com. | - | CloudAssignedOobeConfig (number, required) | This is a bitmap that shows which Autopilot settings were configured. Values include: SkipCortanaOptIn = 1, OobeUserNotLocalAdmin = 2, SkipExpressSettings = 4, SkipOemRegistration = 8, SkipEula = 16 | - | CloudAssignedDomainJoinMethod (number, required) | This property specifies whether the device should join Azure Active Directory or Active Directory (Hybrid Azure AD Join). Values include: Active AD Join = 0, Hybrid Azure AD Join = 1 | - | CloudAssignedForcedEnrollment (number, required) | Specifies that the device should require AAD Join and MDM enrollment.
0 = not required, 1 = required. | - | ZtdCorrelationId (guid, required) | A unique GUID (without braces) that will be provided to Intune as part of the registration process. ZtdCorrelationId will be included in enrollment message as “OfflineAutoPilotEnrollmentCorrelator”. This attribute will be present only if the enrollment is taking place on a device registered with Zero Touch Provisioning via offline registration. | - | CloudAssignedAadServerData (encoded JSON string, required) | An embedded JSON string used for branding. It requires AAD corp branding enabled.
Example value: "CloudAssignedAadServerData": "{\"ZeroTouchConfig\":{\"CloudAssignedTenantUpn\":\"\",\"CloudAssignedTenantDomain\":\"tenant.onmicrosoft.com\"}}" | - | CloudAssignedDeviceName (string, optional) | The name automatically assigned to the computer. This follows the naming pattern convention that can be configured in Intune as part of the Autopilot profile, or can specify an explicit name to use. | - - -5. The Autopilot profile must be saved as a JSON file in ASCII or ANSI format. Windows PowerShell defaults to Unicode format, so if you attempt to redirect output of the commands to a file, you must also specify the file format. For example, to save the file in ASCII format using Windows PowerShell, you can create a directory (ex: c:\Autopilot) and save the profile as shown below: (use the horizontal scroll bar at the bottom if needed to view the entire command string) - - ```powershell - Get-AutopilotProfile | ConvertTo-AutopilotConfigurationJSON | Out-File c:\Autopilot\AutopilotConfigurationFile.json -Encoding ASCII - ``` - **IMPORTANT**: The file name must be named **AutopilotConfigurationFile.json** in addition to being encoded as ASCII/ANSI. - - If preferred, you can save the profile to a text file and edit in Notepad. In Notepad, when you choose **Save as** you must select Save as type: **All Files** and choose ANSI from the drop-down list next to **Encoding**. See the following example. - - ![Notepad JSON](images/notepad.png) - - After saving the file, move the file to a location suitable as a Microsoft Endpoint Configuration Manager package source. - - >[!IMPORTANT] - >Multiple JSON profile files can be used, but each must be named **AutopilotConfigurationFile.json** in order for OOBE to follow the Autopilot experience. The file also must be encoded as ANSI.

**Saving the file with Unicode or UTF-8 encoding or saving it with a different file name will cause Windows 10 OOBE to not follow the Autopilot experience**.
- - -### Create a package containing the JSON file - -1. In Configuration Manager, navigate to **\Software Library\Overview\Application Management\Packages** -2. On the ribbon, click **Create Package** -3. In the **Create Package and Program Wizard** enter the following **Package** and **Program Type** details:
- - Name: **Autopilot for existing devices config** - - Select the **This package contains source files** checkbox - - Source folder: Click **Browse** and specify a UNC path containing the AutopilotConfigurationFile.json file. - - Click **OK** and then click **Next**. - - Program Type: **Do not create a program** -4. Click **Next** twice and then click **Close**. - -**NOTE**: If you change user-driven Autopilot profile settings in Intune at a later date, you must also update the JSON file and redistribute the associated Configuration Manager package. - -### Create a target collection - ->[!NOTE] ->You can also choose to reuse an existing collection - -1. Navigate to **\Assets and Compliance\Overview\Device Collections** -2. On the ribbon, click **Create** and then click **Create Device Collection** -3. In the **Create Device Collection Wizard** enter the following **General** details: - - Name: **Autopilot for existing devices collection** - - Comment: (optional) - - Limiting collection: Click **Browse** and select **All Systems** - - >[!NOTE] - >You can optionally choose to use an alternative collection for the limiting collection. The device to be upgraded must be running the ConfigMgr agent in the collection that you select. - -4. Click **Next**, then enter the following **Membership Rules** details: - - Click **Add Rule** and specify either a direct or query based collection rule to add the target test Windows 7 devices to the new collection. - - For example, if the hostname of the computer to be wiped and reloaded is PC-01 and you wish to use Name as the attribute, click **Add Rule > Direct Rule > (wizard opens) > Next** and then enter **PC-01** next to **Value**. Click **Next**, and then choose **PC-01** under **Resources**. See the following examples. - - ![Named resource1](images/pc-01a.png) - ![Named resource2](images/pc-01b.png) - -5. Continue creating the device collection with the default settings: - - Use incremental updates for this collection: not selected - - Schedule a full update on this collection: default - - Click **Next** twice and then click **Close** - -### Create an Autopilot for existing devices Task Sequence - ->[!TIP] ->The next procedure requires a boot image for Windows 10 1803 or later. Review your available boot images in the Configuration Manager conole under **Software Library\Overview\Operating Systems\Boot images** and verify that the **OS Version** is 10.0.17134.1 (Windows 10 version 1803) or later. - -1. In the Configuration Manager console, navigate to **\Software Library\Overview\Operating Systems\Task Sequences** -2. On the Home ribbon, click **Create Task Sequence** -3. Select **Install an existing image package** and then click **Next** -4. In the Create Task Sequence Wizard enter the following details: - - Task sequence name: **Autopilot for existing devices** - - Boot Image: Click **Browse** and select a Windows 10 boot image (1803 or later) - - Click **Next**, and then on the Install Windows page click **Browse** and select a Windows 10 **Image package** and **Image Index**, version 1803 or later. - - Select the **Partition and format the target computer before installing the operating system** checkbox. - - Select or clear **Configure task sequence for use with BitLocker** checkbox. This is optional. - - Product Key and Server licensing mode: Optionally enter a product key and server licensing mode. - - Randomly generate the local administrator password and disable the account on all support platforms (recommended): Optional. - - Enable the account and specify the local administrator password: Optional. - - Click **Next**, and then on the Configure Network page choose **Join a workgroup** and specify a name (ex: workgroup) next to **Workgroup**. - - > [!IMPORTANT] - > The Autopilot for existing devices task sequence will run the **Prepare Windows for capture** action which uses the System Preparation Tool (sysprep). This action will fail if the target machine is joined to a domain. - - >[!IMPORTANT] - > The System Preparation Tool (sysprep) will run with the /Generalize parameter which, on Windows 10 versions 1903 and 1909, will delete the Autopilot profile file and the machine will boot into OOBE phase instead of Autopilot phase. To fix this issue, please see [Windows Autopilot - known issues](https://docs.microsoft.com/windows/deployment/windows-autopilot/known-issues). - -5. Click **Next**, and then click **Next** again to accept the default settings on the Install Configuration Manager page. -6. On the State Migration page, enter the following details: - - Clear the **Capture user settings and files** checkbox. - - Clear the **Capture network settings** checkbox. - - Clear the **Capture Microsoft Windows settings** checkbox. - - Click **Next**. - - >[!NOTE] - >Because the Autopilot for existing devices task sequence completes while in Windows PE, User State Migration Toolkit (USMT) data migration is not supported as there is no way to restore the user state into the new OS. Also, the User State Migration Toolkit (USMT) does not support Azure AD-joined devices. - -7. On the Include Updates page, choose one of the three available options. This selection is optional. -8. On the Install applications page, add applications if desired. This is optional. -9. Click **Next**, confirm settings, click **Next**, and then click **Close**. -10. Right click on the Autopilot for existing devices task sequence and click **Edit**. -11. In the Task Sequence Editor under the **Install Operating System** group, click the **Apply Windows Settings** action. -12. Click **Add** then click **New Group**. -13. Change the group **Name** from **New Group** to **Autopilot for existing devices config**. -14. Click **Add**, point to **General**, then click **Run Command Line**. -15. Verify that the **Run Command Line** step is nested under the **Autopilot for existing devices config** group. -16. Change the **Name** to **Apply Autopilot for existing devices config file** and paste the following into the **Command line** text box, and then click **Apply**: - ``` - cmd.exe /c xcopy AutopilotConfigurationFile.json %OSDTargetSystemDrive%\windows\provisioning\Autopilot\ /c - ``` - - **AutopilotConfigurationFile.json** must be the name of the JSON file present in the Autopilot for existing devices package created earlier. - -17. In the **Apply Autopilot for existing devices config file** step, select the **Package** checkbox and then click **Browse**. -18. Select the **Autopilot for existing devices config** package created earlier and click **OK**. An example is displayed at the end of this section. -19. Under the **Setup Operating System** group, click the **Setup Windows and Configuration Manager** task. -20. Click **Add** and then click **New Group**. -21. Change **Name** from **New Group** to **Prepare Device for Autopilot** -22. Verify that the **Prepare Device for Autopilot** group is the very last step in the task sequence. Use the **Move Down** button if necessary. -23. With the **Prepare device for Autopilot** group selected, click **Add**, point to **Images** and then click **Prepare ConfigMgr Client for Capture**. -24. Add a second step by clicking **Add**, pointing to **Images**, and clicking **Prepare Windows for Capture**. Use the following settings in this step: - - Automatically build mass storage driver list: **Not selected** - - Do not reset activation flag: **Not selected** - - Shut down the computer after running this action: **Optional** - - ![Autopilot task sequence](images/ap-ts-1.png) - -25. Click **OK** to close the Task Sequence Editor. - -> [!NOTE] -> On Windows 10 1903 and 1909, the **AutopilotConfigurationFile.json** is deleted by the **Prepare Windows for Capture** step. See [Windows Autopilot - known issues](https://docs.microsoft.com/windows/deployment/windows-autopilot/known-issues) for more information and a workaround. - -### Deploy Content to Distribution Points - -Next, ensure that all content required for the task sequence is deployed to distribution points. - -1. Right click on the **Autopilot for existing devices** task sequence and click **Distribute Content**. -2. Click **Next**, **Review the content to distribute**, and then click **Next**. -3. On the Specify the content distribution page click **Add** to specify either a **Distribution Point** or **Distribution Point Group**. -4. On the Add Distribution Points or Add Distribution Point Groups wizard specify content destinations that will allow the JSON file to be retrieved when the task sequence is run. -5. When you are finished specifying content distribution, click **Next** twice then click **Close**. - -### Deploy the OS with Autopilot Task Sequence - -1. Right click on the **Autopilot for existing devices** task sequence and then click **Deploy**. -2. In the Deploy Software Wizard enter the following **General** and **Deployment Settings** details: - - Task Sequence: **Autopilot for existing devices**. - - Collection: Click **Browse** and then select **Autopilot for existing devices collection** (or another collection you prefer). - - Click **Next** to specify **Deployment Settings**. - - Action: **Install**. - - Purpose: **Available**. You can optionally select **Required** instead of **Available**. This is not recommended during the test owing to the potential impact of inadvertent configurations. - - Make available to the following: **Only Configuration Manager Clients**. Note: Choose the option here that is relevant for the context of your test. If the target client does not have the Configuration Manager agent or Windows installed, you will need to select an option that includes PXE or Boot Media. - - Click **Next** to specify **Scheduling** details. - - Schedule when this deployment will become available: Optional - - Schedule when this deployment will expire: Optional - - Click **Next** to specify **User Experience** details. - - Show Task Sequence progress: Selected. - - Software Installation: Not selected. - - System restart (if required to complete the installation): Not selected. - - Commit changed at deadline or during a maintenance windows (requires restart): Optional. - - Allow task sequence to be run for client on the Internet: Optional - - Click **Next** to specify **Alerts** details. - - Create a deployment alert when the threshold is higher than the following: Optional. - - Click **Next** to specify **Distribution Points** details. - - Deployment options: **Download content locally when needed by the running task sequence**. - - When no local distribution point is available use a remote distribution point: Optional. - - Allow clients to use distribution points from the default site boundary group: Optional. - - Click **Next**, confirm settings, click **Next**, and then click **Close**. - -### Complete the client installation process - -1. Open the Software Center on the target Windows 7 or Windows 8.1 client computer. You can do this by clicking Start and then typing **software** in the search box, or by typing the following at a Windows PowerShell or command prompt: - - ``` - C:\Windows\CCM\SCClient.exe - ``` - -2. In the software library, select **Autopilot for existing devices** and click **Install**. See the following example: - - ![Named resource2](images/sc.png) - ![Named resource2](images/sc1.png) - -The Task Sequence will download content, reboot, format the drives and install Windows 10. The device will then proceed to be prepared for Autopilot. Once the task sequence has completed the device will boot into OOBE and provide an Autopilot experience. - -![refresh-1](images/up-1.png) -![refresh-2](images/up-2.png) -![refresh-3](images/up-3.png) - ->[!NOTE] ->If joining devices to Active Directory (Hybrid Azure AD Join), it is necessary to create a Domain Join device configuration profile that is targeted to "All Devices" (since there is no Azure Active Directory device object for the computer to do group-based targeting). See [User-driven mode for hybrid Azure Active Directory join](https://docs.microsoft.com/windows/deployment/windows-autopilot/user-driven#user-driven-mode-for-hybrid-azure-active-directory-join) for more information. - -### Register the device for Windows Autopilot - -Devices provisioned through Autopilot will only receive the guided OOBE Autopilot experience on first boot. Once updated to Windows 10, the device should be registered to ensure a continued Autopilot experience in the event of PC reset. You can enable automatic registration for an assigned group using the **Convert all targeted devices to Autopilot** setting. For more information, see [Create an Autopilot deployment profile](https://docs.microsoft.com/intune/enrollment-autopilot#create-an-autopilot-deployment-profile). - -Also see [Adding devices to Windows Autopilot](https://docs.microsoft.com/windows/deployment/windows-autopilot/add-devices). - -## Speeding up the deployment process - -To remove around 20 minutes from the deployment process, see Michael Niehaus's blog with instructions for [Speeding up Windows Autopilot for existing devices](https://blogs.technet.microsoft.com/mniehaus/2018/10/25/speeding-up-windows-autopilot-for-existing-devices/). diff --git a/windows/deployment/windows-autopilot/index.md b/windows/deployment/windows-autopilot/index.md deleted file mode 100644 index 93abebfa65..0000000000 --- a/windows/deployment/windows-autopilot/index.md +++ /dev/null @@ -1,78 +0,0 @@ ---- -title: Windows Autopilot deployment -description: Discover resources for Windows Autopilot deployment with this guide. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.reviewer: mniehaus -manager: laurawi -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Windows Autopilot deployment - -**Applies to** - -- Windows 10 - -Windows Autopilot is a zero-touch, self-service Windows deployment platform introduced with Windows 10, version 1703. The Windows Autopilot process runs immediately after powering on a new computer for the first time, enabling employees to configure new devices to be business-ready with just a few clicks. - -This guide is intended for use by an IT-specialist, system architect, or business decision maker. The guide provides information about how Windows Autopilot deployment works, including detailed requirements, deployment scenarios, and platform capabilities. The document highlights options that are available to you when planning a modern, cloud-joined Windows 10 deployment strategy. Links are provided to detailed step by step configuration procedures. - -## In this guide - - -
What's new Windows Autopilot is always being updated with new features! Check this topic to read about the latest capabilities. -
- -### Understanding Windows Autopilot - - -
Overview of Windows AutopilotA review of Windows Autopilot is provided with a video walkthrough. Benefits and general requirements are discussed. -
RequirementsDetailed software, network, licensing, and configuration requirements are provided. -
Scenarios and CapabilitiesA summary of Windows Autopilot deployment scenarios and capabilities. -
Get startedInterested in trying out Autopilot? See this step-by-step walkthrough to test Windows Autopilot on a virtual machine or physical device with a free 30-day trial premium Intune account. -
- -### Deployment scenarios - - -
User-driven modeRequirements and validation steps for deploying a new Azure Active Directory (AAD) joined or hybrid AAD-joined Windows 10 device are provided. -
Self-deploying modeRequirements and validation steps for deploying a new Windows 10 device with little to no user interaction are provided. -
Windows Autopilot ResetUsing Windows Autopilot Reset, a device can be restored to its original settings, taking it back to a business-ready state. Both local and remote reset scenarios are discussed. -
Windows Autopilot for white glove deploymentRequirements and procedures are described that enable additional policies and apps to be delivered to a Windows Autopilot device. -
Support for existing devicesThis topic describes how Windows Autopilot can be used to convert Windows 7 or Windows 8.1 domain-joined computers to AAD-joined computers running Windows 10. -
- -### Using Windows Autopilot - - -
Registering devicesThe process of registering a device with the Windows Autopilot deployment service is described. -
Configuring device profilesThe device profile settings that specific its behavior when it is deployed are described. -
Enrollment status pageSettings that are available on the Enrollment Status Page are described. -
BitLocker encryption Available options for configuring BitLocker on Windows Autopilot devices are described. -
DFCI management Manage UEFI settings using the Device Firmware Configuration Interface (DFCI) with Windows Autopilot and Intune. -
Troubleshooting Windows AutopilotDiagnostic event information and troubleshooting procedures are provided. -
Known issuesA list of current known issues and solutions is provided. -
- -### Support topics - - -
FAQFrequently asked questions on several topics are provided. -
Support contactsSupport information is provided. -
Registration authorizationThis article discusses how a CSP partner or OEM can obtain customer authorization to register Windows Autopilot devices. -
Motherboard replacementInformation about how to deal with Autopilot registration and device repair issues is provided. -
- -## Related topics - -[Windows Autopilot](https://www.microsoft.com/windowsforbusiness/windows-autopilot) diff --git a/windows/deployment/windows-autopilot/index.yml b/windows/deployment/windows-autopilot/index.yml new file mode 100644 index 0000000000..cb59230323 --- /dev/null +++ b/windows/deployment/windows-autopilot/index.yml @@ -0,0 +1,38 @@ +### YamlMime:Landing + +title: Windows Autopilot deployment resources and documentation # < 60 chars +summary: Learn about deploying Windows 10 with Autopilot. # < 160 chars + +metadata: + title: Windows Autopilot deployment resources and documentation # Required; page title displayed in search results. Include the brand. < 60 chars. + description: Learn about deploying Windows 10 and keeping it up to date in your organization. # Required; article description that is displayed in search results. < 160 chars. + services: windows-10 + ms.service: windows-10 #Required; service per approved list. service slug assigned to your service by ACOM. + ms.subservice: subservice + ms.topic: landing-page # Required + ms.collection: windows-10 + author: greg-lindsay #Required; your GitHub user alias, with correct capitalization. + ms.author: greglin #Required; microsoft alias of author; optional team alias. + ms.date: 08/05/2020 #Required; mm/dd/yyyy format. + localization_priority: medium + +# linkListType: architecture | concept | deploy | download | get-started | how-to-guide | learn | overview | quickstart | reference | tutorial | video | whats-new + +landingContent: +# Cards and links should be based on top customer tasks or top subjects +# Start card title with a verb + # Card + - title: Overview + linkLists: + - linkListType: overview + links: + - text: Overview of Windows Autopilot + url: https://docs.microsoft.com/mem/autopilot/windows-autopilot + + # Card + - title: Tutorials + linkLists: + - linkListType: get-started + links: + - text: Demonstrate Windows Autopilot deployment + url: demonstrate-deployment-on-vm.md \ No newline at end of file diff --git a/windows/deployment/windows-autopilot/known-issues.md b/windows/deployment/windows-autopilot/known-issues.md deleted file mode 100644 index 8dbec94be5..0000000000 --- a/windows/deployment/windows-autopilot/known-issues.md +++ /dev/null @@ -1,89 +0,0 @@ ---- -title: Windows Autopilot known issues -ms.reviewer: -manager: laurawi -description: Inform yourself about known issues that may occur during Windows Autopilot deployment. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Windows Autopilot - known issues - -**Applies to** - -- Windows 10 - - - - - - - - - - - - - - - - -
IssueMore information - -
Blocking apps specified in a user-targeted Enrollment Status Profile are ignored during device ESP.The services responsible for determining the list of apps that should be blocking during device ESP are not able to determine the correct ESP profile containing the list of apps because they do not know the user identity. As a workaround, enable the default ESP profile (which targets all users and devices) and place the blocking app list there. In the future, it will be possible to instead target the ESP profile to device groups to avoid this issue.
That username looks like it belongs to another organization. Try signing in again or start over with a different account.Confirm that all of your information is correct at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\Diagnostics\AutoPilot. See Troubleshooting Windows Auto Pilot for more details.
Windows Autopilot user-driven Hybrid Azure AD deployments do not grant users Administrator rights even when specified in the Windows Autopilot profile.This will occur when there is another user on the device that already has Administrator rights. For example, a PowerShell script or policy could create an additional local account that is a member of the Administrators group. To ensure this works properly, do not create an additional account until after the Windows Autopilot process has completed.
Windows Autopilot device provisioning can fail with TPM attestation errors or ESP timeouts on devices where the real-time clock is off by a significant amount of time (e.g. several minutes or more).To fix this issue:
  1. Boot the device to the start of the out-of-box experience (OOBE). -
  2. Establish a network connection (wired or wireless). -
  3. Run the command w32tm /resync /force to sync the time with the default time server (time.windows.com).
-
Windows Autopilot for existing devices does not work for Windows 10, version 1903 or 1909; you see screens that you've disabled in your Windows Autopilot profile, such as the Windows 10 License Agreement screen. -
 
-This happens because Windows 10, version 1903 and 1909 deletes the AutopilotConfigurationFile.json file. -		To fix this issue:
  1. Edit the Configuration Manager task sequence and disable the Prepare Windows for Capture step. -
  2. Add a new Run command line step that runs c:\windows\system32\sysprep\sysprep.exe /oobe /reboot.
-More information
TPM attestation fails on Windows 10 1903 due to missing AKI extension in EK certificate. (An additional validation added in Windows 10 1903 to check that the TPM EK certs had the proper attributes according to the TCG specifications uncovered that a number of them don’t, so that validation will be removed). -Download and install the KB4517211 update. -
The following known issues are resolved by installing the August 30, 2019 KB4512941 update (OS Build 18362.329): - -- Windows Autopilot for existing devices feature does not properly suppress “Activities” page during OOBE. (Because of this, you’ll see that extra page during OOBE). -- TPM attestation state is not cleared by sysprep /generalize, causing TPM attestation failure during later OOBE flow. (This isn’t a particularly common issue, but you could run into it while testing if you are running sysprep /generalize and then rebooting or reimaging the device to go back through an Autopilot white glove or self-deploying scenario). -- TPM attestation may fail if the device has a valid AIK cert but no EK cert. (This is related to the previous item). -- If TPM attestation fails during the Windows Autopilot white glove process, the landing page appears to be hung. (Basically, the white glove landing page, where you click “Provision” to start the white glove process, isn’t reporting errors properly). -- TPM attestation fails on newer Infineon TPMs (firmware version > 7.69). (Prior to this fix, only a specific list of firmware versions was accepted). -- Device naming templates may truncate the computer name at 14 characters instead of 15. -- Assigned Access policies cause a reboot which can interfere with the configuration of single-app kiosk devices. -Download and install the KB4512941 update.

See the section: How to get this update for information on specific release channels you can use to obtain the update. -
The following known issues are resolved by installing the July 26, 2019 KB4505903 update (OS Build 18362.267): - -- Windows Autopilot white glove does not work for a non-English OS and you see a red screen that says "Success." -- Windows Autopilot reports an AUTOPILOTUPDATE error during OOBE after sysprep, reset or other variations. This typically happens if you reset the OS or used a custom sysprepped image. -- BitLocker encryption is not correctly configured. Ex: BitLocker didn’t get an expected notification after policies were applied to begin encryption. -- You are unable to install UWP apps from the Microsoft Store, causing failures during Windows Autopilot. If you are deploying Company Portal as a blocking app during Windows Autopilot ESP, you’ve probably seen this error. -- A user is not granted administrator rights in the Windows Autopilot user-driven Hybrid Azure AD join scenario. This is another non-English OS issue. -Download and install the KB4505903 update.

See the section: How to get this update for information on specific release channels you can use to obtain the update. -
Windows Autopilot self-deploying mode fails with an error code: - -
0x800705B4This is a general error indicating a timeout. A common cause of this error in self-deploying mode is that the device is not TPM 2.0 capable (ex: a virtual machine). Devices that are not TPM 2.0 capable cannot be used with self-deploying mode. -
0x801c03eaThis error indicates that TPM attestation failed, causing a failure to join Azure Active Directory with a device token. -
0xc1036501The device cannot do an automatic MDM enrollment because there are multiple MDM configurations in Azure AD. See Inside Windows Autopilot self-deploying mode. -
-
White glove gives a red screen and the Microsoft-Windows-User Device Registration/Admin event log displays HResult error code 0x801C03F3This can happen if Azure AD can’t find an AAD device object for the device that you are trying to deploy. This will occur if you manually delete the object. To fix it, remove the device from AAD, Intune, and Autopilot, then re-register it with Autopilot, which will recreate the AAD device object.
-
To obtain troubleshooting logs use: Mdmdiagnosticstool.exe -area Autopilot;TPM -cab c:\autopilot.cab -
White glove gives a red screenWhite glove is not supported on a VM. -
Error importing Windows Autopilot devices from a .csv fileEnsure that you have not edited the .csv file in Microsoft Excel or an editor other than Notepad. Some of these editors can introduce extra characters causing the file format to be invalid. -
Windows Autopilot for existing devices does not follow the Autopilot OOBE experience.Ensure that the JSON profile file is saved in ANSI/ASCII format, not Unicode or UTF-8. -
Something went wrong is displayed page during OOBE.The client is likely unable to access all the required AAD/MSA-related URLs. For more information, see Networking requirements. -
Using a provisioning package in combination with Windows Autopilot can cause issues, especially if the PPKG contains join, enrollment, or device name information.Using PPKGs in combination with Windows Autopilot is not recommended. -
- -## Related topics - -[Diagnose MDM failures in Windows 10](https://docs.microsoft.com/windows/client-management/mdm/diagnose-mdm-failures-in-windows-10)
-[Troubleshooting Windows Autopilot](troubleshooting.md) diff --git a/windows/deployment/windows-autopilot/policy-conflicts.md b/windows/deployment/windows-autopilot/policy-conflicts.md deleted file mode 100644 index 3c4126ff73..0000000000 --- a/windows/deployment/windows-autopilot/policy-conflicts.md +++ /dev/null @@ -1,45 +0,0 @@ ---- -title: Windows Autopilot policy conflicts -ms.reviewer: -manager: laurawi -description: Inform yourself about known issues that may occur during Windows Autopilot deployment. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: mtniehaus -ms.author: mniehaus -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Windows Autopilot - Policy Conflicts - -**Applies to** - -- Windows 10 - -There are a significant number of policy settings available for Windows 10, both as native MDM policies and group policy (ADMX-backed) settings. Some of these can cause issues in certain Windows Autopilot scenarios as a result of how they change the behavior of Windows 10. If you encounter any of these issues, remove the policy in question to resolve the issue. - - - - - - - - - - - -
PolicyMore information - -
Device restriction / Password PolicyWhen certain DeviceLock policies, such as minimum password length and password complexity, or any similar group policy settings (including any that disable autologon) are applied to a device, and that device reboots during the device Enrollment Status Page (ESP), the out-of-box experience (OOBE) or user desktop autologon can fail unexpectantly. This is especially true for kiosk scenarios where passwords are automatically generated.
Windows 10 Security Baseline / Administrator elevation prompt behavior -
Windows 10 Security Baseline / Require admin approval mode for administrators		When modifying user account control (UAC) settings during the OOBE using the device Enrollment Status Page (ESP), additional UAC prompts may result, especially if the device reboots after these policies are applied, enabling them to take effect. To work around this issue, the policies can be targeted to users instead of devices so that they apply later in the process.
Device restrictions / Cloud and Storage / Microsoft Account sign-in assistantSetting this policy to "disabled" will disable the Microsoft Sign-in Assistant service (wlidsvc). This service is required by Windows Autopilot to obtain the Windows Autopilot profile.
- -## Related topics - -[Troubleshooting Windows Autopilot](troubleshooting.md) diff --git a/windows/deployment/windows-autopilot/profiles.md b/windows/deployment/windows-autopilot/profiles.md deleted file mode 100644 index 5cb74ed199..0000000000 --- a/windows/deployment/windows-autopilot/profiles.md +++ /dev/null @@ -1,49 +0,0 @@ ---- -title: Configure Autopilot profiles -description: Learn how to configure device profiles while performing a Windows Autopilot deployment. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.reviewer: mniehaus -manager: laurawi -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Configure Autopilot profiles - -**Applies to** - -- Windows 10 - -For each device that has been defined to the Windows Autopilot deployment service, a profile of settings needs to be applied that specifies the exact behavior of that device when it is deployed. For detailed procedures on how to configure profile settings and register devices, see [Registering devices](add-devices.md#registering-devices). - -## Profile settings - -The following profile settings are available: - -- **Skip Cortana, OneDrive and OEM registration setup pages**. All devices registered with Autopilot will automatically skip these pages during the out-of-box experience (OOBE) process. - -- **Automatically setup for work or school**. All devices registered with Autopilot will automatically be considered work or school devices, so this question will not be asked during the OOBE process. - -- **Sign in experience with company branding**. Instead of presenting a generic Azure Active Directory sign-in page, all devices registered with Autopilot will automatically present a customized sign-in page with the organization’s name, logon, and additional help text, as configured in Azure Active Directory. See [Add company branding to your directory](https://docs.microsoft.com/azure/active-directory/customize-branding#add-company-branding-to-your-directory) to customize these settings. - -- **Skip privacy settings**. This optional Autopilot profile setting enables organizations to not ask about privacy settings during the OOBE process. This is typically desirable so that the organization can configure these settings via Intune or other management tool. - -- **Disable local admin account creation on the device**. Organizations can decide whether the user setting up the device should have administrator access once the process is complete. - -- **Skip End User License Agreement (EULA)**. Starting in Windows 10 version 1709, organizations can decide to skip the EULA page presented during the OOBE process. This means that organizations accept the EULA terms on behalf of their users. - -- **Disable Windows consumer features**. Starting in Windows 10 version 1803, organizations can disable Windows consumer features so that the device does not automatically install any additional Microsoft Store apps when the user first signs into the device. See the [MDM documentation](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-experience#experience-allowwindowsconsumerfeatures) for more details. - -## Related topics - -[Profile download](troubleshooting.md#profile-download) -[Registering devices](add-devices.md) diff --git a/windows/deployment/windows-autopilot/registration-auth.md b/windows/deployment/windows-autopilot/registration-auth.md deleted file mode 100644 index 547b2f07ea..0000000000 --- a/windows/deployment/windows-autopilot/registration-auth.md +++ /dev/null @@ -1,94 +0,0 @@ ---- -title: Windows Autopilot customer consent -description: Learn how a cloud service provider (CSP) partner or an OEM can get customer authorization to register Windows Autopilot devices on the customer’s behalf. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.reviewer: mniehaus -manager: laurawi -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Windows Autopilot customer consent - -**Applies to: Windows 10** - -This article describes how a cloud service provider (CSP) partner (direct bill, indirect provider, or indirect reseller) or an OEM can get customer authorization to register Windows Autopilot devices on the customer’s behalf. - -## CSP authorization - -CSP partners can get customer authorization to register Windows Autopilot devices on the customer’s behalf per the following restrictions: - - -
Direct CSPGets direct authorization from the customer to register devices. -
Indirect CSP ProviderGets implicit permission to register devices through the relationship their CSP Reseller partner has with the customer. Indirect CSP Providers register devices through Microsoft Partner Center. -
Indirect CSP ResellerGets direct authorization from the customer to register devices. At the same time, their indirect CSP Provider partner also gets authorization, which mean that either the Indirect Provider or the Indirect Reseller can register devices for the customer. However, the Indirect CSP Reseller must register devices through the MPC UI (manually uploading CSV file), whereas the Indirect CSP Provider has the option to register devices using the MPC APIs. -
- -### Steps - -For a CSP to register Windows Autopilot devices on behalf of a customer, the customer must first grant that CSP partner permission using the following process: - -1. CSP sends link to customer requesting authorization/consent to register/manage devices on their behalf. To do so: - - CSP logs into Microsoft Partner Center - - Click **Dashboard** on the top menu - - Click **Customer** on the side menu - - Click the **Request a reseller relationship** link: - ![Request a reseller relationship](images/csp1.png) - - Select the checkbox indicating whether or not you want delegated admin rights: - ![Delegated rights](images/csp2.png) - - NOTE: Depending on your partner, they might request Delegated Admin Permissions (DAP) when requesting this consent. You should ask them to use the newer DAP-free process (shown in this document) if possible. If not, you can easily remove their DAP status either from Microsoft Admin Center or the Office 365 admin portal: https://docs.microsoft.com/partner-center/customers_revoke_admin_privileges - - Send the template above to the customer via email. -2. Customer with global administrator privileges in Microsoft Admin Center clicks the link in the body of the email once they receive it from the CSP, which takes them directly to the following Microsoft 365 admin center page: - - ![Global admin](images/csp3a.png) - - The image above is what the customer will see if they requested delegated admin rights (DAP). Note that the page says what Admin roles are being requested. If the customer did not request delegated admin rights they would see the following page: - - ![Global admin](images/csp3b.png) - - > [!NOTE] - > A user without global admin privileges who clicks the link will see a message similar to the following: - - ![Not global admin](images/csp4.png) - -3. Customer selects the **Yes** checkbox, followed by the **Accept** button. Authorization happens instantaneously. -4. The CSP will know that this consent/authorization request has been completed because the customer will show up in the CSP’s MPC account under their **customers** list, for example: - -![Customers](images/csp5.png) - -## OEM authorization - -Each OEM has a unique link to provide to their respective customers, which the OEM can request from Microsoft via msoemops@microsoft.com. - -1. OEM emails link to their customer. -2. Customer with global administrator privileges in Microsoft Store for Business (MSfB) clicks the link once they receive it from the OEM, which takes them directly to the following MSfB page: - - ![Global admin](images/csp6.png) - - > [!NOTE] - > A user without global admin privileges who clicks the link will see a message similar to the following: - - ![Not global admin](images/csp7.png) -3. Customer selects the **Yes** checkbox, followed by the **Accept** button, and they’re done. Authorization happens instantaneously. - - > [!NOTE] - > Once this process has completed, it is not currently possible for an administrator to remove an OEM. To remove an OEM or revoke - their permissions, send a request to msoemops@microsoft.com - -4. The OEM can use the Validate Device Submission Data API to verify the consent has completed. This API is discussed in the latest version of the API Whitepaper, p. 14ff [https://devicepartner.microsoft.com/assets/detail/windows-autopilot-integration-with-oem-api-design-whitepaper-docx](https://devicepartner.microsoft.com/assets/detail/windows-autopilot-integration-with-oem-api-design-whitepaper-docx). **Note**: this link is only accessible by Microsoft Device Partners. As discussed in this whitepaper, it’s a best practice recommendation for OEM partners to run the API check to confirm they’ve received customer consent before attempting to register devices, thus avoiding errors in the registration process. - - > [!NOTE] - > During the OEM authorization registration process, no delegated admin permissions are granted to the OEM. - -## Summary - -At this stage of the process, Microsoft is no longer involved; the consent exchange happens directly between the OEM and the customer. And, it all happens instantaneously - as quickly as buttons are clicked. diff --git a/windows/deployment/windows-autopilot/self-deploying.md b/windows/deployment/windows-autopilot/self-deploying.md deleted file mode 100644 index 4bdb15131d..0000000000 --- a/windows/deployment/windows-autopilot/self-deploying.md +++ /dev/null @@ -1,74 +0,0 @@ ---- -title: Windows Autopilot Self-Deploying mode -description: Self-deploying mode allows a device to be deployed with little to no user interaction. This mode mode is designed to deploy Windows 10 as a kiosk, digital signage device, or a shared device. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.reviewer: mniehaus -manager: laurawi -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - -# Windows Autopilot Self-Deploying mode - -**Applies to: Windows 10, version 1903 or later** - -Windows Autopilot self-deploying mode enables a device to be deployed with little to no user interaction. For devices with an Ethernet connection, no user interaction is required; for devices connected via Wi-fi, no interaction is required after making the Wi-fi connection (choosing the language, locale, and keyboard, then making a network connection). - -Self-deploying mode joins the device into Azure Active Directory, enrolls the device in Intune (or another MDM service) leveraging Azure AD for automatic MDM enrollment, and ensures that all policies, applications, certificates, and networking profiles are provisioned on the device, leveraging the enrollment status page to prevent access to the desktop until the device is fully provisioned. - ->[!NOTE] ->Self-deploying mode does not support Active Directory Join or Hybrid Azure AD Join. All devices will be joined to Azure Active Directory. - -Self-deploying mode is designed to deploy Windows 10 as a kiosk, digital signage device, or a shared device. When setting up a kiosk, you can leverage the new Kiosk Browser, an app built on Microsoft Edge that can be used to create a tailored, MDM-managed browsing experience. When combined with MDM policies to create a local account and configure it to automatically log on, the complete configuration of the device can be automated. Find out more about these options by reading simplifying kiosk management for IT with Windows 10. See [Set up a kiosk or digital sign in Intune or other MDM service](https://docs.microsoft.com/windows/configuration/setup-kiosk-digital-signage#set-up-a-kiosk-or-digital-sign-in-intune-or-other-mdm-service) for additional details. - ->[!NOTE] ->Self-deploying mode does not presently associate a user with the device (since no user ID or password is specified as part of the process). As a result, some Azure AD and Intune capabilities (such as BitLocker recovery, installation of apps from the Company Portal, or Conditional Access) may not be available to a user that signs into the device. For more information see [Windows Autopilot scenarios and capabilities](windows-autopilot-scenarios.md) and [Setting the BitLocker encryption algorithm for Autopilot devices](bitlocker.md). - -![The user experience with Windows Autopilot self-deploying mode](images/self-deploy-welcome.png) - -## Requirements - -Because self-deploying mode uses a device’s TPM 2.0 hardware to authenticate the device into an organization’s Azure AD tenant, devices without TPM 2.0 cannot be used with this mode. The devices must also support TPM device attestation. (All newly-manufactured Windows devices should meet these requirements.) - ->[!IMPORTANT] ->If you attempt a self-deploying mode deployment on a device that does not have support TPM 2.0 or on a virtual machine, the process will fail when verifying the device with an 0x800705B4 timeout error (Hyper-V virtual TPMs are not supported). Also note that Window 10, version 1903 or later is required to use self-deploying mode due to issues with TPM device attestation in Windows 10, version 1809. Since Windows 10 Enterprise 2019 LTSC is based on Windows 10 version 1809, self-deploying mode is also not supported on Windows 10 Enterprise 2019 LTSC. See [Windows Autopilot known issues](known-issues.md) to review other known errors and solutions. - -In order to display an organization-specific logo and organization name during the Autopilot process, Azure Active Directory Company Branding needs to be configured with the images and text that should be displayed. See [Quickstart: Add company branding to your sign-in page in Azure AD](https://docs.microsoft.com/azure/active-directory/fundamentals/customize-branding) for more details. - -## Step by step - -In order to perform a self-deploying mode deployment using Windows Autopilot, the following preparation steps need to be completed: - -- Create an Autopilot profile for self-deploying mode with the desired settings. In Microsoft Intune, this mode is explicitly chosen when creating the profile. (Note that it is not possible to create a profile in the Microsoft Store for Business or Partner Center for self-deploying mode.) -- If using Intune, create a device group in Azure Active Directory and assign the Autopilot profile to that group. Ensure that the profile has been assigned to the device before attempting to deploy that device. -- Boot the device, connecting it to Wi-fi if required, then wait for the provisioning process to complete. - -## Validation - -When performing a self-deploying mode deployment using Windows Autopilot, the following end-user experience should be observed: - -- Once connected to a network, the Autopilot profile will be downloaded. -- If the Autopilot profile has been configured to automatically configure the language, locale, and keyboard layout, these OOBE screens should be skipped as long as Ethernet connectivity is available. Otherwise, manual steps are required: - - If multiple languages are preinstalled in Windows 10, the user must pick a language. - - The user must pick a locale and a keyboard layout, and optionally a second keyboard layout. -- If connected via Ethernet, no network prompt is expected. If no Ethernet connection is available and Wi-fi is built in, the user needs to connect to a wireless network. -- Windows 10 will check for critical OOBE updates, and if any are available they will be automatically installed (rebooting if required). -- The device will join Azure Active Directory. -- After joining Azure Active Directory, the device will enroll in Intune (or other configured MDM services). -- The [enrollment status page](enrollment-status.md) will be displayed. -- Depending on the device settings deployed, the device will either: - - Remain at the logon screen, where any member of the organization can log on by specifying their Azure AD credentials. - - Automatically sign in as a local account, for devices configured as a kiosk or digital signage. - ->[!NOTE] ->Deploying EAS policies using self-deploying mode for kiosk deployments will cause auto-logon functionality to fail. - -In case the observed results do not match these expectations, consult the [Windows Autopilot Troubleshooting](troubleshooting.md) documentation. diff --git a/windows/deployment/windows-autopilot/troubleshooting.md b/windows/deployment/windows-autopilot/troubleshooting.md deleted file mode 100644 index ff194c99ab..0000000000 --- a/windows/deployment/windows-autopilot/troubleshooting.md +++ /dev/null @@ -1,164 +0,0 @@ ---- -title: Troubleshooting Windows Autopilot -description: Learn how to handle issues as they arise during the Windows Autopilot deployment process. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.reviewer: mniehaus -manager: laurawi -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Troubleshooting Windows Autopilot - -**Applies to: Windows 10** - -Windows Autopilot is designed to simplify all parts of the Windows device lifecycle, but there are always situations where issues may arise, either due to configuration or other issues. To assist with troubleshooting efforts, review the following information. - -## Troubleshooting process - -Whether you are performing user-driven or self-deploying device deployments, the troubleshooting process is about the same. It is always useful to understand the flow for a specific device: - -- A network connection is established. This can be a wireless (Wi-fi) or wired (Ethernet) connection. -- The Windows Autopilot profile is downloaded. Whether using a wired connection or manually establishing a wireless connection, the Windows Autopilot profile will be downloaded from the Autopilot deployment service as soon as the network connection is in place. -- User authentication occurs. When performing a user-driven deployment, the user will enter their Azure Active Directory credentials, which will be validated. -- Azure Active Directory join occurs. For user-driven deployments, the device will be joined to Azure AD using the specified user credentials. For self-deploying scenarios, the device will be joined without specifying any user credentials. -- Automatic MDM enrollment occurs. As part of the Azure AD join process, the device will enroll in the MDM service configured in Azure AD (for example, Microsoft Intune). -- Settings are applied. If the [enrollment status page](enrollment-status.md) is configured, most settings will be applied while the enrollment status page is displayed. If not configured or available, settings will be applied after the user is signed in. - -For troubleshooting, key activities to perform are: - -- Configuration: Has Azure Active Directory and Microsoft Intune (or an equivalent MDM service) been configured as specified in [Windows Autopilot configuration requirements](windows-autopilot-requirements.md)? -- Network connectivity: Can the device access the services described in [Windows Autopilot networking requirements](windows-autopilot-requirements.md)? -- Autopilot OOBE behavior: Were only the expected out-of-box experience screens displayed? Was the Azure AD credentials page customized with organization-specific details as expected? -- Azure AD join issues: Was the device able to join Azure Active Directory? -- MDM enrollment issues: Was the device able to enroll in Microsoft Intune (or an equivalent MDM service)? - -## Troubleshooting Autopilot Device Import - -### Clicking Import after selecting CSV does nothing, '400' error appears in network trace with error body **"Cannot convert the literal '[DEVICEHASH]' to the expected type 'Edm.Binary'"** - -This error points to the device hash being incorrectly formatted. This could be caused by anything that corrupts the collected hash, but one possibility is that the hash itself (even if it is completely valid) fails to be decoded. - -The device hash is Base64. At the device level, it's encoded as unpadded Base64, but Autopilot expects padded Base64. In most cases, it seems the payload lines up to not require padding, so the process works, but sometimes it doesn't line up cleanly and padding is necessary. This is when you get the error above. PowerShell's Base64 decoder also expects padded Base64, so we can use that to validate that the hash is properly padded. - -The "A" characters at the end of the hash are effectively empty data - Each character in Base64 is 6 bits, A in Base64 is 6 bits equal to 0. Deleting or adding **A**'s at the end doesn't change the actual payload data. - -To fix this, we'll need to modify the hash, then test the new value, until PowerShell succeeds in decoding the hash. The result is mostly illegible, this is fine - we're just looking for it to not throw the error "Invalid length for a Base-64 char array or string". - -To test the base64, you can use the following: -```powershell -[System.Text.Encoding]::ascii.getstring( [System.Convert]::FromBase64String("DEVICE HASH")) -``` - -So, as an example (this is not a device hash, but it's misaligned unpadded Base64 so it's good for testing): -```powershell -[System.Text.Encoding]::ascii.getstring( [System.Convert]::FromBase64String("Q29udG9zbwAAA")) -``` - -Now for the padding rules. The padding character is "=". The padding character can only be at the end of the hash, and there can only be a maximum of 2 padding characters. Here's the basic logic. - -- Does decoding the hash fail? - - Yes: Are the last two characters "="? - - Yes: Replace both "=" with a single "A" character, then try again - - No: Add another "=" character at the end, then try again - - No: That hash is valid - -Looping the logic above on the previous example hash, we get the following permutations: -- Q29udG9zbwAAA -- Q29udG9zbwAAA= -- Q29udG9zbwAAA== -- Q29udG9zbwAAAA -- Q29udG9zbwAAAA= -- **Q29udG9zbwAAAA==** (This one has valid padding) - -Replace the collected hash with this new padded hash then try to import again. - -## Troubleshooting Autopilot OOBE issues - -If the expected Autopilot behavior does not occur during the out-of-box experience (OOBE), it is useful to see whether the device received an Autopilot profile and what settings that profile contained. Depending on the Windows 10 release, there are different mechanisms available to do that. - -### Windows 10 version 1803 and above - -To see details related to the Autopilot profile settings and OOBE flow, Windows 10 version 1803 and above adds event log entries. These can be viewed using Event Viewer, navigating to the log at **Application and Services Logs –> Microsoft –> Windows –> Provisioning-Diagnostics-Provider –> Autopilot** for versions before 1903, or **Application and Services Logs –> Microsoft –> Windows –> ModernDeployment-Diagnostics-Provider –> Autopilot** for 1903 and above. The following events may be recorded, depending on the scenario and profile configuration. - -| Event ID | Type | Description | -|----------|------|-------------| -| 100 | Warning | “Autopilot policy [name] not found.” This is typically a temporary problem, while the device is waiting for an Autopilot profile to be downloaded. | -| 101 | Info | “AutopilotGetPolicyDwordByName succeeded: policy name = [setting name]; policy value [value].” This shows Autopilot retrieving and processing numeric OOBE settings. | -| 103 | Info | “AutopilotGetPolicyStringByName succeeded: policy name = [name]; value = [value].” This shows Autopilot retrieving and processing OOBE setting strings such as the Azure AD tenant name. | -| 109 | Info | “AutopilotGetOobeSettingsOverride succeeded: OOBE setting [setting name]; state = [state].” This shows Autopilot retrieving and processing state-related OOBE settings. | -| 111 | Info | “AutopilotRetrieveSettings succeeded.” This means that the settings stored in the Autopilot profile that control the OOBE behavior have been retrieved successfully. | -| 153 | Info | “AutopilotManager reported the state changed from [original state] to [new state].” Typically this should say “ProfileState_Unknown” to “ProfileState_Available” to show that a profile was available for the device and downloaded, so the device is ready to be deployed using Autopilot. | -| 160 | Info | “AutopilotRetrieveSettings beginning acquisition.” This shows that Autopilot is getting ready to download the needed Autopilot profile settings. | -| 161 | Info | “AutopilotManager retrieve settings succeeded.” The Autopilot profile was successfully downloaded. | -| 163 | Info | “AutopilotManager determined download is not required and the device is already provisioned. Clean or reset the device to change this.” This message indicates that an Autopilot profile is resident on the device; it typically would only be removed by the **Sysprep /Generalize** process. | -| 164 | Info | “AutopilotManager determined Internet is available to attempt policy download.” | -| 171 | Error | “AutopilotManager failed to set TPM identity confirmed. HRESULT=[error code].” This indicates an issue performing TPM attestation, needed to complete the self-deploying mode process. | -| 172 | Error | “AutopilotManager failed to set Autopilot profile as available. HRESULT=[error code].” This is typically related to event ID 171. | - -In addition to the event log entries, the registry and ETW trace options described below also work with Windows 10 version 1803 and above. - -### Windows 10 version 1709 and above - -On Windows 10 version 1709 and above, information about the Autopilot profile settings are stored in the registry on the device after they are received from the Autopilot deployment service. These can be found at **HKLM\SOFTWARE\Microsoft\Provisioning\Diagnostics\Autopilot**. Available registry entries include: - -| Value | Description | -|-------|-------------| -| AadTenantId | The GUID of the Azure AD tenant the user signed into. This should match the tenant that the device was registered with; if it does not match the user will receive an error. | -| CloudAssignedTenantDomain | The Azure AD tenant the device has been registered with, for example, “contosomn.onmicrosoft.com.” If the device is not registered with Autopilot, this value will be blank. | -| CloudAssignedTenantId | The GUID of the Azure AD tenant the device has been registered with (the GUID corresponds to the tenant domain from the CloudAssignedTenantDomain registry value). If the device isn’t registered with Autopilot, this value will be blank.| -| IsAutopilotDisabled | If set to 1, this indicates that the device is not registered with Autopilot. This could also indicate that the Autopilot profile could not be downloaded due to network connectivity or firewall issues, or network timeouts. | -| TenantMatched | This will be set to 1 if the tenant ID of the user matches the tenant ID that the device was registered with. If this is 0, the user would be shown an error and forced to start over. | -| CloudAssignedOobeConfig | This is a bitmap that shows which Autopilot settings were configured. Values include: SkipCortanaOptIn = 1, OobeUserNotLocalAdmin = 2, SkipExpressSettings = 4, SkipOemRegistration = 8, SkipEula = 16 | - -### Windows 10 semi-annual channel supported versions - -On devices running a [supported version](https://docs.microsoft.com/windows/release-information/) of Windows 10 semi-annual channel, ETW tracing can be used to capture detailed information from Autopilot and related components. The resulting ETW trace files can then be viewed using the Windows Performance Analyzer or similar tools. See [the advanced troubleshooting blog](https://blogs.technet.microsoft.com/mniehaus/2017/12/13/troubleshooting-windows-autopilot-level-300400/) for more information. - -## Troubleshooting Azure AD Join issues - -The most common issue joining a device to Azure AD is related to Azure AD permissions. Ensure [the correct configuration is in place](windows-autopilot-requirements.md) to allow users to join devices to Azure AD. Errors can also happen if the user has exceeded the number of devices that they are allowed to join, as configured in Azure AD. - -An Azure AD device is created upon import - it's important that this object is not deleted. It acts as Autopilot's anchor in AAD for group membership and targeting (including the profile) and can lead to join errors if it's deleted. Once this object has been deleted, to fix the issue, deleting and reimporting this autopilot hash will be necessary so it can recreate the associated object. - -Error code 801C0003 will typically be reported on an error page titled "Something went wrong". This error means that the Azure AD join failed. - -## Troubleshooting Intune enrollment issues - -See [this knowledge base article](https://support.microsoft.com/help/4089533/troubleshooting-windows-device-enrollment-problems-in-microsoft-intune) for assistance with Intune enrollment issues. Common issues include incorrect or missing licenses assigned to the user or too many devices enrolled for the user. - -Error code 80180018 will typically be reported on an error page titled "Something went wrong". This error means that the MDM enrollment failed. - -If Autopilot Reset fails immediately with an error **Ran into trouble. Please sign in with an administrator account to see why and reset manually**, see [Troubleshoot Autopilot Reset](https://docs.microsoft.com/education/windows/autopilot-reset#troubleshoot-autopilot-reset) for more help. - -## Profile download - -When an Internet-connected Windows 10 device boots up, it will attempt to connect to the Autopilot service and download an Autopilot profile. Note: It is important that a profile exists at this stage so that a blank profile is not cached locally on the PC. To remove the currently cached local profile in Windows 10 version 1803 and earlier, it is necessary to re-generalize the OS using **sysprep /generalize /oobe**, reinstall the OS, or re-image the PC. In Windows 10 version 1809 and later, you can retrieve a new profile by rebooting the PC. - -When a profile is downloaded depends upon the version of Windows 10 that is running on the PC. See the following table. - -| Windows 10 version | Profile download behavior | -| --- | --- | -| 1709 | The profile is downloaded after the OOBE network connection page. This page is not displayed when using a wired connection. In this case, the profile is downloaded just prior to the EULA screen. | -| 1803 | The profile is downloaded as soon as possible. If wired, it is downloaded at the start of OOBE. If wireless, it is downloaded after the network connection page. | -| 1809 | The profile is downloaded as soon as possible (same as 1803), and again after each reboot. | - -If you need to reboot a computer during OOBE: -- Press Shift-F10 to open a command prompt. -- Enter **shutdown /r /t 0** to restart immediately, or **shutdown /s /t 0** to shutdown immediately. - -For more information, see [Windows Setup Command-Line Options](https://docs.microsoft.com/windows-hardware/manufacture/desktop/windows-setup-command-line-options). - -## Related topics - -[Windows Autopilot - known issues](known-issues.md)
-[Diagnose MDM failures in Windows 10](https://docs.microsoft.com/windows/client-management/mdm/diagnose-mdm-failures-in-windows-10)
diff --git a/windows/deployment/windows-autopilot/user-driven.md b/windows/deployment/windows-autopilot/user-driven.md deleted file mode 100644 index 2f93c58513..0000000000 --- a/windows/deployment/windows-autopilot/user-driven.md +++ /dev/null @@ -1,148 +0,0 @@ ---- -title: Windows Autopilot User-Driven Mode -description: Windows Autopilot user-driven mode allows devices to be deployed to a ready-to-use state without requiring help from IT personnel. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.reviewer: mniehaus -manager: laurawi -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Windows Autopilot user-driven mode - -Windows Autopilot user-driven mode is designed to enable new Windows 10 devices to be transformed from their initial state, directly from the factory, into a ready-to-use state without requiring that IT personnel ever touch the device. The process is designed to be simple so that anyone can complete it, enabling devices to be shipped or distributed to the end user directly with simple instructions: - -- Unbox the device, plug it in, and turn it on. -- Choose a language (only required when multiple languages are installed), locale and keyboard. -- Connect it to a wireless or wired network with internet access. If using wireless, the user must establish the Wi-Fi link. -- Specify your e-mail address and password for your organization account. - -After completing those simple steps, the remainder of the process is completely automated, with the device being joined to the organization, enrolled in Intune (or another MDM service), and fully configured as defined by the organization. Any additional prompts during the Out-of-Box Experience (OOBE) can be suppressed; see [Configuring Autopilot Profiles](profiles.md) for options that are available. - -Windows Autopilot user-driven mode supports Azure Active Directory and Hybrid Azure Active Directory joined devices. See [What is a device identity](https://docs.microsoft.com/azure/active-directory/devices/overview) for more information about these two join options. - -From a process flow perspective, the tasks performed during the user-driven process are as follows: - -- Once connected to a network, the device will download a Windows Autopilot profile specifying the settings that should be used (e.g. the prompts during OOBE that should be suppressed). -- Windows 10 will check for critical OOBE updates, and if any are available they will be automatically installed (rebooting if required). -- The user will be prompted for Azure Active Directory credentials, with a customized user experience showing the Azure AD tenant name, logo, and sign-in text. -- The device will join Azure Active Directory or Active Directory, based on the Windows Autopilot profile settings. -- The device will enroll in Intune (or other configured MDM services). (This occurs as part of the Azure Active Directory join process via MDM auto-enrollment, or before the Active Directory join process, as needed.) -- If configured, the [enrollment status page](enrollment-status.md) (ESP) will be displayed. -- Once the device configuration tasks have completed, the user will be signed into Windows 10 using the credentials they previously provided. (Note that if the device reboots during the device ESP process, the user will need to re-enter their credentials as these are not persisted across reboots.) -- Once signed in, the enrollment status page will again be displayed for user-targeted configuration tasks. - -If any issues are encountered during this process, see the [Windows Autopilot Troubleshooting](troubleshooting.md) documentation. - -For more information on the available join options, see the following sections: - -- [Azure Active Directory join](#user-driven-mode-for-azure-active-directory-join) is available if devices do not need to be joined to an on-prem Active Directory domain. -- [Hybrid Azure Active Directory join](#user-driven-mode-for-hybrid-azure-active-directory-join) is available for devices that must be joined to both Azure Active Directory and your on-prem Active Directory domain. -- [Hybrid Azure Active Directory join with VPN support](#user-driven-mode-for-hybrid-azure-active-directory-join-with-vpn-support) is available for devices that must be joined to both Azure Active Directory and your on-prem Active Directory domain, but are not connected to the corporate network and must use VPN connectivity. - -## User-driven mode for Azure Active Directory join - -In order to perform a user-driven deployment using Windows Autopilot, the following preparation steps need to be completed: - -- Ensure that the users who will be performing user-driven mode deployments are able to join devices to Azure Active Directory. See [Configure device settings](https://docs.microsoft.com/azure/active-directory/device-management-azure-portal#configure-device-settings) in the Azure Active Directory documentation for more information. -- Create an Autopilot profile for user-driven mode with the desired settings. In Microsoft Intune, this mode is explicitly chosen when creating the profile. With Microsoft Store for Business and Partner Center, user-driven mode is the default and does not need to be selected. -- If using Intune, create a device group in Azure Active Directory and assign the Autopilot profile to that group. - -For each device that will be deployed using user-driven deployment, these additional steps are needed: - -- Ensure that the device has been added to Windows Autopilot. This can be done automatically by an OEM or partner at the time the device is purchased, or it can be done through a manual harvesting process later. See [Adding devices to Windows Autopilot](add-devices.md) for more information. -- Ensure an Autopilot profile has been assigned to the device: - - If using Intune and Azure Active Directory dynamic device groups, this can be done automatically. - - If using Intune and Azure Active Directory static device groups, manually add the device to the device group. - - If using other methods (e.g. Microsoft Store for Business or Partner Center), manually assign an Autopilot profile to the device. - - -## User-driven mode for hybrid Azure Active Directory join - -Windows Autopilot requires that devices be Azure Active Directory joined. If you have an on-premises Active Directory environment and want to also join devices to your on-premises domain, you can accomplish this by configuring Autopilot devices to be [hybrid-joined to Azure Active Directory (Azure AD)](https://docs.microsoft.com/azure/active-directory/devices/hybrid-azuread-join-plan). - -### Requirements - -To perform a user-driven hybrid Azure AD joined deployment using Windows Autopilot: - -- A Windows Autopilot profile for user-driven mode must be created and - - **Hybrid Azure AD joined** must be specified as the selected option under **Join to Azure AD as** in the Autopilot profile. -- If using Intune, a device group in Azure Active Directory must exist with the Windows Autopilot profile assigned to that group. -- The device must be running Windows 10, version 1809 or later. -- The device must be able to access an Active Directory domain controller, so it must be connected to the organization's network (where it can resolve the DNS records for the AD domain and the AD domain controller, and communicate with the domain controller to authenticate the user). -- The device must be able to access the Internet, following the [documented Windows Autopilot network requirements](windows-autopilot-requirements.md). -- The Intune Connector for Active Directory must be installed. - - Note: The Intune Connector will perform an on-prem AD join, therefore users do not need on-prem AD-join permission, assuming the Connector is [configured to perform this action](https://docs.microsoft.com/intune/windows-autopilot-hybrid#increase-the-computer-account-limit-in-the-organizational-unit) on the user's behalf. -- If using Proxy, WPAD Proxy settings option must be enabled and configured. - -The hybrid Azure AD join process uses the system context to register the device to Azure AD, therefore it is not affected by user based Azure AD join permission settings. - -## User-driven mode for hybrid Azure Active Directory join with VPN support - -Devices that are joined to Active Directory require connectivity to an Active Directory domain controller for a variety of activities, such as user sign-in (validating the user's credentials) and Group Policy application. As a result, the Windows Autopilot user-driven Hybrid Azure AD Join process would validate that the device is able to contact an Active Directory domain controller by pinging that domain controller. - -With the additional of VPN support for this scenario, it is now possible for you to specify to skip that connectivity check during the Hybrid Azure AD Join. This does not eliminate the need for communicating with an Active Directory domain controller, but rather enables the device to be first prepared with a needed VPN configuration delivered via Intune prior to the user attempting to sign into Windows, allowing connectivity to the organization's network. - -### Requirements - -The following additional requirements apply for Hybrid Azure AD Join with VPN support: - -- A supported version of Windows 10: - - Windows 10 1903 + December 10th Cumulative update (KB4530684, OS build 18362.535) or higher - - Windows 10 1909 + December 10th Cumulative update (KB4530684, OS build 18363.535) or higher - - Windows 10 2004 or later -- Enable the new “Skip domain connectivity check” toggle in the Hybrid Azure AD Join Autopilot profile. -- A VPN configuration that can be deployed via Intune that enables the user to manually establish a VPN connection from the Windows logon screen, or one that automatically establishes a VPN connection as needed. - -The specific VPN configuration required depends on the VPN software and authentication being used. For third-party (non-Microsoft) VPN solutions, this typically would involve deploying a Win32 app (containing the VPN client software itself as well as any specific connection information, e.g. VPN endpoint host names) via Intune Management Extensions. Consult your VPN provider's documentation for configuration details specific to that provider. - -> [!NOTE] -> The VPN requirements are not specific to Windows Autopilot. For example, if you have already implemented a VPN configuration to enable remote password resets, where a user needs to log on to Windows with a new password when not on the organization's network, that same configuration can be used with Windows Autopilot. Once the user has signed in to cache their credentials, subsequent log-on attempts do not need connectivity since the cached credentials can be used. - -In cases where certificate authentication is required by the VPN software, the needed machine certificate should also be deployed via Intune. This can be done using the Intune certificate enrollment capabilities, targeting the certificate profiles to the device. - -Note that user certificates are not supported because these certificates cannot be deployed until the user logs in. Also, third-party UWP VPN plug-ins delivered from the Windows Store are also not supported because these are not installed until after the user signs in. - -### Validation - -Before attempting a hybrid Azure AD Join using VPN, it is important to first confirm that a user-driven Hybrid Azure AD Join process can be performed on the organization's network, before adding in the additional requirements described below. This simplifies troubleshooting by making sure the core process works fine before adding the additional VPN configuration required. - -Next, validate that the VPN configuration (Win32 app, certs, and any other requirements) can be deployed via Intune to an existing device that has already been hybrid Azure AD joined. For example, some VPN clients create a per-machine VPN connection as part of the installation process, so you can validate the configuration using steps such as these: - -- From PowerShell, verify that at least one per-machine VPN connection has been created using the "Get-VpnConnection -AllUserConnection" command. -- Attempt to manually start the VPN connection using the command: RASDIAL.EXE "ConnectionName" -- Log out and verify that the "VPN connection" icon can be seen on the Windows logon page. -- Move the device off the corporate network and attempt to establish the connection using the icon on the Windows logon page, signing into an account that does not have cached credentials. - -For VPN configurations that automatically connect, the validation steps may be different. - -> [!NOTE] -> Always On VPN can be used for this scenario. See the [Deploy Always On VPN](https://docs.microsoft.com/windows-server/remote/remote-access/vpn/always-on-vpn/deploy/always-on-vpn-deploy-deployment) documentation for more information. Note that Intune cannot yet deploy the needed per-machine VPN profile. - -To validate the end-to-end process, ensure the needed Windows 10 cumulative update has been installed on Windows 10 1903 or Windows 10 1909. This can be done manually during OOBE by first downloading the latest cumulative from https://catalog.update.microsoft.com and then manually installing it: - -- Press Shift-F10 to open a command prompt. -- Insert a USB key containing the downloaded update. -- Install the update using the command (substituting the real file name): WUSA.EXE .msu /quiet -- Reboot the computer using the command: shutdown.exe /r /t 0 - -Alternatively, you can invoke Windows Update to install the latest updates through this process: - -- Press Shift-F10 to open a command prompt. -- Run the command "start ms-settings:" -- Navigate to the "Update & Security" node and check for updates. -- Reboot after the updates are installed. - -## Step by step instructions - -See [Deploy hybrid Azure AD joined devices using Intune and Windows Autopilot](https://docs.microsoft.com/intune/windows-autopilot-hybrid). - diff --git a/windows/deployment/windows-autopilot/white-glove.md b/windows/deployment/windows-autopilot/white-glove.md deleted file mode 100644 index 2945f04f62..0000000000 --- a/windows/deployment/windows-autopilot/white-glove.md +++ /dev/null @@ -1,120 +0,0 @@ ---- -title: Windows Autopilot for white glove deployment -description: Windows Autopilot for white glove deployment -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune, pre-provisioning -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: low -ms.sitesec: library -ms.pagetype: deploy -audience: itproF -author: greg-lindsay -manager: laurawi -ms.audience: itpro -author: greg-lindsay -ms.collection: M365-modern-desktop -ms.topic: article ---- - -# Windows Autopilot for white glove deployment - -**Applies to: Windows 10, version 1903** - -Windows Autopilot enables organizations to easily provision new devices - leveraging the preinstalled OEM image and drivers with a simple process that can be performed by the end user to help get their device business-ready. - - ![OEM](images/wg01.png) - -Windows Autopilot can also provide a white glove service that enables partners or IT staff to pre-provision a Windows 10 PC so that it is fully configured and business-ready. From the end user’s perspective, the Windows Autopilot user-driven experience is unchanged, but getting their device to a fully provisioned state is faster. - -With **Windows Autopilot for white glove deployment**, the provisioning process is split. The time-consuming portions are performed by IT, partners, or OEMs. The end user simply completes a few necessary settings and polices and then they can begin using their device. - - ![OEM](images/wg02.png) - -Enabled with Microsoft Intune in Windows 10, version 1903 and later, white glove deployment capabilities build on top of existing Windows Autopilot [user-driven scenarios](user-driven.md), supporting both the user-driven mode for Azure Active Directory Join, and user-driven mode for Hybrid Azure Active Directory join scenarios. - -## Prerequisites - -In addition to [Windows Autopilot requirements](windows-autopilot-requirements.md), Windows Autopilot for white glove deployment adds the following: - -- Windows 10, version 1903 or later is required. -- An Intune subscription. -- Physical devices that support TPM 2.0 and device attestation; virtual machines are not supported. The white glove provisioning process leverages Windows Autopilot self-deploying capabilities, hence the TPM 2.0 requirements. -- Physical devices with Ethernet connectivity; Wi-fi connectivity is not supported due to the requirement to choose a language, locale, and keyboard to make that Wi-fi connection; doing that in a pre-provisioning process could prevent the user from choosing their own language, locale, and keyboard when they receive the device. - ->[!IMPORTANT] ->Because the OEM or vendor performs the white glove process, this doesn’t require access to an end-user's on-prem domain infrastructure. This is unlike a typical hybrid Azure AD-joined scenario because rebooting the device is postponed. The device is resealed prior to the time when connectivity to a domain controller is expected, and the domain network is contacted when the device is unboxed on-prem by the end-user. - -## Preparation - -Devices slated for white glove provisioning are registered for Autopilot via the normal registration process. - -To be ready to try out Windows Autopilot for white glove deployment, ensure that you can first successfully use existing Windows Autopilot user-driven scenarios: - -- User-driven Azure AD join. Devices can be deployed using Windows Autopilot and joined to an Azure Active Directory tenant. -- User-driven with Hybrid Azure AD join. Devices can be deployed using Windows Autopilot and joined to an on-premises Active Directory domain, then registered with Azure Active Directory to enable the Hybrid Azure AD join features. - -If these scenarios cannot be completed, Windows Autopilot for white glove deployment will also not succeed since it builds on top of these scenarios. - -To enable white glove deployment, an additional Autopilot profile setting must be configured by the customer or IT Admin via their Intune account, prior to beginning the white glove process in the provisioning service facility: - -![allow white glove](images/allow-white-glove-oobe.png) - -The Windows Autopilot for white glove deployment pre-provisioning process will apply all device-targeted policies from Intune. That includes certificates, security templates, settings, apps, and more – anything targeting the device. Additionally, any apps (Win32 or LOB) that are configured to install in the device context and targeted to the user that has been pre-assigned to the Autopilot device will also be installed. Please make sure not to target both win32 and LOB apps to the same device, as this can make troubleshooting difficult if there are app installation failures. For more information, see [Add a Windows line-of-business app to Microsoft Intune](https://docs.microsoft.com/mem/intune/apps/lob-apps-windows). - -> [!NOTE] -> Select the language mode as the user specified in Autopilot profiles to ensure easy access into white glove provisioning mode. -> The white glove technician phase will install all device-targeted apps as well as any user-targeted, device-context apps that are targeted to the assigned user. If there is no assigned user, then it will only install the device-targeted apps. Other user-targeted policies will not apply until the user signs into the device. To verify these behaviors, be sure to create appropriate apps and policies targeted to devices and users. - -## Scenarios - -Windows Autopilot for white glove deployment supports two distinct scenarios: -- User-driven deployments with Azure AD Join. The device will be joined to an Azure AD tenant. -- User-driven deployments with Hybrid Azure AD Join. The device will be joined to an on-premises Active Directory domain, and separately registered with Azure AD. -Each of these scenarios consists of two parts, a technician flow and a user flow. At a high level, these parts are the same for Azure AD Join and Hybrid Azure AD join; differences are primarily seen by the end user in the authentication steps. - -### Technician flow - -After the customer or IT Admin has targeted all the apps and settings they want for their devices through Intune, the white glove technician can begin the white glove process. The technician could be a member of the IT staff, a services partner, or an OEM – each organization can decide who should perform these activities. Regardless of the scenario, the process to be performed by the technician is the same: -- Boot the device (running Windows 10 Pro, Enterprise, or Education SKUs, version 1903 or later). -- From the first OOBE screen (which could be a language selection or locale selection screen), do not click **Next**. Instead, press the Windows key five times to view an additional options dialog. From that screen, choose the **Windows Autopilot provisioning** option and then click **Continue**. - - ![choice](images/choice.png) - -- On the **Windows Autopilot Configuration** screen, information will be displayed about the device: - - The Autopilot profile assigned to the device. - - The organization name for the device. - - The user assigned to the device (if there is one). - - A QR code containing a unique identifier for the device, useful to look up the device in Intune to make any configuration changes needed (e.g. assigning a user, adding the device to any additional groups needed for app or policy targeting). - - **Note**: The QR codes can be scanned using a companion app, which will also configure the device to specify who it belongs to. An [open-source sample of the companion app](https://github.com/Microsoft/WindowsAutopilotCompanion) that integrates with Intune via the Graph API has been published to GitHub by the Autopilot team. -- Validate the information displayed. If any changes are needed, make these and then click **Refresh** to re-download the updated Autopilot profile details. - - ![landing](images/landing.png) - -- Click **Provision** to begin the provisioning process. - -If the pre-provisioning process completes successfully: -- A green status screen will be displayed with information about the device, including the same details presented previously (e.g. Autopilot profile, organization name, assigned user, QR code), as well as the elapsed time for the pre-provisioning steps. - ![white-glove-result](images/white-glove-result.png) -- Click **Reseal** to shut the device down. At that point, the device can be shipped to the end user. - ->[!NOTE] ->Technician Flow inherits behavior from [Self-Deploying Mode](self-deploying.md). Per the Self-Deploying Mode documentation, it leverages the Enrollment Status Page to hold the device in a provisioning state and prevent the user from proceeding to the desktop after enrollment but before software and configuration is done applying. As such, if Enrollment Status Page is disabled, the reseal button may appear before software and configuration is done applying letting you proceed to the user flow before technician flow provisioning is complete. The green screen validates that enrollment was successful, not that the technician flow is necessarily complete. - -If the pre-provisioning process fails: -- A red status screen will be displayed with information about the device, including the same details presented previously (e.g. Autopilot profile, organization name, assigned user, QR code), as well as the elapsed time for the pre-provisioning steps. -- Diagnostic logs can be gathered from the device, and then it can be reset to start the process over again. - -### User flow - -If the pre-provisioning process completed successfully and the device was resealed, it can be delivered to the end user to complete the normal Windows Autopilot user-driven process. They will perform a standard set of steps: - -- Power on the device. -- Select the appropriate language, locale, and keyboard layout. -- Connect to a network (if using Wi-Fi). Internet access is always required. If using Hybrid Azure AD Join, there must also be connectivity to a domain controller. -- On the branded sign-on screen, enter the user’s Azure Active Directory credentials. -- If using Hybrid Azure AD Join, the device will reboot; after the reboot, enter the user’s Active Directory credentials. -- Additional policies and apps will be delivered to the device, as tracked by the Enrollment Status Page (ESP). Once complete, the user will be able to access the desktop. - -## Related topics - -[White glove video](https://youtu.be/nE5XSOBV0rI) diff --git a/windows/deployment/windows-autopilot/windows-autopilot-requirements.md b/windows/deployment/windows-autopilot/windows-autopilot-requirements.md deleted file mode 100644 index c1ce8c7759..0000000000 --- a/windows/deployment/windows-autopilot/windows-autopilot-requirements.md +++ /dev/null @@ -1,145 +0,0 @@ ---- -title: Windows Autopilot requirements -ms.reviewer: -manager: laurawi -description: See the requirements you need to run Windows Autopilot in Windows 10, Azure Active Directory, and MDM services such as Microsoft Intune. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, Autopilot, ztd, zero-touch, partner, msfb, intune -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article -ms.custom: -- CI 116757 -- CSSTroubleshooting ---- - - -# Windows Autopilot requirements - -**Applies to: Windows 10** - -Windows Autopilot depends on specific capabilities available in Windows 10, Azure Active Directory, and MDM services such as Microsoft Intune. In order to use Windows Autopilot and leverage these capabilities, some requirements must be met. - -> [!NOTE] -> For a list of OEMs that currently support Windows Autopilot, see the Participant device manufacturers section at [Windows Autopilot](https://aka.ms/windowsAutopilot). - -## Software requirements - -- A [supported version](https://docs.microsoft.com/windows/release-information/) of Windows 10 Semi-Annual Channel is required. Windows 10 Enterprise 2019 long-term servicing channel (LTSC) is also supported. -- The following editions are supported: - - Windows 10 Pro - - Windows 10 Pro Education - - Windows 10 Pro for Workstations - - Windows 10 Enterprise - - Windows 10 Education - - Windows 10 Enterprise 2019 LTSC - ->[!NOTE] ->Procedures for deploying Windows Autopilot might refer to specific products and versions. The inclusion of these products in this content doesn't imply an extension of support for a version that is beyond its support lifecycle. Windows Autopilot does not support products that are beyond their support lifecycle. For more information, see [Microsoft Lifecycle Policy](https://go.microsoft.com/fwlink/p/?LinkId=208270). - -## Networking requirements - -Windows Autopilot depends on a variety of internet-based services. Access to these services must be provided for Autopilot to function properly. In the simplest case, enabling proper functionality can be achieved by ensuring the following: - -- Ensure DNS name resolution for internet DNS names. -- Allow access to all hosts via port 80 (HTTP), 443 (HTTPS), and 123 (UDP/NTP). - -In environments that have more restrictive Internet access, or for those that require authentication before internet access can be obtained, additional configuration may be required to allow access to the required services. - -> [!NOTE] -> Smart card and certificate based authentication is not supported during OOBE. For more information, see [Smartcards and certificate-based authentication](https://docs.microsoft.com/azure/active-directory/devices/azureadjoin-plan#smartcards-and-certificate-based-authentication). - -For additional details about each of these services and their specific requirements, review the following details: - -
ServiceInformation -
Windows Autopilot Deployment ServiceAfter a network connection is in place, each Windows 10 device will contact the Windows Autopilot Deployment Service. With Windows 10 version 1903 and above, the following URLs are used: https://ztd.dds.microsoft.com, https://cs.dds.microsoft.com.
- -
Windows ActivationWindows Autopilot also requires Windows Activation services. See Windows activation or validation fails with error code 0x8004FE33 for details about the URLs that need to be accessible for the activation services.
- -
Azure Active DirectoryUser credentials are validated by Azure Active Directory, and the device can also be joined to Azure Active Directory. See Office 365 IP Address and URL Web service for more information. -
IntuneOnce authenticated, Azure Active Directory will trigger enrollment of the device into the Intune MDM service. See the following link for details about network communication requirements: Intune network configuration requirements and bandwidth. -
Windows UpdateDuring the OOBE process, as well as after the Windows 10 OS is fully configured, the Windows Update service is leveraged to retrieve needed updates. If there are problems connecting to Windows Update, see How to solve connection problems concerning Windows Update or Microsoft Update.
- -If Windows Update is inaccessible, the Autopilot process will still continue but critical updates will not be available. - -
Delivery OptimizationWhen downloading Windows Updates, Microsoft Store apps and app updates, Office Updates and Intune Win32 Apps, the Delivery Optimization service is contacted to enable peer-to-peer sharing of content so that only a few devices need to download it from the internet.
- -If the Delivery Optimization Service is inaccessible, the Autopilot process will still continue with Delivery Optimization downloads from the cloud (without peer-to-peer). - -
Network Time Protocol (NTP) SyncWhen a Windows device starts up, it will talk to a network time server to ensure that the time on the device is accurate. Ensure that UDP port 123 to time.windows.com is accessible. -
Domain Name Services (DNS)To resolve DNS names for all services, the device communicates with a DNS server, typically provided via DHCP.  This DNS server must be able to resolve internet names. -
Diagnostics dataStarting in Windows 10, 1903, diagnostic data collection will be enabled by default. To disable Windows Analytics and related diagnostics capabilities, see Manage enterprise diagnostic data level.
- -If diagnostic data cannot be sent, the Autopilot process will still continue, but services that depend on diagnostic data, such as Windows Analytics, will not work. -
Network Connection Status Indicator (NCSI)Windows must be able to tell that the device is able to access the internet. For more information, see Network Connection Status Indicator (NCSI). - -www.msftconnecttest.com must be resolvable via DNS and accessible via HTTP. -
Windows Notification Services (WNS)This service is used to enable Windows to receive notifications from apps and services. See Microsoft Store for more information.
- -If the WNS services are not available, the Autopilot process will still continue without notifications. -
Microsoft Store, Microsoft Store for BusinessApps in the Microsoft Store can be pushed to the device, triggered via Intune (MDM).  App updates and additional apps may also be needed when the user first logs in. For more information, see Prerequisites for Microsoft Store for Business and Education (also includes Azure AD and Windows Notification Services).
- -If the Microsoft Store is not accessible, the Autopilot process will still continue without Microsoft Store apps. - -
Office 365As part of the Intune device configuration, installation of Microsoft 365 Apps for enterprise may be required. For more information, see Office 365 URLs and IP address ranges (includes all Office services, DNS names, IP addresses; includes Azure AD and other services that may overlap with those listed above). -
Certificate revocation lists (CRLs)Some of these services will also need to check certificate revocation lists (CRLs) for certificates used in the services.  A full list of these is documented at Office 365 URLs and IP address ranges and Office 365 Certificate Chains. -
Hybrid AAD joinThe device can be hybrid AAD joined. The computer should be on corporate network for hybrid AAD join to work. See details at Windows Autopilot user-driven mode -
Autopilot Self-Deploying mode and Autopilot White GloveFirmware TPM devices, which are only provided by Intel, AMD, or Qualcomm, do not include all needed certificates at boot time and must be able to retrieve them from the manufacturer on first use. Devices with discrete TPM chips (including devices from any other manufacturer) come with these certificates preinstalled. See TPM recommendations for more details. Make sure that these URLs are accessible for each firmware TPM provider so that certificates can be successfully requested: - -
Intel- https://ekop.intel.com/ekcertservice -
Qualcomm- https://ekcert.spserv.microsoft.com/EKCertificate/GetEKCertificate/v1 -
AMD- https://ftpm.amd.com/pki/aia -
- -## Licensing requirements - -Windows Autopilot depends on specific capabilities available in Windows 10 and Azure Active Directory. It also requires an MDM service such as Microsoft Intune. These capabilities can be obtained through various editions and subscription programs. - -To provide needed Azure Active Directory (automatic MDM enrollment and company branding features) and MDM functionality, one of the following is required: -- [Microsoft 365 Business Premium subscription](https://www.microsoft.com/microsoft-365/business). -- [Microsoft 365 F1 or F3 subscription](https://www.microsoft.com/microsoft-365/enterprise/firstline). -- [Microsoft 365 Academic A1, A3, or A5 subscription](https://www.microsoft.com/education/buy-license/microsoft365/default.aspx). -- [Microsoft 365 Enterprise E3 or E5 subscription](https://www.microsoft.com/microsoft-365/enterprise), which include all Windows 10, Office 365, and EM+S features (Azure AD and Intune). -- [Enterprise Mobility + Security E3 or E5 subscription](https://www.microsoft.com/cloud-platform/enterprise-mobility-security), which include all needed Azure AD and Intune features. -- [Intune for Education subscription](https://docs.microsoft.com/intune-education/what-is-intune-for-education), which include all needed Azure AD and Intune features. -- [Azure Active Directory Premium P1 or P2](https://azure.microsoft.com/services/active-directory/) and [Microsoft Intune subscriptions](https://www.microsoft.com/cloud-platform/microsoft-intune) (or an alternative MDM service). - -> [!NOTE] -> Even when using Microsoft 365 subscriptions, you still need to [assign Intune licenses to the users](https://docs.microsoft.com/intune/fundamentals/licenses-assign). - -Additionally, the following are also recommended (but not required): -- [Microsoft 365 Apps for enterprise](https://www.microsoft.com/p/office-365-proplus/CFQ7TTC0K8R0), which can be deployed easily via Intune (or other MDM services). -- [Windows Subscription Activation](https://docs.microsoft.com/windows/deployment/windows-10-enterprise-subscription-activation), to automatically step up devices from Windows 10 Pro to Windows 10 Enterprise. - -## Configuration requirements - -Before Windows Autopilot can be used, some configuration tasks are required to support the common Autopilot scenarios. - -- Configure Azure Active Directory automatic enrollment. For Microsoft Intune, see [Enable Windows 10 automatic enrollment](https://docs.microsoft.com/intune/windows-enroll#enable-windows-10-automatic-enrollment) for details. If using a different MDM service, contact the vendor for the specific URLs or configuration needed for those services. -- Configure Azure Active Directory custom branding. In order to display an organization-specific logon page during the Autopilot process, Azure Active Directory needs to be configured with the images and text that should be displayed. See [Quickstart: Add company branding to your sign-in page in Azure AD](https://docs.microsoft.com/azure/active-directory/fundamentals/customize-branding) for more details. Note that the "square logo" and "sign-in page text" are the key elements for Autopilot, as well as the Azure Active Directory tenant name (configured separately in the Azure AD tenant properties). -- Enable [Windows Subscription Activation](https://docs.microsoft.com/windows/deployment/windows-10-enterprise-subscription-activation) if desired, in order to automatically step up from Windows 10 Pro to Windows 10 Enterprise. - -Specific scenarios will then have additional requirements. Generally, there are two specific tasks: - -- Device registration. Devices need to be added to Windows Autopilot to support most Windows Autopilot scenarios. See [Adding devices to Windows Autopilot](add-devices.md) for more details. -- Profile configuration. Once devices have been added to Windows Autopilot, a profile of settings needs to be applied to each device. See [Configure Autopilot profiles](profiles.md) for details. Note that Microsoft Intune can automate this profile assignment; see [Create an Autopilot device group](https://docs.microsoft.com/intune/enrollment-Autopilot#create-an-Autopilot-device-group) and [Assign an Autopilot deployment profile to a device group](https://docs.microsoft.com/intune/enrollment-Autopilot#assign-an-Autopilot-deployment-profile-to-a-device-group) for more information. - -See [Windows Autopilot Scenarios](windows-Autopilot-scenarios.md) for additional details. - -For a walkthrough for some of these and related steps, see this video: - -
- - - -There are no additional hardware requirements to use Windows 10 Autopilot, beyond the [requirements to run Windows 10](https://www.microsoft.com/windows/windows-10-specifications). - -## Related topics - -[Configure Autopilot deployment](https://docs.microsoft.com/windows/deployment/windows-Autopilot/) diff --git a/windows/deployment/windows-autopilot/windows-autopilot-reset.md b/windows/deployment/windows-autopilot/windows-autopilot-reset.md deleted file mode 100644 index 8510d7574e..0000000000 --- a/windows/deployment/windows-autopilot/windows-autopilot-reset.md +++ /dev/null @@ -1,138 +0,0 @@ ---- -title: Windows Autopilot Reset -description: Windows Autopilot Reset takes the device back to a business-ready state, allowing the next user to sign in and get productive quickly and easily. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.reviewer: mniehaus -manager: laurawi -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Windows Autopilot Reset - -- Applies to: Windows 10, version 1709 and later (local reset) -- Applies to: Windows 10, version 1809 and later (remote reset) - -Windows Autopilot Reset removes personal files, apps, and settings and reapplies a device’s original settings, maintaining its identity connection to Azure AD and its management connection to Intune so that the device is once again ready for use. Windows Autopilot Reset takes the device back to a business-ready state, allowing the next user to sign in and get productive quickly and simply. - -The Windows Autopilot Reset process automatically retains information from the existing device: - -- Set the region, language, and keyboard to the originally-configured values. -- Wi-Fi connection details. -- Provisioning packages previously applied to the device, as well as a provisioning package present on a USB drive when the reset process is initiated. -- Azure Active Directory device membership and MDM enrollment information. - -Windows Autopilot Reset will block the user from accessing the desktop until this information is restored, including re-applying any provisioning packages. For devices enrolled in an MDM service, Windows Autopilot Reset will also block until an MDM sync is completed. -When Autopilot reset is used on a device, the device's primary user will be removed. The next user who signs in after the reset will be set as the primary user. - - ->[!NOTE] ->The Autopilot Reset does not support Hybrid Azure AD joined devices. - -## Scenarios - -Windows Autopilot Reset supports two scenarios: - -- [Local reset](#reset-devices-with-local-windows-autopilot-reset) initiated by IT personnel or other administrators from the organization. -- [Remote reset](#reset-devices-with-remote-windows-autopilot-reset) initiated remotely by IT personnel via an MDM service such as Microsoft Intune. - -Additional requirements and configuration details apply with each scenario; see the detailed links above for more information. - -## Reset devices with local Windows Autopilot Reset - -**Applies to: Windows 10, version 1709 and above** - -The Intune Service Administrator role is required to perform this task. For more information, see [Add users and grant administrative permission to Intune](https://docs.microsoft.com/intune/users-add). - -IT admins can perform a local Windows Autopilot Reset to quickly remove personal files, apps, and settings, and reset Windows 10 devices from the lock screen any time and apply original settings and management enrollment (Azure Active Directory and device management) so the devices are ready to use. With a local Autopilot Reset, devices are returned to a fully configured or known IT-approved state. - -To enable local Autopilot Reset in Windows 10: - -1. [Enable the policy for the feature](#enable-local-windows-autopilot-reset) -2. [Trigger a reset for each device](#trigger-local-windows-autopilot-reset) - -### Enable local Windows Autopilot Reset - -To enable a local Windows Autopilot Reset, the **DisableAutomaticReDeploymentCredentials** policy must be configured. This policy is documented in the [Policy CSP](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-credentialproviders), **CredentialProviders/DisableAutomaticReDeploymentCredentials**. By default, local Windows Autopilot is disabled. This ensures that a local Autopilot Reset is not triggered by accident. - -You can set the policy using one of these methods: - -- MDM provider - - - When using Intune, you can create a new device configuration profile, specifying "Windows 10 or later" for the platform, "Device restrictions" for the profile type, and "General" for the settings category. The **Automatic Redeployment** setting should be set to **Allow**. Deploy this setting to all devices where a local reset should be permitted. - - If you're using an MDM provider other than Intune, check your MDM provider documentation on how to set this policy. - -- Windows Configuration Designer - - You can [use Windows Configuration Designer](https://docs.microsoft.com/windows/configuration/provisioning-packages/provisioning-create-package) to set the **Runtime settings > Policies > CredentialProviders > DisableAutomaticReDeploymentCredentials** setting to 0 and then create a provisioning package. - -- Set up School PCs app - - The latest release of the Set up School PCs app supports enabling local Windows Autopilot Reset. - -### Trigger local Windows Autopilot Reset - -Performing a local Windows Autopilot Reset is a two-step process: trigger it and then authenticate. Once you've done these two steps, you can let the process execute and once it is done, the device is again ready for use. - -**To trigger a local Autopilot Reset** - -1. From the Windows device lock screen, enter the keystroke: **CTRL + ![Windows key](images/windows_glyph.png) + R**. - - ![Enter CTRL+Windows key+R on the Windows lock screen](images/autopilot-reset-lockscreen.png) - - This will open up a custom login screen for the local Autopilot Reset. The screen serves two purposes: - 1. Confirm/verify that the end user has the right to trigger Local Autopilot Reset - 2. Notify the user in case a provisioning package, created using Windows Configuration Designer, will be used as part of the process. - - ![Custom login screen for local Autopilot Reset](images/autopilot-reset-customlogin.png) - -2. Sign in with the admin account credentials. If you created a provisioning package, plug in the USB drive and trigger the local Autopilot Reset. - - Once the local Autopilot Reset is triggered, the reset process starts. Once provisioning is complete, the device is again ready for use. - -## Reset devices with remote Windows Autopilot Reset - -**Applies to: Windows 10, version 1809 or later** - -When performing a remote Windows Autopilot Reset, an MDM service such an Microsoft Intune can be used to initiate the reset process, avoiding the need for IT staff or other administrators to visit each machine to initiate the process. - -To enable a device for a remote Windows Autopilot Reset, the device must be MDM managed and joined to Azure AD. This feature is not supported on devices that were enrolled using [Autopilot self deploying mode](self-deploying.md). - -### Triggering a remote Windows Autopilot Reset - -To trigger a remote Windows Autopilot Reset via Intune, follow these steps: - -- Navigate to **Devices** tab in the Intune console. -- In the **All devices** view, select the targeted reset devices and then click **More** to view device actions. -- Select **Autopilot Reset** to kick-off the reset task. - ->[!NOTE] ->The Autopilot Reset option will only be enabled in Microsoft Intune for devices running Windows 10 build 17672 or higher. - ->[!IMPORTANT] ->The feature for Autopilot Reset will stay grayed out, **unless** you reset the device using Autopilot (either using Fresh Reset or manually sysprep the device). - -Once the reset is complete, the device is again ready for use. - - - -## Troubleshooting - -Windows Autopilot Reset requires that the [Windows Recovery Environment (WinRE)](https://docs.microsoft.com/windows-hardware/manufacture/desktop/windows-recovery-environment--windows-re--technical-reference) is correctly configured and enabled on the device. If it is not configured and enabled, an error such as `Error code: ERROR_NOT_SUPPORTED (0x80070032)` will be reported. - -To make sure WinRE is enabled, use the [REAgentC.exe tool](https://docs.microsoft.com/windows-hardware/manufacture/desktop/reagentc-command-line-options) to run the following command: - -``` -reagentc /enable -``` - -If Windows Autopilot Reset fails after enabling WinRE, or if you are unable to enable WinRE, please contact [Microsoft Support](https://support.microsoft.com) for assistance. diff --git a/windows/deployment/windows-autopilot/windows-autopilot-scenarios.md b/windows/deployment/windows-autopilot/windows-autopilot-scenarios.md deleted file mode 100644 index 16abf999ea..0000000000 --- a/windows/deployment/windows-autopilot/windows-autopilot-scenarios.md +++ /dev/null @@ -1,76 +0,0 @@ ---- -title: Windows Autopilot scenarios and capabilities -description: Follow along with several typical Windows Autopilot deployment scenarios, such as re-deploying a device in a business-ready state. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.reviewer: mniehaus -manager: laurawi -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Windows Autopilot scenarios and capabilities - -**Applies to: Windows 10** - -## Scenarios - -Windows Autopilot includes support for a growing list of scenarios, designed to support common organization needs which can vary based on the type of organization and their progress moving to Windows 10 and [transitioning to modern management](https://docs.microsoft.com/windows/client-management/manage-windows-10-in-your-organization-modern-management). - -The following Windows Autopilot scenarios are described in this guide: - -| Scenario | More information | -| --- | --- | -| Deploy devices that will be set up by a member of the organization and configured for that person | [Windows Autopilot user-driven mode](user-driven.md) | -| Deploy devices that will be automatically configured for shared use, as a kiosk, or as a digital signage device.| [Windows Autopilot self-deploying mode](self-deploying.md) | -| Re-deploy a device in a business-ready state.| [Windows Autopilot Reset](windows-autopilot-reset.md) | -| Pre-provision a device with up-to-date applications, policies and settings.| [White glove](white-glove.md) | -| Deploy Windows 10 on an existing Windows 7 or 8.1 device | [Windows Autopilot for existing devices](existing-devices.md) | - -These scenarios are summarized in the following video. - -  - -> [!video https://www.microsoft.com/videoplayer/embed/RE4Ci1b?autoplay=false] - -## Windows Autopilot capabilities - -### Windows Autopilot is self-updating during OOBE - -Starting with the Windows 10, version 1903, Autopilot functional and critical updates will begin downloading automatically during OOBE after a device gets connected to a network and the [critical driver and Windows zero-day patch (ZDP) updates](https://docs.microsoft.com/windows-hardware/customize/desktop/windows-updates-during-oobe) have completed. The user or IT admin cannot opt-out of these Autopilot updates; they are required for Windows Autopilot deployment to operate properly. Windows will alert the user that the device is checking for, downloading and installing the updates. - -See [Windows Autopilot update](autopilot-update.md) for more information. - -### Cortana voiceover and speech recognition during OOBE - -In Windows 10, version 1903 and later Cortana voiceover and speech recognition during OOBE is DISABLED by default for all Windows 10 Pro, Education and Enterprise SKUs. - -If desired, you can enable Cortana voiceover and speech recognition during OOBE by creating the following registry key. This key does not exist by default. - -HKLM\Software\Microsoft\Windows\CurrentVersion\OOBE\EnableVoiceForAllEditions - -The key value is a DWORD with **0** = disabled and **1** = enabled. - -| Value | Description | -| --- | --- | -| 0 | Cortana voiceover is disabled | -| 1 | Cortana voiceover is enabled | -| No value | Device will fall back to default behavior of the edition | - -To change this key value, use WCD tool to create as PPKG as documented [here](https://docs.microsoft.com/windows/configuration/wcd/wcd-oobe#nforce). - -### Bitlocker encryption - -With Windows Autopilot, you can configure the BitLocker encryption settings to be applied before automatic encryption is started. For more information, see [Setting the BitLocker encryption algorithm for Autopilot devices](bitlocker.md) - -## Related topics - -[Windows Autopilot: What's new](windows-autopilot-whats-new.md) diff --git a/windows/deployment/windows-autopilot/windows-autopilot-whats-new.md b/windows/deployment/windows-autopilot/windows-autopilot-whats-new.md deleted file mode 100644 index 8d69cc5d75..0000000000 --- a/windows/deployment/windows-autopilot/windows-autopilot-whats-new.md +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: Windows Autopilot what's new -ms.reviewer: -manager: laurawi -description: Read news and resources about the latest updates and past versions of Windows Autopilot. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Windows Autopilot: What's new - -**Applies to** - -- Windows 10 - -## Windows Autopilot update history - -The following [Windows Autopilot updates](autopilot-update.md) are available. **Note**: Updates are automatically downloaded and applied during the Windows Autopilot deployment process. - -No updates are available yet. Check back here later for more information. - -## New in Windows 10, version 2004 - -With this release, you can configure Windows Autopilot [user-driven](user-driven.md) Hybrid Azure Active Directory join with VPN support. This support is also backported to Windows 10, version 1909 and 1903. - -If you configure the language settings in the Autopilot profile and the device is connected to Ethernet, all scenarios will now skip the language, locale, and keyboard pages. In previous versions, this was only supported with self-deploying profiles. - -## New in Windows 10, version 1903 - -[Windows Autopilot for white glove deployment](white-glove.md) is new in Windows 10, version 1903. See the following video: - -
- -> [!VIDEO https://www.youtube.com/embed/nE5XSOBV0rI] - -Also new in this version of Windows: -- The Intune enrollment status page (ESP) now tracks Intune Management Extensions. -- [Cortana voiceover and speech recognition during OOBE](windows-autopilot-scenarios.md#cortana-voiceover-and-speech-recognition-during-oobe) is disabled by default for all Windows 10 Pro Education, and Enterprise SKUs. -- [Windows Autopilot is self-updating during OOBE](windows-autopilot-scenarios.md#windows-autopilot-is-self-updating-during-oobe). Starting with the Windows 10, version 1903 Autopilot functional and critical updates will begin downloading automatically during OOBE. -- Windows Autopilot will set the diagnostics data level to Full on Windows 10 version 1903 and later during OOBE. - -## New in Windows 10, version 1809 - -Windows Autopilot [self-deploying mode](self-deploying.md) enables a zero touch device provisioning experience. Simply power on the device, plug it into the Ethernet, and the device is fully configured by Windows Autopilot. This self-deploying capability removes the current need to have an end user interact by pressing the “Next” button during the deployment process. - -You can utilize Windows Autopilot self-deploying mode to register the device to an AAD tenant, enroll in your organization’s MDM provider, and provision policies and applications, all with no user authentication or user interaction required. - ->[!NOTE] ->Window 10, version 1903 or later is required to use self-deploying mode due to issues with TPM device attestation in Windows 10, version 1809. - -## Related topics - -[What's new in Microsoft Intune](https://docs.microsoft.com/intune/whats-new)
-[What's new in Windows 10](https://docs.microsoft.com/windows/whats-new/) diff --git a/windows/deployment/windows-autopilot/windows-autopilot.md b/windows/deployment/windows-autopilot/windows-autopilot.md deleted file mode 100644 index 16e1781d6e..0000000000 --- a/windows/deployment/windows-autopilot/windows-autopilot.md +++ /dev/null @@ -1,62 +0,0 @@ ---- -title: Overview of Windows Autopilot -description: Windows Autopilot is a collection of technologies used to set up and pre-configure new devices, getting them ready for productive use. -keywords: mdm, setup, windows, windows 10, oobe, manage, deploy, autopilot, ztd, zero-touch, partner, msfb, intune -ms.reviewer: mniehaus -manager: laurawi -ms.prod: w10 -ms.mktglfcycl: deploy -ms.localizationpriority: medium -ms.sitesec: library -ms.pagetype: deploy -audience: itpro -author: greg-lindsay -ms.author: greglin -ms.collection: M365-modern-desktop -ms.topic: article ---- - - -# Overview of Windows Autopilot - -**Applies to** - -- Windows 10 - -Windows Autopilot is a collection of technologies used to set up and pre-configure new devices, getting them ready for productive use. You can also use Windows Autopilot to reset, repurpose and recover devices. This solution enables an IT department to achieve the above with little to no infrastructure to manage, with a process that's easy and simple. - -Windows Autopilot is designed to simplify all parts of the lifecycle of Windows devices, for both IT and end users, from initial deployment through the eventual end of life. Leveraging cloud-based services, it can reduce the overall costs for deploying, managing, and retiring devices by reducing the amount of time that IT needs to spend on these processes and the amount of infrastructure that they need to maintain, while ensuring ease of use for all types of end users. See the following video and diagram: - -  - -> [!video https://www.microsoft.com/videoplayer/embed/RE4C7G9?autoplay=false] - -![Process overview](images/image1.png) - -When initially deploying new Windows devices, Windows Autopilot leverages the OEM-optimized version of Windows 10 that is preinstalled on the device, saving organizations the effort of having to maintain custom images and drivers for every model of device being used. Instead of re-imaging the device, your existing Windows 10 installation can be transformed into a “business-ready” state, applying settings and policies, installing apps, and even changing the edition of Windows 10 being used (e.g. from Windows 10 Pro to Windows 10 Enterprise) to support advanced features. - -Once deployed, Windows 10 devices can be managed by tools such as Microsoft Intune, Windows Update for Business, Microsoft Endpoint Configuration Manager, and other similar tools. Windows Autopilot can also be used to re-purpose a device by leveraging Windows Autopilot Reset to quickly prepare a device for a new user, or in break/fix scenarios to enable a device to quickly be brought back to a business-ready state. - -Windows Autopilot enables you to: -* Automatically join devices to Azure Active Directory (Azure AD) or Active Directory (via Hybrid Azure AD Join). See [Introduction to device management in Azure Active Directory](https://docs.microsoft.com/azure/active-directory/device-management-introduction) for more information about the differences between these two join options. -* Auto-enroll devices into MDM services, such as Microsoft Intune ([*Requires an Azure AD Premium subscription for configuration*](https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Windows-10-Azure-AD-and-Microsoft-Intune-Automatic-MDM/ba-p/244067)). -* Restrict the Administrator account creation. -* Create and auto-assign devices to configuration groups based on a device's profile. -* Customize OOBE content specific to the organization. - -## Benefits of Windows Autopilot - -Traditionally, IT pros spend a lot of time building and customizing images that will later be deployed to devices. Windows Autopilot introduces a new approach. - -From the user's perspective, it only takes a few simple operations to make their device ready to use. - -From the IT pro's perspective, the only interaction required from the end user is to connect to a network and to verify their credentials. Everything beyond that is automated. - -## Requirements - -A [supported version](https://docs.microsoft.com/windows/release-information/) of Windows 10 semi-annual channel is required to use Windows Autopilot. Windows 10 Enterprise LTSC 2019 is also supported. See [Windows Autopilot requirements](windows-autopilot-requirements.md) for detailed information on software, configuration, network, and licensing requirements. - -## Related topics - -[Enroll Windows devices in Intune by using Windows Autopilot](https://docs.microsoft.com/intune/enrollment-autopilot)
-[Windows Autopilot scenarios and capabilities](windows-autopilot-scenarios.md)