deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-15 18:33:43 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Merge branch 'public' into master

Browse Source
This commit is contained in:
Dani Halfin
2019-10-07 13:30:00 -07:00
committed by GitHub
parent 208778785a bfe2b75e51
commit d8e924255b
2575 changed files with 62848 additions and 37279 deletions
Download Patch File Download Diff File Expand all files Collapse all files

116
windows/deployment/s-mode.md
View File

@ -1,57 +1,59 @@
---
title: Windows 10 Pro in S mode
description: Overview of Windows 10 Pro/Enterprise in S mode. What is S mode for Enterprise customers?
keywords: Windows 10 S, S mode, Windows S mode, Windows 10 S mode, S-mode, system requirements, Overview, Windows 10 Pro in S mode, Windows 10 Enterprise in S mode, Windows 10 Pro/Enterprise in S mode
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.prod: w10
ms.sitesec: library
ms.pagetype: deploy
ms.date: 12/05/2018
ms.reviewer:
manager: laurawi
ms.audience: itpro
author: greg-lindsay
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Windows 10 in S mode - What is it?
S mode is an evolution of the S SKU introduced with Windows 10 April 2018 Update. It's a configuration that's available on all Windows Editions when enabled at the time of manufacturing. The edition of Windows can be upgrade at any time as shown below. However, the switch from S mode is a onetime switch and can only be undone by a wipe and reload of the OS.
![Configuration and features of S mode](images/smodeconfig.png)
## S mode key features
**Microsoft-verified security**
With Windows 10 in S mode, you’ll find your favorite applications, such as Office, Evernote, and Spotify in the Microsoft Store where they’re Microsoft-verified for security. You can also feel secure when you’re online. Microsoft Edge, your default browser, gives you protection against phishing and socially engineered malware.
**Performance that lasts**
Start-ups are quick, and S mode is built to keep them that way. With Microsoft Edge as your browser, your online experience is fast and secure. Plus, you’ll enjoy a smooth, responsive experience, whether you’re streaming HD video, opening apps, or being productive on the go.
**Choice and flexibility**
Save your files to your favorite cloud, like OneDrive or Dropbox, and access them from any device you choose. Browse the Microsoft Store for thousands of apps, and if you don’t find exactly what you want, you can easily [switch out of S mode](https://docs.microsoft.com/windows/deployment/windows-10-pro-in-s-mode) to Windows 10 Home, Pro, or Enterprise editions at any time and search the web for more choices, as shown below.
![Switching out of S mode flow chart](images/s-mode-flow-chart.png)
## Deployment
Windows 10 in S mode is built for [modern management](https://docs.microsoft.com/windows/client-management/manage-windows-10-in-your-organization-modern-management) which means using [Windows Autopilot](https://docs.microsoft.com/windows/deployment/windows-autopilot/windows-10-autopilot). Windows Autopilot lets you deploy the device directly to a user without IT having to touch the physical device. Instead of manually deploying a custom image, Windows Autopilot will start with a generic PC that can only be used to join the company domain; policies are then deployed automatically through mobile device management to customize the device to the user and the desired environment. Devices are shipped in S mode; you can either keep them in S mode or use Windows Autopilot to switch the device out of S mode during the first run process or later using mobile device management, if desired.
## Keep line of business apps functioning with Desktop Bridge
Worried about your line of business apps not working in S mode? [Desktop Bridge](https://docs.microsoft.com/windows/uwp/porting/desktop-to-uwp-root) enables you to convert your line of business apps to a packaged app with UWP manifest. After testing and validating you can distribute the app through the Microsoft Store, making it ideal for Windows 10 in S mode.
## Repackage Win32 apps into the MSIX format
The [MSIX Packaging Tool](https://docs.microsoft.com/windows/application-management/msix-app-packaging-tool), available from the Microsoft Store, enables you to repackage existing Win32 applications to the MSIX format. You can run your desktop installers through this tool interactively and obtain an MSIX package that you can install on your device and upload to the Microsoft Store. This is another way to get your apps ready to run on Windows 10 in S mode.
## Related links
- [Consumer applications for S mode](https://www.microsoft.com/windows/s-mode)
- [S mode devices](https://www.microsoft.com/windows/view-all-devices)
---
title: Windows 10 Pro in S mode
description: Overview of Windows 10 Pro/Enterprise in S mode. What is S mode for Enterprise customers?
keywords: Windows 10 S, S mode, Windows S mode, Windows 10 S mode, S-mode, system requirements, Overview, Windows 10 Pro in S mode, Windows 10 Enterprise in S mode, Windows 10 Pro/Enterprise in S mode
ms.mktglfcycl: deploy
ms.localizationpriority: medium
ms.prod: w10
ms.sitesec: library
ms.pagetype: deploy
ms.date: 12/05/2018
ms.reviewer:
manager: laurawi
ms.audience: itpro
author: greg-lindsay
audience: itpro
author: greg-lindsay
ms.topic: article
---
# Windows 10 in S mode - What is it?
S mode is an evolution of the S SKU introduced with Windows 10 April 2018 Update. It's a configuration that's available on all Windows Editions when enabled at the time of manufacturing. The edition of Windows can be upgrade at any time as shown below. However, the switch from S mode is a onetime switch and can only be undone by a wipe and reload of the OS.
![Configuration and features of S mode](images/smodeconfig.png)
## S mode key features
**Microsoft-verified security**
With Windows 10 in S mode, you’ll find your favorite applications, such as Office, Evernote, and Spotify in the Microsoft Store where they’re Microsoft-verified for security. You can also feel secure when you’re online. Microsoft Edge, your default browser, gives you protection against phishing and socially engineered malware.
**Performance that lasts**
Start-ups are quick, and S mode is built to keep them that way. With Microsoft Edge as your browser, your online experience is fast and secure. Plus, you’ll enjoy a smooth, responsive experience, whether you’re streaming HD video, opening apps, or being productive on the go.
**Choice and flexibility**
Save your files to your favorite cloud, like OneDrive or Dropbox, and access them from any device you choose. Browse the Microsoft Store for thousands of apps, and if you don’t find exactly what you want, you can easily [switch out of S mode](https://docs.microsoft.com/windows/deployment/windows-10-pro-in-s-mode) to Windows 10 Home, Pro, or Enterprise editions at any time and search the web for more choices, as shown below.
![Switching out of S mode flow chart](images/s-mode-flow-chart.png)
## Deployment
Windows 10 in S mode is built for [modern management](https://docs.microsoft.com/windows/client-management/manage-windows-10-in-your-organization-modern-management) which means using [Windows Autopilot](https://docs.microsoft.com/windows/deployment/windows-autopilot/windows-10-autopilot). Windows Autopilot lets you deploy the device directly to a user without IT having to touch the physical device. Instead of manually deploying a custom image, Windows Autopilot will start with a generic PC that can only be used to join the company domain; policies are then deployed automatically through mobile device management to customize the device to the user and the desired environment. Devices are shipped in S mode; you can either keep them in S mode or use Windows Autopilot to switch the device out of S mode during the first run process or later using mobile device management, if desired.
## Keep line of business apps functioning with Desktop Bridge
Worried about your line of business apps not working in S mode? [Desktop Bridge](https://docs.microsoft.com/windows/uwp/porting/desktop-to-uwp-root) enables you to convert your line of business apps to a packaged app with UWP manifest. After testing and validating you can distribute the app through the Microsoft Store, making it ideal for Windows 10 in S mode.
## Repackage Win32 apps into the MSIX format
The [MSIX Packaging Tool](https://docs.microsoft.com/windows/application-management/msix-app-packaging-tool), available from the Microsoft Store, enables you to repackage existing Win32 applications to the MSIX format. You can run your desktop installers through this tool interactively and obtain an MSIX package that you can install on your device and upload to the Microsoft Store. This is another way to get your apps ready to run on Windows 10 in S mode.
## Related links
- [Consumer applications for S mode](https://www.microsoft.com/windows/s-mode)
- [S mode devices](https://www.microsoft.com/windows/view-all-devices)
- [Windows Defender Application Control deployment guide](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide)
- [Windows Defender Advanced Threat Protection](https://www.microsoft.com/microsoft-365/windows/microsoft-defender-atp)

8
windows/deployment/update/device-health-using.md
View File

@ -2,7 +2,7 @@
title: Using Device Health
ms.reviewer:
manager: laurawi
description: Explains how to begin usihg Device Health.
description: Explains how to begin using Device Health.
ms.prod: w10
ms.mktglfcycl: deploy
keywords: oms, operations management suite, wdav, health, log analytics
@ -93,7 +93,7 @@ Clicking a listed driver on the Driver-Induced OS Crashes blade opens a driver p
![Driver detail and history](images/driver-detail-1-sterile.png)
![Driver detail and history scrolldown](images/driver-detail-2-sterile.png)
The driver version table can help you determine whether deploying a newer version of the driver might help you reduce the crash rate. In the example shown above, the most commonly installed driver version (19.15.1.5) has a crash rate of about one-half of one percent--this is low, so this driver is probably fine. However, driver version 19.40.0.3 has a crash rate of almost 20%. If that driver had been widely deployed, updating it would substantially reduce the overal number of crashes in your organization.
The driver version table can help you determine whether deploying a newer version of the driver might help you reduce the crash rate. In the example shown above, the most commonly installed driver version (19.15.1.5) has a crash rate of about one-half of one percent--this is low, so this driver is probably fine. However, driver version 19.40.0.3 has a crash rate of almost 20%. If that driver had been widely deployed, updating it would substantially reduce the overall number of crashes in your organization.
## App Reliability
@ -207,7 +207,7 @@ The Login Health blades appear in the Device Health dashboard:
![Main Login health view](images/login-health.png)
### Login Errors
The **Login errors** blade displays data on the frequency and type of errors, with statistics on specific errors. They are generally categorized into user-generated (caused by bad input) or non-user-generated (might need IT intervention) errors. Click any individual error to see all instances of the error's occurence for the specified time period.
The **Login errors** blade displays data on the frequency and type of errors, with statistics on specific errors. They are generally categorized into user-generated (caused by bad input) or non-user-generated (might need IT intervention) errors. Click any individual error to see all instances of the error's occurrence for the specified time period.
### Login Metrics by Type
The **Login metrics by type** blade shows the success rate for your devices, as well as the success rate for other environments with a mix of operating system versions and device models similar to yours (the **Commercial average success rate**).
@ -304,7 +304,7 @@ You can run these queries from the Azure Portal **Log Search** interface (availa
### Exporting data and configuring alerts
Azure Portal enables you to export data to other tools. To do this, in any view that shows **Log Search** just click the **Export** button. Similarly, clicking the **Alert** button will enable you to run a query automaticlaly on a schedule and receive email alerts for particular query results that you set. If you have a PowerBI account, then you will also see a **PowerBI** button that enables you to run a query on a schedule and have the results automatically saved as a PowerBI data set.
Azure Portal enables you to export data to other tools. To do this, in any view that shows **Log Search** just click the **Export** button. Similarly, clicking the **Alert** button will enable you to run a query automatically on a schedule and receive email alerts for particular query results that you set. If you have a PowerBI account, then you will also see a **PowerBI** button that enables you to run a query on a schedule and have the results automatically saved as a PowerBI data set.

15
windows/deployment/update/fod-and-lang-packs.md
View File

@ -6,7 +6,8 @@ ms.mktglfcycl: manage
ms.sitesec: library
ms.pagetype: article
ms.author: greglin
audience: itpro
audience: itpro
author: greg-lindsay
ms.localizationpriority: medium
ms.date: 03/13/2019
ms.reviewer:
@ -17,10 +18,14 @@ ms.topic: article
> Applies to: Windows 10
As of Windows 10 version 1709, you cannot use Windows Server Update Services (WSUS) to host [Features on Demand](https://docs.microsoft.com/windows-hardware/manufacture/desktop/features-on-demand-v2--capabilities) (FOD) and language packs for Windows 10 clients locally. Instead, you can enforce a Group Policy setting that tells the clients to pull them directly from Windows Update. You can also host FOD and language packs on a network share, but starting with Windows 10 version 1809, FOD and language packs can only be installed from Windows Update.
As of Windows 10 version 1709, you can't use Windows Server Update Services (WSUS) to host [Features on Demand](https://docs.microsoft.com/windows-hardware/manufacture/desktop/features-on-demand-v2--capabilities) (FODs) locally. Starting with Windows 10 version 1803, language packs can no longer be hosted on WSUS.
The **Specify settings for optional component installation and component repair** policy, located under `Computer Configuration\Administrative Templates\System` in the Group Policy Editor, can be used to specify alternate ways to acquire FOD packages, language packages, and content for corruption repair. However, it’s important to note this policy only allows specifying one alternate location and behaves differently across OS versions.
In Windows 10 version 1709 and 1803, changing the **Specify settings for optional component installation and component repair** policy to download content from Windows Update enables acquisition of FOD packages while also enabling corruption repair. Specifying a network location works for either, depending on the content is found at that location. Changing this policy on these OS versions does not influence how language packs are acquired.
In Windows 10 version 1809 and beyond, changing the **Specify settings for optional component installation and component repair** policy also influences how language packs are acquired, however language packs can only be acquired directly from Windows Update. It’s currently not possible to acquire them from a network share. Specifying a network location works for FOD packages or corruption repair, depending on the content at that location.
For all OS versions, changing the **Specify settings for optional component installation and component repair** policy does not affect how OS updates are distributed. They continue to come from WSUS or SCCM or other sources as you have scheduled them, even while optional content is sourced from Windows Update or a network location.
Learn about other client management options, including using Group Policy and administrative templates, in [Manage clients in Windows 10](https://docs.microsoft.com/windows/client-management/).

11
windows/deployment/update/waas-delivery-optimization.md
View File

@ -8,9 +8,9 @@ ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
audience: itpro
author: greg-lindsay
author: jaimeo
ms.localizationpriority: medium
ms.author: greglin
ms.author: jaimeo
ms.collection: M365-modern-desktop
ms.topic: article
---
@ -97,7 +97,12 @@ For more details, check out the [Adopting Windows as a Service at Microsoft](htt
**Does Delivery Optimization work with WSUS?**: Yes. Devices will obtain the update payloads from the WSUS server, but must also have an internet connection as they communicate with the Delivery Optimization cloud service for coordination.
**Which ports does Delivery Optimization use?**: For peer-to-peer traffic, it uses 7680 for TCP/IP or 3544 for NAT traversal (optionally Teredo). For client-service communication, it uses HTTP or HTTPS over port 80/443.
**Which ports does Delivery Optimization use?**: Delivery Optimization listens on port 7680 for requests from other peers by using TCP/IP. The service will register and open this port on the device, but you might need to set this port to accept inbound traffic through your firewall yourself. If you don't allow inbound traffic over port 7680, you can't use the peer-to-peer functionality of Delivery Optimization. However, devices can still successfully download by using HTTP or HTTPS traffic over port 80 (such as for default Windows Update data).
If you set up Delivery Optimization to create peer groups that include devices across NATs (or any form of internal subnet that uses gateways or firewalls between subnets), it will use Teredo. For this to work, you must allow inbound TCP/IP traffic over port 3544. Look for a "NAT traversal" setting in your firewall to set this up.
Delivery Optimization also communicates with its cloud service by using HTTP/HTTPS over port 80.
**What are the requirements if I use a proxy?**: You must allow Byte Range requests. See [Proxy requirements for Windows Update](https://support.microsoft.com/help/3175743/proxy-requirements-for-windows-update) for details.

11
windows/deployment/update/waas-quick-start.md
View File

@ -19,15 +19,14 @@ ms.topic: article
**Applies to**
- Windows 10
- Windows 10 IoT Mobile
Windows as a service is a new concept, introduced with the release of Windows 10. While [an extensive set of documentation](index.md) is available explaining all the specifics and nuances, here is a quick guide to the most important concepts.
## Definitions
Some new terms have been introduced as part of Windows as a service, so you should know what these terms mean.
- **Feature updates** will be released twice per year, around March and September. As the name suggests, these will add new features to Windows 10, delivered in bite-sized chunks compared to the previous practice of Windows releases every 3-5 years.
- **Quality updates** deliver both security and non-security fixes. They are typically released on the second Tuesday of each month ("Patch Tuesday"), though they can be released at any time. Quality updates include security updates, critical updates, servicing stack updates, and driver updates. Quality updates are cumulative, so installing the latest quality update is sufficient to get all the available fixes for a specific Windows 10 feature update. The "servicing stack" is the code that installs other updates, so they are important to keep current. For more information, see [Servicing stack updates](servicing-stack-updates.md).
- **Feature updates** are released twice per year, around March and September. As the name suggests, these will add new features to Windows 10, delivered in bite-sized chunks compared to the previous practice of Windows releases every 3-5 years.
- **Quality updates** deliver both security and non-security fixes. They are typically released on the second Tuesday of each month, though they can be released at any time. Quality updates include security updates, critical updates, servicing stack updates, and driver updates. Quality updates are cumulative, so installing the latest quality update is sufficient to get all the available fixes for a specific Windows 10 feature update. The "servicing stack" is the code that installs other updates, so they are important to keep current. For more information, see [Servicing stack updates](servicing-stack-updates.md).
- **Insider Preview** builds are made available during the development of the features that will be shipped in the next feature update, enabling organizations to validate new features as well as compatibility with existing apps and infrastructure, providing feedback to Microsoft on any issues encountered.
- **Servicing channels** allow organizations to choose when to deploy new features.
- The **Semi-Annual Channel** receives feature updates twice per year.
@ -40,9 +39,9 @@ For some interesting in-depth information about how cumulative updates work, see
## Key Concepts
Windows 10 gains new functionality with twice-per-year feature update releases. Initially, organizations will use these feature update releases for pilot deployments to ensure compatibility with existing apps and infrastructure. After a period of time, typically about four months after the feature update release, broad deployment throughout the organization can begin. The exact timeframe is determined by feedback from customers, ISVs, OEMs, and others, with an explicit "ready for broad deployment" declaration signaling this to customers.
Windows 10 gains new functionality with twice-per-year feature update releases. Initially, organizations will use these feature update releases for pilot deployments to ensure compatibility with existing apps and infrastructure. With each Semi-Annual Channel release, we recommend beginning deployment right away to devices selected for early adoption (targeted validation) and ramp up to full deployment at your discretion.
Each Windows 10 feature update will be serviced with quality updates for 18 months from the date of the feature update release.
All releases of Windows 10 have 18 months of servicing for all editions--these updates provide security and feature updates for the release. Customers running Enterprise and Education editions have an additional 12 months of servicing for specific Windows 10 releases, for a total of 30 months from initial release. These versions include Enterprise and Education editions for Windows 10, versions 1607 and later. Starting in October 2018, all Semi-Annual Channel releases in the September/October timeframe will also have the additional 12 months of servicing for a total of 30 months from the initial release. The Semi-Annual Channel versions released in March/April timeframe will continue to have an 18-month lifecycle.
Windows 10 Enterprise LTSB is a separate **Long Term Servicing Channel** version. Each release is supported for a total of 10 years (five years standard support, five years extended support). New releases are expected about every three years.
@ -50,7 +49,7 @@ See [Assign devices to servicing channels for Windows 10 updates](waas-servicing
## Staying up to date
The process for keeping Windows 10 up to date involves deploying a feature update, at an appropriate time after its release. A variety of tools management and patching tools such as Windows Update, Windows Update for Business, Windows Server Update Services, System Center Configuration Manager, and third-party products) can be used to help with this process. [Windows Analytics Upgrade Readiness](https://www.microsoft.com/WindowsForBusiness/windows-analytics), a free tool to streamline Windows upgrade projects, is another important tool to help.
The process for keeping Windows 10 up to date involves deploying a feature update, at an appropriate time after its release. A variety of management and update tools such as Windows Update, Windows Update for Business, Windows Server Update Services, System Center Configuration Manager, and third-party products) can be used to help with this process. [Upgrade Readiness](https://docs.microsoft.com/windows/deployment/upgrade/upgrade-readiness-get-started), a free tool to streamline Windows upgrade projects, is another important tool to help.
Because app compatibility, both for desktop apps and web apps, is outstanding with Windows 10, extensive advanced testing isn’t required. Instead, only business-critical apps need to be tested, with the remaining apps validated through a series of pilot deployment rings. Once these pilot deployments have validated most apps, broad deployment can begin.

586
windows/deployment/update/windows-analytics-FAQ-troubleshooting.md
View File

@ -1,293 +1,293 @@
---
title: Frequently asked questions and troubleshooting Windows Analytics
ms.reviewer:
manager: laurawi
description: Frequently asked questions about Windows Analytics and steps to take when things go wrong
keywords: windows analytics, oms, operations management suite, prerequisites, requirements, updates, upgrades, log analytics, health, FAQ, problems, troubleshooting, error
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.audience: itpro
author: greg-lindsay
ms.localizationpriority: medium
ms.collection: M365-analytics
ms.topic: article
---
# Frequently asked questions and troubleshooting Windows Analytics
>[!IMPORTANT]
>**The OMS portal has been deprecated; you should start using the [Azure portal](https://portal.azure.com) instead as soon as possible.** Many experiences are the same in the two portals, but there are some key differences. See [Windows Analytics in the Azure Portal](windows-analytics-azure-portal.md) for steps to use Windows Analytics in the Azure portal. For much more information about the transition from OMS to Azure, see [OMS portal moving to Azure](https://docs.microsoft.com/azure/log-analytics/log-analytics-oms-portal-transition).
This topic compiles the most common issues encountered with configuring and using Windows Analytics, as well as general questions. This FAQ, along with the [Windows Analytics Technical Community](https://techcommunity.microsoft.com/t5/Windows-Analytics/ct-p/WindowsAnalytics), are recommended resources to consult before contacting Microsoft support.
## Troubleshooting common problems
If you've followed the steps in the [Enrolling devices in Windows Analytics](windows-analytics-get-started.md) topic and are still encountering problems, you might find the solution here.
[Devices not appearing in Upgrade Readiness](#devices-not-appearing-in-upgrade-readiness)
[Devices not appearing in Device Health Device Reliability](#devices-not-appearing-in-device-health-device-reliability)
[Device crashes not appearing in Device Health Device Reliability](#device-crashes-not-appearing-in-device-health-device-reliability)
[Apps not appearing in Device Health App Reliability](#apps-not-appearing-in-device-health-app-reliability)
[Upgrade Readiness shows many "Computers with outdated KB"](#upgrade-readiness-shows-many-computers-with-outdated-kb)
[Upgrade Readiness shows many "Computers with incomplete data"](#upgrade-readiness-shows-many-computers-with-incomplete-data)
[Upgrade Readiness doesn't show app inventory data on some devices](#upgrade-readiness-doesnt-show-app-inventory-data-on-some-devices)
[Upgrade Readiness doesn't show IE site discovery data from some devices](#upgrade-readiness-doesnt-show-ie-site-discovery-data-from-some-devices)
[Device names not appearing for Windows 10 devices](#device-names-not-appearing-for-windows-10-devices)
[Custom log queries using the AbnormalShutdownCount field of Device Health show zero or lower than expected results](#custom-log-queries-using-the-abnormalshutdowncount-field-of-device-health-show-zero-or-lower-than-expected-results)
[Disable Upgrade Readiness](#disable-upgrade-readiness)
[Exporting large data sets](#exporting-large-data-sets)
### Devices not appearing in Upgrade Readiness
In Log Analytics workspace, go to **Solutions** and verify that you are subscribed to the Windows Analytics solutions you intend to use.
Even though devices can take 2-3 days after enrollment to show up due to latency in the system, you can now verify the status of your devices within a few hours of running the deployment script as described in [You can now check on the status of your computers within hours of running the deployment script](https://techcommunity.microsoft.com/t5/Windows-Analytics-Blog/You-can-now-check-on-the-status-of-your-computers-within-hours/ba-p/187213) on the Tech Community Blog.
>[!NOTE]
> If you generate the status report and get an error message saying "Sorry! We’re not recognizing your Commercial Id, See [Enrolling devices in Windows Analytics](https://docs.microsoft.com/windows/deployment/update/windows-analytics-get-started).
If devices are not showing up as expected, find a representative device and follow these steps to run the latest pilot version of the Upgrade Readiness deployment script on it to troubleshoot issues:
1. Download and extract the [Upgrade Readiness Deployment Script](https://www.microsoft.com/download/details.aspx?id=53327). Ensure that the **Pilot/Diagnostics** folder is included.
2. Edit the script as described in [Upgrade Readiness deployment script](../upgrade/upgrade-readiness-deployment-script.md).
3. Check that `isVerboseLogging` is set to `$true`.
4. Run the script again. Log files will be saved to the directory specified in the script.
5. Check the output of the script in the command window and/or log **UA_dateTime_machineName.txt** to ensure that all steps were completed successfully.
6. If you are still seeing errors you can't diagnose, then consider open a support case with Microsoft Support through your regular channel and provide this information.
If you want to check a large number of devices, you should run the latest script at scale from your management tool of choice (for example, System Center Configuration Manager) and check the results centrally.
If you think the issue might be related to a network proxy, check "Enable data sharing" section of the [Enrolling devices in Windows Analytics](windows-analytics-get-started.md) topic. Also see [Understanding connectivity scenarios and the deployment script](https://blogs.technet.microsoft.com/upgradeanalytics/2017/03/10/understanding-connectivity-scenarios-and-the-deployment-script/) on the Windows Analytics blog.
If you have deployed images that have not been generalized, then many of them might have the same ID and so Windows Analytics will see them as one device. If you suspect this is the issue, then you can reset the IDs on the non-generalized devices by performing these steps:
1. Net stop diagtrack
2. Reg delete hklm\software\microsoft\sqmclient /v MachineId /f
3. Net start diagtrack
#### Devices not appearing in Device Health Device Reliability
[![Device Reliability tile showing device count highlighted](images/device-reliability-device-count.png)](images/device-reliability-device-count.png)
If you have devices that appear in other solutions, but not Device Health (the Device Health overview tile shows "Performing Assessment" or the device count is lower than expected), follow these steps to investigate the issue:
1. Using the Azure portal, remove the Device Health (appears as DeviceHealthProd on some pages) solution from your Log Analytics workspace. After completing this, add the Device Health solution to you workspace again.
2. Confirm that the devices are running Windows 10.
3. Verify that the Commercial ID is present in the device's registry. For details see [https://gpsearch.azurewebsites.net/#13551](https://gpsearch.azurewebsites.net/#13551).
4. Confirm that devices are opted in to send diagnostic data by checking in the registry that **AllowTelemetry** is set to either 2 (Enhanced) or 3 (Full).
- **AllowTelemetry** under **HKLM\Software\Policies\Microsoft\Windows\DataCollection** is the IT policy path.
- **AllowTelemetry** under **HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\DataCollection** is the user preference (Settings app) path.
- IMPORTANT: By convention (and in earlier versions of Windows 10) the IT policy would take precedence over any user preference. Starting with Windows 10, version 1803, the user can lower the device's effective value even when an IT policy is set. This change assists organizations in complying with regional or organizational expectations about user control over privacy settings. For organizations where user control of privacy settings is not required, the previous behavior (IT policy path always wins) can be enabled using the new policy **Computer Configuration\Administrative Templates\Windows Components\Data Collection and Preview Builds\Configure telemetry opt-in setting user interface**.
5. Verify that devices can reach the endpoints specified in [Enrolling devices in Windows Analytics](windows-analytics-get-started.md). Also check settings for SSL inspection and proxy authentication; see [Configuring endpoint access with SSL inspection](https://docs.microsoft.com/windows/deployment/update/windows-analytics-get-started#configuring-endpoint-access-with-ssl-inspection) for more information.
6. Wait 48 hours for activity to appear in the reports.
7. If you need additional troubleshooting, contact Microsoft Support.
### Device crashes not appearing in Device Health Device Reliability
[![Device Reliability tile showing crash count highlighted](images/device-reliability-crash-count.png)](images/device-reliability-crash-count.png)
If you know that devices are experiencing stop error crashes that do not seem to be reflected in the count of devices with crashes, follow these steps to investigate the issue:
1. Verify that devices are reporting data properly by following the steps in the [Devices not appearing in Device Health Device Reliability](#devices-not-appearing-in-device-health-device-reliability) section of this topic.
2. Trigger a known crash on a test device by using a tool such as [NotMyFault](https://docs.microsoft.com/sysinternals/downloads/notmyfault) from Windows Sysinternals.
3. Verify that Windows Error Reporting (WER) is not disabled or redirected by confirming the registry settings in **HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting** (or **HKLM\Software\Policies\Microsoft\Windows\DataCollection**, which will take precedence if set):
- Verify that the value "Disabled" (REG_DWORD), if set, is 0.
- Verify that the value "DontSendAdditionalData" (REG_DWORD), if set, is 0.
- Verify that the value "CorporateWERServer" (REG_SZ) is not configured.
4. Verify that WER can reach all diagnostic endpoints specified in [Enrolling devices in Windows Analytics](windows-analytics-get-started.md)--if WER can only reach some of the endpoints, it could be included in the device count while not reporting crashes.
5. Check that crash reports successfully complete the round trip with Event 1001 and that BucketID is not blank. A typical such event looks like this:
[![Event viewer detail showing Event 1001 details](images/event_1001.png)](images/event_1001.png)
You can use the following Windows PowerShell snippet to summarize recent occurrences of Event 1001. Most events should have a value for BucketID (a few intermittent blank values are OK, however).
```powershell
$limitToMostRecentNEvents = 20
Get-WinEvent -FilterHashTable @{ProviderName="Windows Error Reporting"; ID=1001} |
?{ $_.Properties[2].Value -match "crash|blue" } |
% { [pscustomobject]@{
TimeCreated=$_.TimeCreated
WEREvent=$_.Properties[2].Value
BucketId=$_.Properties[0].Value
ContextHint = $(
if($_.Properties[2].Value -eq "bluescreen"){"kernel"}
else{ $_.Properties[5].Value }
)
}} | Select-Object -First $limitToMostRecentNEvents
```
The output should look something like this:
[![Typical output for this snippet](images/device-reliability-event1001-PSoutput.png)](images/device-reliability-event1001-PSoutput.png)
6. Check that some other installed device, app, or crash monitoring solution is not intercepting crash events.
7. Wait 48 hours for activity to appear in the reports.
8. If you need additional troubleshooting, contact Microsoft Support.
#### Endpoint connectivity
Devices must be able to reach the endpoints specified in [Enrolling devices in Windows Analytics](windows-analytics-get-started.md).
If you are using proxy server authentication, it's worth taking extra care to check the configuration. Prior to Windows 10, version 1703, WER only uploads error reports in the machine context, so whitelisting endpoints to allow non-authenticated access was typically used. In Windows 10, version 1703 and later versions, WER will attempt to use the context of the user that is logged on for proxy authentication such that only the user account requires proxy access.
For more information, see [Enrolling devices in Windows Analytics](windows-analytics-get-started.md#configuring-endpoint-access-with-proxy-server-authentication).
### Apps not appearing in Device Health App Reliability
[![App Reliability tile showing relability events trend](images/app-reliability.png)](images/app-reliability.png)
If apps that you know are crashing do not appear in App Reliability, follow these steps to investigate the issue:
1. Double-check the steps in the [Devices not appearing in Device Health Device Reliability](#devices-not-appearing-in-device-health-device-reliability) and [Device crashes not appearing in Device Health Device Reliability](#device-crashes-not-appearing-in-device-health-device-reliability) sections of this topic.
2. Confirm that an in-scope application has crashed on an enrolled device. Keep the following points in mind:
- Not all user-mode crashes are included in App Reliability, which tracks only apps that have a GUI, have been used interactively by a user, and are not part of the operating system.
- Enrolling more devices helps to ensure that there are enough naturally occurring app crashes.
- You can also use test apps which are designed to crash on demand.
3. Verify that *per-user* Windows Error Reporting (WER) is not disabled or redirected by confirming the registry settings in **HKCU\SOFTWARE\Microsoft\Windows\Windows Error Reporting** (or **HKCU\Software\Policies\Microsoft\Windows\DataCollection**, which will take precedence if set):
- Verify that the value "Disabled" (REG_DWORD), if set, is 0.
- Verify that the value "DontSendAdditionalData" (REG_DWORD), if set, is 0.
- Verify that the value "CorporateWERServer" (REG_SZ) is not configured.
4. Check that some other installed device, app, or crash monitoring solution is not intercepting crash events.
5. Wait 48 hours for activity to appear in the reports.
6. If you need additional troubleshooting, contact Microsoft Support.
### Upgrade Readiness shows many "Computers with outdated KB"
If you see a large number of devices reported as shown in this screenshot of the Upgrade Readiness tile:
[![Upgrade Readiness tile showing Computers with outdated KB datum in red box](images/outdated_outdated.png)](images/outdated_outdated.png)
On Windows 7 SP1 and Windows 8.1 devices, you must deploy the compatibility update as described in [Enrolling devices in Windows Analytics](windows-analytics-get-started.md).
Note that the compatibility update retains the same KB number when a new version is released, so even if the update is installed on your devices, *they might not be running the latest version*. The compatibility update is now a critical update, so you can check that the latest version is installed from your management tool.
### Upgrade Readiness shows many "Computers with incomplete data"
If you see a large number of devices reported as shown in this screenshot of the Upgrade Readiness tile:
[![Upgrade Readiness tile showing Computers with incomplete data datum in red box](images/outdated_incomplete.png)](images/outdated_incomplete.png)
Download the latest deployment script and run it on an affected device to check for issues. See the [Upgrade Readiness deployment script](../upgrade/upgrade-readiness-deployment-script.md) topic for information about obtaining and running the script, and for a description of the error codes that can be displayed. Remember to wait up to 48-72 hours to see the results.
See ["Understanding connectivity scenarios and the deployment script"](https://blogs.technet.microsoft.com/upgradeanalytics/2017/03/10/understanding-connectivity-scenarios-and-the-deployment-script/) on the Windows Analytics blog for a summary of setting the ClientProxy for the script, which will enable the script properly check for diagnostic data endpoint connectivity.
If this becomes a recurring issue, schedule a full inventory scan monthly, as per the device enrollment guidelines for deployment at scale.
### Upgrade Readiness doesn't show app inventory data on some devices
Upgrade Readiness only collects app inventory on devices that are not yet upgraded to the target operating system version specified in the Upgrade Readiness Overview blade. This is because Upgrade Readiness targets upgrade planning (for devices not yet upgraded).
### Upgrade Readiness doesn't show IE site discovery data from some devices
Double-check that IE site discovery opt-in has been configured in the deployment script. (See the [Upgrade Readiness deployment script](../upgrade/upgrade-readiness-deployment-script.md) topic for information about obtaining and running the script, and for a description of the error codes that can be displayed. See ["Understanding connectivity scenarios and the deployment script"](https://blogs.technet.microsoft.com/upgradeanalytics/2017/03/10/understanding-connectivity-scenarios-and-the-deployment-script/) on the Windows Analytics blog for a summary of setting the ClientProxy for the script, which will enable the script properly check for diagnostic data endpoint connectivity.)
Also, on Windows 10 devices remember that IE site discovery requires data diagnostics set to the Enhanced level.
There are two additional configurations to check:
1. Make sure Flip Ahead with Page Prediction is enabled. It can be configured at Internet Options -> Advanced -> Browsing -> Enable flip ahead with page prediction.
2. Make sure IE is not running in InPrivate mode.
Finally, Upgrade Readiness only collects IE site discovery data on devices that are not yet upgraded to the target operating system version specified in the Upgrade Readiness Overview blade. This is because Upgrade Readiness targets upgrade planning (for devices not yet upgraded).
>[!NOTE]
> IE site discovery is disabled on devices running Windows 7 and Windows 8.1 that are in Switzerland and EU countries.
### Device names not appearing for Windows 10 devices
Starting with Windows 10, version 1803, the device name is no longer collected by default and requires a separate opt-in. For more information, see [Enrolling devices in Windows Analytics](windows-analytics-get-started.md). Allowing device names to be collected can make it easier for you to identify individual devices that report problems. Without the device name, Windows Analytics can only label devices by a GUID that it generates.
### Custom log queries using the AbnormalShutdownCount field of Device Health show zero or lower than expected results
This issue affects custom queries of the Device Health data by using the **Logs > Search page** or API. It does not impact any of the built-in tiles or reports of the Device Health solution. The **AbnormalShutdownCount** field of the **DHOSReliability** data table represents abnormal shutdowns other than crashes, such as sudden power loss or holding down the power button.
We have identified an incompatibility between AbnormalShutdownCount and the Limited Enhanced diagnostic data level on Windows 10, versions 1709, 1803, and 1809. Such devices do not send the abnormal shutdown signal to Microsoft. You should not rely on AbnormalShutdownCount in your custom queries unless you use any one of the following workarounds:
- Upgrade devices to Windows 10, version 1903 when available. Participants in the Windows Insider program can preview this change using Windows Insider builds.
- Change the diagnostic data setting from devices running Windows 10, versions 1709, 1803, and 1809 normal Enhanced level instead of Limited Enhanced.
- Use alternative data from devices to track abnormal shutdowns. For example, you can forward abnormal shutdown events from the Windows Event Log to your Log Analytics workspace by using the Log Analytics agent. Suggested events to forward include:
- Log: System, ID: 41, Source: Kernel-Power
- Log System, ID: 6008, Source: EventLog
### Disable Upgrade Readiness
If you want to stop using Upgrade Readiness and stop sending diagnostic data to Microsoft, follow these steps:
1. Delete the Upgrade Readiness solution in Log Analytics workspace. In Log Analytics workspace. select **Solutions** > **Compatibility Assessment** > **Delete**.
2. Disable the Commercial Data Opt-in Key on computers running Windows 7 SP1 or 8.1. On computers running Windows 10, set the diagnostic data level to **Security**:
**Windows 7 and Windows 8.1**: Delete CommercialDataOptIn registry property from *HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection*
**Windows 10**: Follow the instructions in [Configure Windows diagnostic data in your organization](https://docs.microsoft.com/windows/privacy/configure-windows-diagnostic-data-in-your-organization).
3. If you enabled **Internet Explorer Site Discovery**, you can disable Internet Explorer data collection by setting the *IEDataOptIn* registry key to value "0". The IEDataOptIn key can be found under: *HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection*.
4. **Optional step:** You can also remove the “CommercialId” key from: "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection".
### Exporting large data sets
Azure Log Analytics is optimized for advanced analytics of large data sets and can efficiently generate summaries and analytics for them. The query language is not optimized (or intended) for returning large raw data sets and has built-in limits to protect against overuse. There are times when it might be necessary to get more data than this, but that should be done sparingly since this is not the intended way to use Azure Log Analytics. The following code snippet shows how to retrieve data from UAApp one “page” at a time:
```
let snapshot = toscalar(UAApp | summarize max(TimeGenerated));
let pageSize = 100000;
let pageNumber = 0;
UAApp
| where TimeGenerated == snapshot and IsRollup==true and RollupLevel=="Granular" and Importance == "Low install count"
| order by AppName, AppVendor, AppVersion desc
| serialize
| where row_number(0) >= (pageSize * pageNumber)
| take pageSize
```
## Other common questions
### What are the requirements and costs for Windows Analytics solutions?
| Windows Analytics solution| Windows license requirements | Windows version requirements | Minimum diagnostic data requirements |
|----------------------|-----------------------------------|------------------------------|------------------------------|
| Upgrade Readiness | No additional requirements | Windows 7 with Service Pack 1, Windows 8.1, Windows 10 | Basic level in most cases; Enhanced level to support Windows 10 app usage data and IE site discovery |
| Update Compliance | No additional requirements | Windows 10 | Basic level |
| Device Health | **Any** of the following licenses: <br>- Windows 10 Enterprise or Windows 10 Education per-device with active Software Assurance<br>- Windows 10 Enterprise E3 or E5 per-device or per-user subscription (including Microsoft 365 F1, E3, or E5)<br>- Windows 10 Education A3 or A5 (including Microsoft 365 Education A3 or A5)<br>- Windows VDA E3 or E5 per-device or per-user subscription<br>- Windows Server 2016 or later | Windows 10 | - For Windows 10 version 1709 or later: Enhanced (Limited)<br>- For earlier versions: Enhanced
>[!NOTE]
> Regarding licensing requirements for Device Health, you do not need per-seat licensing, but only enough licenses to cover your total device usage. For example, if you have 100 E3 licenses, you can monitor 100 devices with Device Health.
Beyond the cost of Windows operating system licenses, there is no additional cost for using Windows Analytics. Within Azure Log Analytics, Windows Analytics is "zero-rated;" this means it is excluded from data limits and costs regardless of the Azure Log Analytics pricing tier you have chosen. To be more specific, Azure Log Analytics is available in different pricing tiers as described in [Pricing - Log Analytics](https://azure.microsoft.com/pricing/details/log-analytics/).
- If you are using the free tier, which has a cap on the amount of data collected per day, the Windows Analytics data will not count towards this cap. You will be able to collect all the Windows Analytics data from your devices and still have the full cap available for collecting additional data from other sources.
- If you are using a paid tier that charges per GB of data collected, the Windows Analytics data will not be charged. You will be able to collect all the Windows Analytics data from your devices and not incur any costs.
Note that different Azure Log Analytics plans have different data retention periods, and the Windows Analytics solutions inherit the workspace's data retention policy. So, for example, if your workspace is on the free plan then Windows Analytics will retain the last week's worth of "daily snapshots" that are collected in the workspace.
### Why do SCCM and Upgrade Readiness show different counts of devices that are ready to upgrade?
System Center Configuration Manager (SCCM) considers a device ready to upgrade if *no installed app* has an upgrade decision of “not ready” (that is, they are all "ready" or "in progress"), while Upgrade Readiness considers a device ready to upgrade only if *all* installed apps are marked “ready”.
Currently, you can choose the criteria you wish to use:
- To use the SCCM criteria, create the collection of devices ready to upgrade within the SCCM console (using the analytics connector).
- To use the Upgrade Readiness criteria, export the list of ready-to-upgrade devices from the corresponding Upgrade Readiness report, and then build the SCCM collection from that spreadsheet.
### How does Upgrade Readiness collect the inventory of devices and applications?
For details about this process and some tips, see [How does Upgrade Readiness in WA collects application inventory for your OMS workspace?](https://techcommunity.microsoft.com/t5/Windows-Analytics-Blog/How-does-Upgrade-Readiness-in-WA-collects-application-inventory/ba-p/213586) on the Windows Analytics blog.
---
title: Frequently asked questions and troubleshooting Windows Analytics
ms.reviewer:
manager: laurawi
description: Frequently asked questions about Windows Analytics and steps to take when things go wrong
keywords: windows analytics, oms, operations management suite, prerequisites, requirements, updates, upgrades, log analytics, health, FAQ, problems, troubleshooting, error
ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: deploy
audience: itpro
author: greg-lindsay
ms.audience: itpro
author: greg-lindsay
ms.localizationpriority: medium
ms.collection: M365-analytics
ms.topic: article
---
# Frequently asked questions and troubleshooting Windows Analytics
>[!IMPORTANT]
>**The OMS portal has been deprecated; you should start using the [Azure portal](https://portal.azure.com) instead as soon as possible.** Many experiences are the same in the two portals, but there are some key differences. See [Windows Analytics in the Azure Portal](windows-analytics-azure-portal.md) for steps to use Windows Analytics in the Azure portal. For much more information about the transition from OMS to Azure, see [OMS portal moving to Azure](https://docs.microsoft.com/azure/log-analytics/log-analytics-oms-portal-transition).
This topic compiles the most common issues encountered with configuring and using Windows Analytics, as well as general questions. This FAQ, along with the [Windows Analytics Technical Community](https://techcommunity.microsoft.com/t5/Windows-Analytics/ct-p/WindowsAnalytics), are recommended resources to consult before contacting Microsoft support.
## Troubleshooting common problems
If you've followed the steps in the [Enrolling devices in Windows Analytics](windows-analytics-get-started.md) topic and are still encountering problems, you might find the solution here.
[Devices not appearing in Upgrade Readiness](#devices-not-appearing-in-upgrade-readiness)
[Devices not appearing in Device Health Device Reliability](#devices-not-appearing-in-device-health-device-reliability)
[Device crashes not appearing in Device Health Device Reliability](#device-crashes-not-appearing-in-device-health-device-reliability)
[Apps not appearing in Device Health App Reliability](#apps-not-appearing-in-device-health-app-reliability)
[Upgrade Readiness shows many "Computers with outdated KB"](#upgrade-readiness-shows-many-computers-with-outdated-kb)
[Upgrade Readiness shows many "Computers with incomplete data"](#upgrade-readiness-shows-many-computers-with-incomplete-data)
[Upgrade Readiness doesn't show app inventory data on some devices](#upgrade-readiness-doesnt-show-app-inventory-data-on-some-devices)
[Upgrade Readiness doesn't show IE site discovery data from some devices](#upgrade-readiness-doesnt-show-ie-site-discovery-data-from-some-devices)
[Device names not appearing for Windows 10 devices](#device-names-not-appearing-for-windows-10-devices)
[Custom log queries using the AbnormalShutdownCount field of Device Health show zero or lower than expected results](#custom-log-queries-using-the-abnormalshutdowncount-field-of-device-health-show-zero-or-lower-than-expected-results)
[Disable Upgrade Readiness](#disable-upgrade-readiness)
[Exporting large data sets](#exporting-large-data-sets)
### Devices not appearing in Upgrade Readiness
In Log Analytics workspace, go to **Solutions** and verify that you are subscribed to the Windows Analytics solutions you intend to use.
Even though devices can take 2-3 days after enrollment to show up due to latency in the system, you can now verify the status of your devices within a few hours of running the deployment script as described in [You can now check on the status of your computers within hours of running the deployment script](https://techcommunity.microsoft.com/t5/Windows-Analytics-Blog/You-can-now-check-on-the-status-of-your-computers-within-hours/ba-p/187213) on the Tech Community Blog.
>[!NOTE]
> If you generate the status report and get an error message saying "Sorry! We’re not recognizing your Commercial Id, See [Enrolling devices in Windows Analytics](https://docs.microsoft.com/windows/deployment/update/windows-analytics-get-started).
If devices are not showing up as expected, find a representative device and follow these steps to run the latest pilot version of the Upgrade Readiness deployment script on it to troubleshoot issues:
1. Download and extract the [Upgrade Readiness Deployment Script](https://www.microsoft.com/download/details.aspx?id=53327). Ensure that the **Pilot/Diagnostics** folder is included.
2. Edit the script as described in [Upgrade Readiness deployment script](../upgrade/upgrade-readiness-deployment-script.md).
3. Check that `isVerboseLogging` is set to `$true`.
4. Run the script again. Log files will be saved to the directory specified in the script.
5. Check the output of the script in the command window and/or log **UA_dateTime_machineName.txt** to ensure that all steps were completed successfully.
6. If you are still seeing errors you can't diagnose, then consider open a support case with Microsoft Support through your regular channel and provide this information.
If you want to check a large number of devices, you should run the latest script at scale from your management tool of choice (for example, System Center Configuration Manager) and check the results centrally.
If you think the issue might be related to a network proxy, check "Enable data sharing" section of the [Enrolling devices in Windows Analytics](windows-analytics-get-started.md) topic. Also see [Understanding connectivity scenarios and the deployment script](https://blogs.technet.microsoft.com/upgradeanalytics/2017/03/10/understanding-connectivity-scenarios-and-the-deployment-script/) on the Windows Analytics blog.
If you have deployed images that have not been generalized, then many of them might have the same ID and so Windows Analytics will see them as one device. If you suspect this is the issue, then you can reset the IDs on the non-generalized devices by performing these steps:
1. Net stop diagtrack
2. Reg delete hklm\software\microsoft\sqmclient /v MachineId /f
3. Net start diagtrack
#### Devices not appearing in Device Health Device Reliability
[![Device Reliability tile showing device count highlighted](images/device-reliability-device-count.png)](images/device-reliability-device-count.png)
If you have devices that appear in other solutions, but not Device Health (the Device Health overview tile shows "Performing Assessment" or the device count is lower than expected), follow these steps to investigate the issue:
1. Using the Azure portal, remove the Device Health (appears as DeviceHealthProd on some pages) solution from your Log Analytics workspace. After completing this, add the Device Health solution to you workspace again.
2. Confirm that the devices are running Windows 10.
3. Verify that the Commercial ID is present in the device's registry. For details see [https://gpsearch.azurewebsites.net/#13551](https://gpsearch.azurewebsites.net/#13551).
4. Confirm that devices are opted in to send diagnostic data by checking in the registry that **AllowTelemetry** is set to either 2 (Enhanced) or 3 (Full).
- **AllowTelemetry** under **HKLM\Software\Policies\Microsoft\Windows\DataCollection** is the IT policy path.
- **AllowTelemetry** under **HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\DataCollection** is the user preference (Settings app) path.
- IMPORTANT: By convention (and in earlier versions of Windows 10) the IT policy would take precedence over any user preference. Starting with Windows 10, version 1803, the user can lower the device's effective value even when an IT policy is set. This change assists organizations in complying with regional or organizational expectations about user control over privacy settings. For organizations where user control of privacy settings is not required, the previous behavior (IT policy path always wins) can be enabled using the new policy **Computer Configuration\Administrative Templates\Windows Components\Data Collection and Preview Builds\Configure telemetry opt-in setting user interface**.
5. Verify that devices can reach the endpoints specified in [Enrolling devices in Windows Analytics](windows-analytics-get-started.md). Also check settings for SSL inspection and proxy authentication; see [Configuring endpoint access with SSL inspection](https://docs.microsoft.com/windows/deployment/update/windows-analytics-get-started#configuring-endpoint-access-with-ssl-inspection) for more information.
6. Wait 48 hours for activity to appear in the reports.
7. If you need additional troubleshooting, contact Microsoft Support.
### Device crashes not appearing in Device Health Device Reliability
[![Device Reliability tile showing crash count highlighted](images/device-reliability-crash-count.png)](images/device-reliability-crash-count.png)
If you know that devices are experiencing stop error crashes that do not seem to be reflected in the count of devices with crashes, follow these steps to investigate the issue:
1. Verify that devices are reporting data properly by following the steps in the [Devices not appearing in Device Health Device Reliability](#devices-not-appearing-in-device-health-device-reliability) section of this topic.
2. Trigger a known crash on a test device by using a tool such as [NotMyFault](https://docs.microsoft.com/sysinternals/downloads/notmyfault) from Windows Sysinternals.
3. Verify that Windows Error Reporting (WER) is not disabled or redirected by confirming the registry settings in **HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting** (or **HKLM\Software\Policies\Microsoft\Windows\DataCollection**, which will take precedence if set):
- Verify that the value "Disabled" (REG_DWORD), if set, is 0.
- Verify that the value "DontSendAdditionalData" (REG_DWORD), if set, is 0.
- Verify that the value "CorporateWERServer" (REG_SZ) is not configured.
4. Verify that WER can reach all diagnostic endpoints specified in [Enrolling devices in Windows Analytics](windows-analytics-get-started.md)--if WER can only reach some of the endpoints, it could be included in the device count while not reporting crashes.
5. Check that crash reports successfully complete the round trip with Event 1001 and that BucketID is not blank. A typical such event looks like this:
[![Event viewer detail showing Event 1001 details](images/event_1001.png)](images/event_1001.png)
You can use the following Windows PowerShell snippet to summarize recent occurrences of Event 1001. Most events should have a value for BucketID (a few intermittent blank values are OK, however).
```powershell
$limitToMostRecentNEvents = 20
Get-WinEvent -FilterHashTable @{ProviderName="Windows Error Reporting"; ID=1001} |
?{ $_.Properties[2].Value -match "crash|blue" } |
% { [pscustomobject]@{
TimeCreated=$_.TimeCreated
WEREvent=$_.Properties[2].Value
BucketId=$_.Properties[0].Value
ContextHint = $(
if($_.Properties[2].Value -eq "bluescreen"){"kernel"}
else{ $_.Properties[5].Value }
)
}} | Select-Object -First $limitToMostRecentNEvents
```
The output should look something like this:
[![Typical output for this snippet](images/device-reliability-event1001-PSoutput.png)](images/device-reliability-event1001-PSoutput.png)
6. Check that some other installed device, app, or crash monitoring solution is not intercepting crash events.
7. Wait 48 hours for activity to appear in the reports.
8. If you need additional troubleshooting, contact Microsoft Support.
#### Endpoint connectivity
Devices must be able to reach the endpoints specified in [Enrolling devices in Windows Analytics](windows-analytics-get-started.md).
If you are using proxy server authentication, it's worth taking extra care to check the configuration. Prior to Windows 10, version 1703, WER only uploads error reports in the machine context, so whitelisting endpoints to allow non-authenticated access was typically used. In Windows 10, version 1703 and later versions, WER will attempt to use the context of the user that is logged on for proxy authentication such that only the user account requires proxy access.
For more information, see [Enrolling devices in Windows Analytics](windows-analytics-get-started.md#configuring-endpoint-access-with-proxy-server-authentication).
### Apps not appearing in Device Health App Reliability
[![App Reliability tile showing relability events trend](images/app-reliability.png)](images/app-reliability.png)
If apps that you know are crashing do not appear in App Reliability, follow these steps to investigate the issue:
1. Double-check the steps in the [Devices not appearing in Device Health Device Reliability](#devices-not-appearing-in-device-health-device-reliability) and [Device crashes not appearing in Device Health Device Reliability](#device-crashes-not-appearing-in-device-health-device-reliability) sections of this topic.
2. Confirm that an in-scope application has crashed on an enrolled device. Keep the following points in mind:
- Not all user-mode crashes are included in App Reliability, which tracks only apps that have a GUI, have been used interactively by a user, and are not part of the operating system.
- Enrolling more devices helps to ensure that there are enough naturally occurring app crashes.
- You can also use test apps which are designed to crash on demand.
3. Verify that *per-user* Windows Error Reporting (WER) is not disabled or redirected by confirming the registry settings in **HKCU\SOFTWARE\Microsoft\Windows\Windows Error Reporting** (or **HKCU\Software\Policies\Microsoft\Windows\DataCollection**, which will take precedence if set):
- Verify that the value "Disabled" (REG_DWORD), if set, is 0.
- Verify that the value "DontSendAdditionalData" (REG_DWORD), if set, is 0.
- Verify that the value "CorporateWERServer" (REG_SZ) is not configured.
4. Check that some other installed device, app, or crash monitoring solution is not intercepting crash events.
5. Wait 48 hours for activity to appear in the reports.
6. If you need additional troubleshooting, contact Microsoft Support.
### Upgrade Readiness shows many "Computers with outdated KB"
If you see a large number of devices reported as shown in this screenshot of the Upgrade Readiness tile:
[![Upgrade Readiness tile showing Computers with outdated KB datum in red box](images/outdated_outdated.png)](images/outdated_outdated.png)
On Windows 7 SP1 and Windows 8.1 devices, you must deploy the compatibility update as described in [Enrolling devices in Windows Analytics](windows-analytics-get-started.md).
Note that the compatibility update retains the same KB number when a new version is released, so even if the update is installed on your devices, *they might not be running the latest version*. The compatibility update is now a critical update, so you can check that the latest version is installed from your management tool.
### Upgrade Readiness shows many "Computers with incomplete data"
If you see a large number of devices reported as shown in this screenshot of the Upgrade Readiness tile:
[![Upgrade Readiness tile showing Computers with incomplete data datum in red box](images/outdated_incomplete.png)](images/outdated_incomplete.png)
Download the latest deployment script and run it on an affected device to check for issues. See the [Upgrade Readiness deployment script](../upgrade/upgrade-readiness-deployment-script.md) topic for information about obtaining and running the script, and for a description of the error codes that can be displayed. Remember to wait up to 48-72 hours to see the results.
See ["Understanding connectivity scenarios and the deployment script"](https://blogs.technet.microsoft.com/upgradeanalytics/2017/03/10/understanding-connectivity-scenarios-and-the-deployment-script/) on the Windows Analytics blog for a summary of setting the ClientProxy for the script, which will enable the script properly check for diagnostic data endpoint connectivity.
If this becomes a recurring issue, schedule a full inventory scan monthly, as per the device enrollment guidelines for deployment at scale.
### Upgrade Readiness doesn't show app inventory data on some devices
Upgrade Readiness only collects app inventory on devices that are not yet upgraded to the target operating system version specified in the Upgrade Readiness Overview blade. This is because Upgrade Readiness targets upgrade planning (for devices not yet upgraded).
### Upgrade Readiness doesn't show IE site discovery data from some devices
Double-check that IE site discovery opt-in has been configured in the deployment script. (See the [Upgrade Readiness deployment script](../upgrade/upgrade-readiness-deployment-script.md) topic for information about obtaining and running the script, and for a description of the error codes that can be displayed. See ["Understanding connectivity scenarios and the deployment script"](https://blogs.technet.microsoft.com/upgradeanalytics/2017/03/10/understanding-connectivity-scenarios-and-the-deployment-script/) on the Windows Analytics blog for a summary of setting the ClientProxy for the script, which will enable the script properly check for diagnostic data endpoint connectivity.)
Also, on Windows 10 devices remember that IE site discovery requires data diagnostics set to the Enhanced level.
There are two additional configurations to check:
1. Make sure Flip Ahead with Page Prediction is enabled. It can be configured at Internet Options -> Advanced -> Browsing -> Enable flip ahead with page prediction.
2. Make sure IE is not running in InPrivate mode.
Finally, Upgrade Readiness only collects IE site discovery data on devices that are not yet upgraded to the target operating system version specified in the Upgrade Readiness Overview blade. This is because Upgrade Readiness targets upgrade planning (for devices not yet upgraded).
>[!NOTE]
> IE site discovery is disabled on devices running Windows 7 and Windows 8.1 that are in Switzerland and EU countries.
### Device names not appearing for Windows 10 devices
Starting with Windows 10, version 1803, the device name is no longer collected by default and requires a separate opt-in. For more information, see [Enrolling devices in Windows Analytics](windows-analytics-get-started.md). Allowing device names to be collected can make it easier for you to identify individual devices that report problems. Without the device name, Windows Analytics can only label devices by a GUID that it generates.
### Custom log queries using the AbnormalShutdownCount field of Device Health show zero or lower than expected results
This issue affects custom queries of the Device Health data by using the **Logs > Search page** or API. It does not impact any of the built-in tiles or reports of the Device Health solution. The **AbnormalShutdownCount** field of the **DHOSReliability** data table represents abnormal shutdowns other than crashes, such as sudden power loss or holding down the power button.
We have identified an incompatibility between AbnormalShutdownCount and the Limited Enhanced diagnostic data level on Windows 10, versions 1709, 1803, and 1809. Such devices do not send the abnormal shutdown signal to Microsoft. You should not rely on AbnormalShutdownCount in your custom queries unless you use any one of the following workarounds:
- Upgrade devices to Windows 10, version 1903 when available. Participants in the Windows Insider program can preview this change using Windows Insider builds.
- Change the diagnostic data setting from devices running Windows 10, versions 1709, 1803, and 1809 normal Enhanced level instead of Limited Enhanced.
- Use alternative data from devices to track abnormal shutdowns. For example, you can forward abnormal shutdown events from the Windows Event Log to your Log Analytics workspace by using the Log Analytics agent. Suggested events to forward include:
- Log: System, ID: 41, Source: Kernel-Power
- Log System, ID: 6008, Source: EventLog
### Disable Upgrade Readiness
If you want to stop using Upgrade Readiness and stop sending diagnostic data to Microsoft, follow these steps:
1. Delete the Upgrade Readiness solution in Log Analytics workspace. In Log Analytics workspace. select **Solutions** > **Compatibility Assessment** > **Delete**.
2. Disable the Commercial Data Opt-in Key on computers running Windows 7 SP1 or 8.1. On computers running Windows 10, set the diagnostic data level to **Security**:
**Windows 7 and Windows 8.1**: Delete CommercialDataOptIn registry property from *HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection*
**Windows 10**: Follow the instructions in [Configure Windows diagnostic data in your organization](https://docs.microsoft.com/windows/privacy/configure-windows-diagnostic-data-in-your-organization).
3. If you enabled **Internet Explorer Site Discovery**, you can disable Internet Explorer data collection by setting the *IEDataOptIn* registry key to value "0". The IEDataOptIn key can be found under: *HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection*.
4. **Optional step:** You can also remove the “CommercialId” key from: "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\DataCollection".
### Exporting large data sets
Azure Log Analytics is optimized for advanced analytics of large data sets and can efficiently generate summaries and analytics for them. The query language is not optimized (or intended) for returning large raw data sets and has built-in limits to protect against overuse. There are times when it might be necessary to get more data than this, but that should be done sparingly since this is not the intended way to use Azure Log Analytics. The following code snippet shows how to retrieve data from UAApp one “page” at a time:
```
let snapshot = toscalar(UAApp | summarize max(TimeGenerated));
let pageSize = 100000;
let pageNumber = 0;
UAApp
| where TimeGenerated == snapshot and IsRollup==true and RollupLevel=="Granular" and Importance == "Low install count"
| order by AppName, AppVendor, AppVersion desc
| serialize
| where row_number(0) >= (pageSize * pageNumber)
| take pageSize
```
## Other common questions
### What are the requirements and costs for Windows Analytics solutions?
| Windows Analytics solution| Windows license requirements | Windows version requirements | Minimum diagnostic data requirements |
|----------------------|-----------------------------------|------------------------------|------------------------------|
| Upgrade Readiness | No additional requirements | Windows 7 with Service Pack 1, Windows 8.1, Windows 10 | Basic level in most cases; Enhanced level to support Windows 10 app usage data and IE site discovery |
| Update Compliance | No additional requirements | Windows 10 | Basic level |
| Device Health | **Any** of the following licenses: <br>- Windows 10 Enterprise or Windows 10 Education per-device with active Software Assurance<br>- Windows 10 Enterprise E3 or E5 per-device or per-user subscription (including Microsoft 365 F1, E3, or E5)<br>- Windows 10 Education A3 or A5 (including Microsoft 365 Education A3 or A5)<br>- Windows VDA E3 or E5 per-device or per-user subscription<br>- Windows Server 2016 or later | Windows 10 | - For Windows 10 version 1709 or later: Enhanced (Limited)<br>- For earlier versions: Enhanced
>[!NOTE]
> Regarding licensing requirements for Device Health, you do not need per-seat licensing, but only enough licenses to cover your total device usage. For example, if you have 100 E3 licenses, you can monitor 100 devices with Device Health.
Beyond the cost of Windows operating system licenses, there is no additional cost for using Windows Analytics. Within Azure Log Analytics, Windows Analytics is "zero-rated;" this means it is excluded from data limits and costs regardless of the Azure Log Analytics pricing tier you have chosen. To be more specific, Azure Log Analytics is available in different pricing tiers as described in [Pricing - Log Analytics](https://azure.microsoft.com/pricing/details/log-analytics/).
- If you are using the free tier, which has a cap on the amount of data collected per day, the Windows Analytics data will not count towards this cap. You will be able to collect all the Windows Analytics data from your devices and still have the full cap available for collecting additional data from other sources.
- If you are using a paid tier that charges per GB of data collected, the Windows Analytics data will not be charged. You will be able to collect all the Windows Analytics data from your devices and not incur any costs.
Note that different Azure Log Analytics plans have different data retention periods, and the Windows Analytics solutions inherit the workspace's data retention policy. So, for example, if your workspace is on the free plan then Windows Analytics will retain the last week's worth of "daily snapshots" that are collected in the workspace.
### Why do SCCM and Upgrade Readiness show different counts of devices that are ready to upgrade?
System Center Configuration Manager (SCCM) considers a device ready to upgrade if *no installed app* has an upgrade decision of “not ready” (that is, they are all "ready" or "in progress"), while Upgrade Readiness considers a device ready to upgrade only if *all* installed apps are marked “ready”.
Currently, you can choose the criteria you wish to use:
- To use the SCCM criteria, create the collection of devices ready to upgrade within the SCCM console (using the analytics connector).
- To use the Upgrade Readiness criteria, export the list of ready-to-upgrade devices from the corresponding Upgrade Readiness report, and then build the SCCM collection from that spreadsheet.
### How does Upgrade Readiness collect the inventory of devices and applications?
For details about this process and some tips, see [How does Upgrade Readiness in WA collects application inventory for your OMS workspace?](https://techcommunity.microsoft.com/t5/Windows-Analytics-Blog/How-does-Upgrade-Readiness-in-WA-collects-application-inventory/ba-p/213586) on the Windows Analytics blog.

2
windows/deployment/update/windows-update-errors.md
View File

@ -27,7 +27,7 @@ The following table provides information about common errors you might run into
| 0x8024402F | WU_E_PT_ECP_SUCCEEDED_WITH_ERRORS | External cab file processing completed with some errors | One of the reasons we see this issue is due to the design of a software called Lightspeed Rocket for Web filtering. <br>The IP addresses of the computers you want to get updates successfully on, should be added to the exceptions list of Lightspeed |
| 0x80242006 | WU_E_UH_INVALIDMETADATA | A handler operation could not be completed because the update contains invalid metadata. | Rename Software Redistribution Folder and attempt to download the updates again: <br>Rename the following folders to \*.BAK: <br>- %systemroot%\system32\catroot2 <br><br>To do this, type the following commands at a command prompt. Press ENTER after you type each command.<br>- Ren %systemroot%\SoftwareDistribution\DataStore \*.bak<br>- Ren %systemroot%\SoftwareDistribution\Download \*.bak<br>Ren %systemroot%\system32\catroot2 \*.bak |
| 0x80070BC9 | ERROR_FAIL_REBOOT_REQUIRED | The requested operation failed. A system reboot is required to roll back changes made. | Ensure that we do not have any policies that control the start behavior for the Windows Module Installer. This service should not be hardened to any start value and should be managed by the OS. |
| 0x80200053 | BG_E_VALIDATION_FAILED | NA | Ensure that there is no Firewalls that filter downloads. The Firewall filtering may lead to invalid responses being received by the Windows Update Client.<br><br>If the issue still persists, run the [WU reset script](https://gallery.technet.microsoft.com/scriptcenter/Reset-Windows-Update-Agent-d824badc). |
| 0x80200053 | BG_E_VALIDATION_FAILED | NA | Ensure that there is no Firewalls that filter downloads. The Firewall filtering may lead to invalid responses being received by the Windows Update Client.<br><br>If the issue still persists, run the [WU reset script](https://gallery.technet.microsoft.com/scriptcenter/Reset-Windows-Update-Agent-d824badc). |
| 0x80072EE2 | WININET_E_TIMEOUT | The operation timed out | This error message can be caused if the computer isn't connected to Internet. To fix this issue, following these steps: make sure these URLs are not blocked: <br> http://<em>.update.microsoft.com<br>https://</em>.update.microsoft.com <br><http://download.windowsupdate.com> <br><br>Additionally , you can take a network trace and see what is timing out. \<Refer to Firewall Troubleshooting scenario> |
| 0x80072EFD <br>0x80072EFE <br>0x80D02002 | TIME_OUT_ERRORS | The operation timed out | Make sure there are no firewall rules or proxy to block Microsoft download URLs. <br>Take a network monitor trace to understand better. \<Refer to Firewall Troubleshooting scenario> |
| 0X8007000D | ERROR_INVALID_DATA | Indicates invalid data downloaded or corruption occurred. | Attempt to re-download the update and initiate installation. |

11
windows/deployment/volume-activation/activate-forest-by-proxy-vamt.md
View File

@ -9,7 +9,8 @@ ms.prod: w10
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: activation
audience: itpro
audience: itpro
author: greg-lindsay
ms.date: 04/25/2017
ms.topic: article
---
@ -18,13 +19,13 @@ ms.topic: article
You can use the Volume Activation Management Tool (VAMT) Active Directory-Based Activation (ADBA) function to activate by proxy an Active Directory (AD) forest for an isolated workgroup that does not have Internet access. ADBA enables certain volume products to inherit activation from the domain.
**Important**  
> [!IMPORTANT]
> ADBA is only applicable to *Generic Volume License Keys (GVLKs)* and *KMS Host key (CSVLK)*. To use ADBA, one or more KMS Host keys (CSVLK) must be installed on the AD forest, and client keys (GVLKs) must be installed on the client products.
In a typical proxy-activation scenario, the VAMT host computer distributes a product key to one or more client computers and collects the installation ID (IID) from each computer. The VAMT host computer sends the IIDs to Microsoft on behalf of the client computers and obtains the corresponding Confirmation IDs (CIDs). The VAMT host computer then installs the CIDs on the client computer to complete the activation. If you use this activation method, only the VAMT host computer needs to have Internet access.
**Note**  
> [!NOTE]
> For workgroups that are isolated from any larger network, you can still perform an AD forest activation. This requires installing a second instance of VAMT on a computer in the isolated group and using removable media to transfer activation data between that computer and another VAMT host computer that has Internet access. You can also activate by proxy a KMS Host key (CSVLK) in the core network if you do not want the host computer to connect to Microsoft over the Internet.
## Requirements

2
windows/deployment/volume-activation/activate-using-active-directory-based-activation-client.md
View File

@ -46,7 +46,7 @@ The process proceeds as follows:
For environments in which all computers are running Windows 10, Windows 8.1, Windows 8, Windows Server 2012, or Windows Server 2012 R2, and they are joined to a domain, Active Directory-based activation is the best option for activating all client computers and servers, and you may be able to remove any KMS hosts from your environment.
If an environment will continue to contain earlier volume licensing operating systems and applications or if you have workgroup computers outside the domain, you need to maintain a KMS host to maintain activation status for earlier volume licensing editions of Windows and Office.
Clients that are activated with Active Directory-based activation will maintain their activated state for up to 180 days since the last contact with the domain, but they will periodically attempt to reactivate before then and at the end of the 180day period. By default, this reactivation event occurs every seven days.
Clients that are activated with Active Directory-based activation will maintain their activated state for up to 180 days since the last contact with the domain, but they will periodically attempt to reactivate before then and at the end of the 180 day period. By default, this reactivation event occurs every seven days.
When a reactivation event occurs, the client queries AD DS for the activation object. Client computers examine the activation object and compare it to the local edition as defined by the GVLK. If the object and GVLK match, reactivation occurs. If the AD DS object cannot be retrieved, client computers use KMS activation. If the computer is removed from the domain, when the computer or the Software Protection service is restarted, the operating system will change the status from activated to not activated, and the computer will try to activate with KMS.
## Step-by-step configuration: Active Directory-based activation
**Note**  

86
windows/deployment/windows-autopilot/autopilot-support.md
View File

@ -1,43 +1,43 @@
---
title: Windows Autopilot support
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.date: 10/31/2018
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: <br>Low – 120 hours <br>Normal – 72 hours <br>High – 24 hours <br>Immediate – 4 hours |
| Partners with a Partner Technology Strategist (PTS) | If you have a PTS (whether you’re a CSP or not), you may first try working through your account’s specific Partner Technology Strategist (PTS). |
| Partners with an Ecosystem PM | If you have an Ecosystem PM (whether you’re a CSP or not), you may first try working through your account’s specific Ecosystem PM, especially for technical issues. To learn more about Ecosystem PMs and the services they offer, contact epsoinfo@microsoft.com. |
| 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. |
| All other queries, or when unsure who to contact | Contact msoemops@microsoft.com. |
---
title: Windows Autopilot support
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.date: 10/31/2018
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: <br>Low – 120 hours <br>Normal – 72 hours <br>High – 24 hours <br>Immediate – 4 hours |
| Partners with a Partner Technology Strategist (PTS) | If you have a PTS (whether you’re a CSP or not), you may first try working through your account’s specific Partner Technology Strategist (PTS). |
| Partners with an Ecosystem PM | If you have an Ecosystem PM (whether you’re a CSP or not), you may first try working through your account’s specific Ecosystem PM, especially for technical issues. To learn more about Ecosystem PMs and the services they offer, contact epsoinfo@microsoft.com. |
| 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. |
| All other queries, or when unsure who to contact | Contact msoemops@microsoft.com. |

632
windows/deployment/windows-autopilot/existing-devices.md
View File

@ -1,315 +1,317 @@
---
title: Windows Autopilot for existing devices
description: 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
---
# 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
- System Center Configuration Manager Current Branch (1806) OR System Center Configuration Manager Technical Preview (1808)
- The [Windows ADK](https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit) 1803 or later
- Note: Config Mgr 1806 or later is required to [support](https://docs.microsoft.com/sccm/core/plan-design/configs/support-for-windows-10#windows-10-adk) the Windows ADK 1809.
- Assigned Microsoft Intune Licenses
- Azure Active Directory Premium
- Windows 10 version 1809 or later imported into Config Mgr as an Operating System Image
## 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/sccm/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)<br><br>
![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
```
3. Enter the following lines and provide Intune administrative credentials
- In the following command, replace the example user principal name for Azure authentication (admin@M365x373186.onmicrosoft.com) with your user account. Be sure that the user account you specify has sufficient administrative rights.
```powershell
Connect-AutopilotIntune -user admin@M365x373186.onmicrosoft.com
```
The password for your account will be requested using a standard Azure AD form. Type your password and then click **Sign in**.
<br>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)
<pre style="overflow-y: visible">
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"
}</pre>
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, e.g. 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. <br>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. <br> 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 an SCCM 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. <br><br>**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**.<br>
### 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:<br>
- <u>Name</u>: **Autopilot for existing devices config**
- Select the **This package contains source files** checkbox
- <u>Source folder</u>: Click **Browse** and specify a UNC path containing the AutopilotConfigurationFile.json file.
- Click **OK** and then click **Next**.
- <u>Program Type</u>: **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 Config Mgr 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:
- <u>Name</u>: **Autopilot for existing devices collection**
- Comment: (optional)
- <u>Limiting collection</u>: 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:
- <u>Task sequence name</u>: **Autopilot for existing devices**
- <u>Boot Image</u>: 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.
- <u>Product Key</u> and <u>Server licensing mode</u>: Optionally enter a product key and server licencing mode.
- <u>Randomly generate the local administrator password and disable the account on all support platforms (recommended)</u>: Optional.
- <u>Enable the account and specify the local administrator password</u>: 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 calls the System Preparation Tool (syeprep). This action will fail if the target machine is joined to a domain.
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]
>The Autopilot for existing devices task sequence will result in an Azure Active Directory Domain (AAD) joined device. The User State Migration Toolkit (USMT) does not support AAD joined or hybrid AAD 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:
- <u>Automatically build mass storage driver list</u>: **Not selected**
- <u>Do not reset activation flag</u>: **Not selected**
- <u>Shutdown the computer after running this action</u>: **Optional**
![Autopilot task sequence](images/ap-ts-1.png)
25. Click **OK** to close the Task Sequence Editor.
### 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 a 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:
- <u>Task Sequence</u>: **Autopilot for existing devices**.
- <u>Collection</u>: Click **Browse** and then select **Autopilot for existing devices collection** (or another collection you prefer).
- Click **Next** to specify **Deployment Settings**.
- <u>Action</u>: **Install**.
- <u>Purpose</u>: **Available**. You can optionally select **Required** instead of **Available**. This is not recommended during the test owing to the potential impact of inadvertent configurations.
- <u>Make available to the following</u>: **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.
- <u>Schedule when this deployment will become available</u>: Optional
- <u>Schedule when this deployment will expire</u>: Optional
- Click **Next** to specify **User Experience** details.
- <u>Show Task Sequence progress</u>: Selected.
- <u>Software Installation</u>: Not selected.
- <u>System restart (if required to complete the installation)</u>: Not selected.
- <u>Commit changed at deadline or during a maintenance windows (requires restart)</u>: Optional.
- <u>Allow task sequence to be run for client on the Internet</u>: Optional
- Click **Next** to specify **Alerts** details.
- <u>Create a deployment alert when the threshold is higher than the following</u>: Optional.
- Click **Next** to specify **Distribution Points** details.
- <u>Deployment options</u>: **Download content locally when needed by the running task sequence**.
- <u>When no local distribution point is available use a remote distribution point</u>: Optional.
- <u>Allow clients to use distribution points from the default site boundary group</u>: 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
---
title: Windows Autopilot for existing devices
description: 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
---
# 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
- System Center Configuration Manager Current Branch (1806) OR System Center Configuration Manager Technical Preview (1808)
- The [Windows ADK](https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit) 1803 or later
- Note: Config Mgr 1806 or later is required to [support](https://docs.microsoft.com/sccm/core/plan-design/configs/support-for-windows-10#windows-10-adk) the Windows ADK 1809.
- Assigned Microsoft Intune Licenses
- Azure Active Directory Premium
- Windows 10 version 1809 or later imported into Config Mgr 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/sccm/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)<br><br>
![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
```
3. Enter the following lines and provide Intune administrative credentials
- In the following command, replace the example user principal name for Azure authentication (admin@M365x373186.onmicrosoft.com) with your user account. Be sure that the user account you specify has sufficient administrative rights.
```powershell
Connect-AutopilotIntune -user admin@M365x373186.onmicrosoft.com
```
The password for your account will be requested using a standard Azure AD form. Type your password and then click **Sign in**.
<br>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)
<pre style="overflow-y: visible">
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"
}</pre>
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, e.g. 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. <br>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. <br> 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 an SCCM 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. <br><br>**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**.<br>
### 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:<br>
- <u>Name</u>: **Autopilot for existing devices config**
- Select the **This package contains source files** checkbox
- <u>Source folder</u>: Click **Browse** and specify a UNC path containing the AutopilotConfigurationFile.json file.
- Click **OK** and then click **Next**.
- <u>Program Type</u>: **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 Config Mgr 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:
- <u>Name</u>: **Autopilot for existing devices collection**
- Comment: (optional)
- <u>Limiting collection</u>: 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:
- <u>Task sequence name</u>: **Autopilot for existing devices**
- <u>Boot Image</u>: 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.
- <u>Product Key</u> and <u>Server licensing mode</u>: Optionally enter a product key and server licensing mode.
- <u>Randomly generate the local administrator password and disable the account on all support platforms (recommended)</u>: Optional.
- <u>Enable the account and specify the local administrator password</u>: 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 calls the System Preparation Tool (syeprep). This action will fail if the target machine is joined to a domain.
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]
>The Autopilot for existing devices task sequence will result in an Azure Active Directory Domain (AAD) joined device. The User State Migration Toolkit (USMT) does not support AAD joined or hybrid AAD 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:
- <u>Automatically build mass storage driver list</u>: **Not selected**
- <u>Do not reset activation flag</u>: **Not selected**
- <u>Shutdown the computer after running this action</u>: **Optional**
![Autopilot task sequence](images/ap-ts-1.png)
25. Click **OK** to close the Task Sequence Editor.
### 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 a 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:
- <u>Task Sequence</u>: **Autopilot for existing devices**.
- <u>Collection</u>: Click **Browse** and then select **Autopilot for existing devices collection** (or another collection you prefer).
- Click **Next** to specify **Deployment Settings**.
- <u>Action</u>: **Install**.
- <u>Purpose</u>: **Available**. You can optionally select **Required** instead of **Available**. This is not recommended during the test owing to the potential impact of inadvertent configurations.
- <u>Make available to the following</u>: **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.
- <u>Schedule when this deployment will become available</u>: Optional
- <u>Schedule when this deployment will expire</u>: Optional
- Click **Next** to specify **User Experience** details.
- <u>Show Task Sequence progress</u>: Selected.
- <u>Software Installation</u>: Not selected.
- <u>System restart (if required to complete the installation)</u>: Not selected.
- <u>Commit changed at deadline or during a maintenance windows (requires restart)</u>: Optional.
- <u>Allow task sequence to be run for client on the Internet</u>: Optional
- Click **Next** to specify **Alerts** details.
- <u>Create a deployment alert when the threshold is higher than the following</u>: Optional.
- Click **Next** to specify **Distribution Points** details.
- <u>Deployment options</u>: **Download content locally when needed by the running task sequence**.
- <u>When no local distribution point is available use a remote distribution point</u>: Optional.
- <u>Allow clients to use distribution points from the default site boundary group</u>: 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/).

114
windows/deployment/windows-autopilot/known-issues.md
View File

@ -1,46 +1,68 @@
---
title: Windows Autopilot known issues
ms.reviewer:
manager: laurawi
description: 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
<table>
<th>Issue<th>More information
<tr><td>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.
<td>Download and install the <a href="https://support.microsoft.com/help/4505903">KB4505903 update</a>. <br><br>See the section: <b>How to get this update</b> for information on specific release channels you can use to obtain the update.
<tr><td>White glove gives a red screen and the <b>Microsoft-Windows-User Device Registration/Admin</b> event log displays <b>HResult error code 0x801C03F3</b><td>This 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.<br>
<br>To obtain troubleshooting logs use: <b>Mdmdiagnosticstool.exe -area Autopilot;TPM -cab c:\autopilot.cab</b>
<tr><td>White glove gives a red screen<td>White glove is not supported on a VM.
<tr><td>Error importing Windows Autopilot devices from a .csv file<td>Ensure 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.
<tr><td>Windows Autopilot for existing devices does not follow the Autopilot OOBE experience.<td>Ensure that the JSON profile file is saved in <b>ANSI/ASCII</b> format, not Unicode or UTF-8.
<tr><td><b>Something went wrong</b> is displayed page during OOBE.<td>The client is likely unable to access all the required AAD/MSA-related URLs. For more information, see <a href="windows-autopilot-requirements.md#networking-requirements">Networking requirements</a>.
</table>
## Related topics
[Diagnose MDM failures in Windows 10](https://docs.microsoft.com/windows/client-management/mdm/diagnose-mdm-failures-in-windows-10)<br>
---
title: Windows Autopilot known issues
ms.reviewer:
manager: laurawi
description: 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
<table>
<th>Issue<th>More information
<tr><td>Windows Autopilot for existing devices does not work for Windows 10, version 1903; you see screens that you've disabled in your Windows Autopilot profile, such as the Windows 10 License Agreement screen.
<br>&nbsp;<br>
This happens because Windows 10, version 1903 deletes the AutopilotConfigurationFile.json file.
<td>To fix this issue: <ol><li>Edit the Configuration Manager task sequence and disable the <b>Prepare Windows for Capture</b> step.
<li>Add a new <b>Run command line</b> step that runs <b>c:\windows\system32\sysprep\sysprep.exe /oobe /reboot</b>.</ol>
<a href="https://oofhours.com/2019/09/19/a-challenge-with-windows-autopilot-for-existing-devices-and-windows-10-1903/">More information</a>
<tr><td>The following known issue will be resolved by installing the KB4517211 update, due to be released in late September 2019.
<br>&nbsp;<br>
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).
<td>Download and install the KB4517211 update</a>. <br><br>This update is currently pending release.
<tr><td>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.
<td>Download and install the <a href="https://support.microsoft.com/help/4512941">KB4512941 update</a>. <br><br>See the section: <b>How to get this update</b> for information on specific release channels you can use to obtain the update.
<tr><td>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.
<td>Download and install the <a href="https://support.microsoft.com/help/4505903">KB4505903 update</a>. <br><br>See the section: <b>How to get this update</b> for information on specific release channels you can use to obtain the update.
<tr><td>White glove gives a red screen and the <b>Microsoft-Windows-User Device Registration/Admin</b> event log displays <b>HResult error code 0x801C03F3</b><td>This 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.<br>
<br>To obtain troubleshooting logs use: <b>Mdmdiagnosticstool.exe -area Autopilot;TPM -cab c:\autopilot.cab</b>
<tr><td>White glove gives a red screen<td>White glove is not supported on a VM.
<tr><td>Error importing Windows Autopilot devices from a .csv file<td>Ensure 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.
<tr><td>Windows Autopilot for existing devices does not follow the Autopilot OOBE experience.<td>Ensure that the JSON profile file is saved in <b>ANSI/ASCII</b> format, not Unicode or UTF-8.
<tr><td><b>Something went wrong</b> is displayed page during OOBE.<td>The client is likely unable to access all the required AAD/MSA-related URLs. For more information, see <a href="windows-autopilot-requirements.md#networking-requirements">Networking requirements</a>.
</table>
## Related topics
[Diagnose MDM failures in Windows 10](https://docs.microsoft.com/windows/client-management/mdm/diagnose-mdm-failures-in-windows-10)<br>
[Troubleshooting Windows Autopilot](troubleshooting.md)

202
windows/deployment/windows-autopilot/user-driven.md
View File

@ -1,99 +1,103 @@
---
title: Windows Autopilot User-Driven Mode
description: 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
---
# 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, locale and keyboard.
- Connect it to a wireless or wired network with internet access.
- 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 supressed; see [Configuring Autopilot Profiles](profiles.md) for options that are available.
Today, Windows Autopilot user-driven mode supports joining devices to Azure Active Directory. Support for Hybrid Azure Active Directory Join (with devices joined to an on-premises Active Directory domain) will be available in a future Windows 10 release. 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.
## Available user-driven modes
The following options are available for user-driven deployment:
- [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.
### 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.
Also see the [Validation](#validation) section below.
### 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 Azure Active Directory (AAD) joined](https://docs.microsoft.com/azure/active-directory/devices/hybrid-azuread-join-plan).
#### Requirements
To perform a user-driven hybrid AAD 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.
**AAD device join**: The hybrid AAD join process uses the system context to perform device AAD join, therefore it is not affected by user based AAD join permission settings. In addition, all users are enabled to join devices to AAD by default.
#### Step by step instructions
See [Deploy hybrid Azure AD joined devices using Intune and Windows Autopilot](https://docs.microsoft.com/intune/windows-autopilot-hybrid).
Also see the **Validation** section in the [Windows Autopilot user-driven mode](user-driven.md) topic.
## Validation
When performing a user-driven deployment using Windows Autopilot, the following end-user experience should be observed:
- 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.
- Once connected to a network, the Autopilot profile will be downloaded.
- 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.
- Once correct credentials have been entered, the device will join Azure Active Directory.
- After joining Azure Active Directory, the device will enroll in Intune (or other configured MDM services).
- If configured, the [enrollment status page](enrollment-status.md) will be displayed.
- Once the device configuration tasks have completed, the user will be signed into Windows 10 using the credentials they previously provided.
- Once signed in, the enrollment status page will again be displayed for user-targeted configuration tasks.
---
title: Windows Autopilot User-Driven Mode
description: 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
---
# 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, locale and keyboard.
- Connect it to a wireless or wired network with internet access.
- 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.
Today, Windows Autopilot user-driven mode supports joining devices to Azure Active Directory. Support for Hybrid Azure Active Directory Join (with devices joined to an on-premises Active Directory domain) will be available in a future Windows 10 release. 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.
## Available user-driven modes
The following options are available for user-driven deployment:
- [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.
### 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.
Also see the [Validation](#validation) section below.
>[!NOTE]
>If the device reboots during the device enrollment status page (ESP) in the user-driven Azure Active Directoy join scenario, the user will not automatically sign on because the user's credentials cannot be saved across reboots. In this scenario, the user will need to sign in manually after the device ESP completes.
### 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 Azure Active Directory (AAD) joined](https://docs.microsoft.com/azure/active-directory/devices/hybrid-azuread-join-plan).
#### Requirements
To perform a user-driven hybrid AAD 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.
**AAD device join**: The hybrid AAD join process uses the system context to perform device AAD join, therefore it is not affected by user based AAD join permission settings. In addition, all users are enabled to join devices to AAD by default.
#### Step by step instructions
See [Deploy hybrid Azure AD joined devices using Intune and Windows Autopilot](https://docs.microsoft.com/intune/windows-autopilot-hybrid).
Also see the **Validation** section in the [Windows Autopilot user-driven mode](user-driven.md) topic.
## Validation
When performing a user-driven deployment using Windows Autopilot, the following end-user experience should be observed:
- 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.
- Once connected to a network, the Autopilot profile will be downloaded.
- 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.
- Once correct credentials have been entered, the device will join Azure Active Directory.
- After joining Azure Active Directory, the device will enroll in Intune (or other configured MDM services).
- If configured, the [enrollment status page](enrollment-status.md) will be displayed.
- Once the device configuration tasks have completed, the user will be signed into Windows 10 using the credentials they previously provided.
- Once signed in, the enrollment status page will again be displayed for user-targeted configuration tasks.
If your results do not match these expectations, see the [Windows Autopilot Troubleshooting](troubleshooting.md) documentation.