Merge branch 'master' of https://github.com/MicrosoftDocs/windows-docs-pr into tocideas

windows/deployment/deploy-whats-new.md

@@ -48,8 +48,8 @@ See [Deploy Windows 10 with Microsoft 365](deploy-m365.md) for an overview, whic
 ## Windows 10 servicing and support
 
 - [**Delivery Optimization**](https://docs.microsoft.com/windows/deployment/update/waas-delivery-optimization): Improved Peer Efficiency for enterprises and educational institutions with complex networks is enabled with of [new policies](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-deliveryoptimization). This now supports Microsoft 365 Apps for enterprise updates, and Intune content, with Microsoft Endpoint Configuration Manager content coming soon! 
-- [**Automatic Restart Sign-on (ARSO)**](https://docs.microsoft.com/windows-insider/at-work-pro/wip-4-biz-whats-new#automatic-restart-and-sign-on-arso-for-enterprises-build-18305): Windows will automatically logon as the user and lock their device in order to complete the update, ensuring that when the user returns and unlocks the device, the update will be completed.  
-- [**Windows Update for Business**](https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Windows-Update-for-Business-and-the-retirement-of-SAC-T/ba-p/339523): There will now be a single, common start date for phased deployments (no more SAC-T designation). In addition, there will a new notification and reboot scheduling experience for end users, the ability to enforce update installation and reboot deadlines, and the ability to provide end user control over reboots for a specific time period. 
+- [**Automatic Restart Sign-on (ARSO)**](https://docs.microsoft.com/windows-insider/at-work-pro/wip-4-biz-whats-new#automatic-restart-and-sign-on-arso-for-enterprises-build-18305): Windows will automatically log on as the user and lock their device in order to complete the update, ensuring that when the user returns and unlocks the device, the update will be completed.  
+- [**Windows Update for Business**](https://techcommunity.microsoft.com/t5/Windows-IT-Pro-Blog/Windows-Update-for-Business-and-the-retirement-of-SAC-T/ba-p/339523): There will now be a single, common start date for phased deployments (no more SAC-T designation). In addition, there will be a new notification and reboot scheduling experience for end users, the ability to enforce update installation and reboot deadlines, and the ability to provide end user control over reboots for a specific time period. 
 - **Update rollback improvements**: You can now automatically recover from startup failures by removing updates if the startup failure was introduced after the installation of recent driver or quality updates. When a device is unable to start up properly after the recent installation of Quality of driver updates, Windows will now automatically uninstall the updates to get the device back up and running normally.
 - **Pause updates**: We have extended the ability to pause updates for both feature and monthly updates. This extension ability is for all editions of Windows 10, including Home. You can pause both feature and monthly updates for up to 35 days (seven days at a time, up to five times). Once the 35-day pause period is reached, you will need to update your device before pausing again. 
 - **Improved update notifications**: When there’s an update requiring you to restart your device, you’ll see a colored dot on the Power button in the Start menu and on the Windows icon in your taskbar.

windows/deployment/deploy-windows-mdt/set-up-mdt-for-bitlocker.md

@@ -88,7 +88,6 @@ Following these steps, you enable the backup of BitLocker and TPM recovery infor
         3. Do not enable BitLocker until recovery information is stored in AD DS for operating system drives
     2. Enable the **Configure TPM platform validation profile for BIOS-based firmware configurations** policy.
     3. Enable the **Configure TPM platform validation profile for native UEFI firmware configurations** policy.
-        Computer Configuration / Policies / Administrative Templates / System / Trusted Platform Module Services
 
 > [!NOTE]
 > If you consistently get the error "Windows BitLocker Drive Encryption Information. The system boot information has changed since BitLocker was enabled. You must supply a BitLocker recovery password to start this system." after encrypting a computer with BitLocker, you might have to change the various "Configure TPM platform validation profile" Group Policies, as well. Whether or not you need to do this will depend on the hardware you are using.

windows/deployment/update/create-deployment-plan.md

@@ -136,4 +136,5 @@ For more about Desktop Analytics, see these articles:
 - [How to set up Desktop Analytics](https://docs.microsoft.com/mem/configmgr/desktop-analytics/set-up)
 - [Tutorial: Deploy Windows 10 to Pilot](https://docs.microsoft.com/mem/configmgr/desktop-analytics/tutorial-windows10)
 - [Desktop Analytics documentation](https://docs.microsoft.com/mem/configmgr/desktop-analytics/overview)
-- [Intune deployment planning, design, and implementation guide](https://docs.microsoft.com/mem/intune/fundamentals/planning-guide)
+- [Intune deployment planning, design, and implementation guide](https://docs.microsoft.com/mem/intune/fundamentals/planning-guide)
+

windows/deployment/update/eval-infra-tools.md

@@ -0,0 +1,71 @@
+---
+title: Evaluate infrastructure and tools
+ms.reviewer: 
+manager: laurawi
+description: 
+keywords: updates, servicing, current, deployment, semi-annual channel, feature, quality, rings, insider, tools
+ms.prod: w10
+ms.mktglfcycl: manage
+audience: itpro
+author: jaimeo
+ms.localizationpriority: medium
+ms.audience: itpro
+author: jaimeo
+ms.topic: article
+ms.collection: M365-modern-desktop
+---
+
+# Evaluate infrastructure and tools
+
+Before you deploy an update, it's best to assess your deployment infrastucture (that is, tools such as Configuration Manager, Microsoft Intune, or similar) and current configurations (such as security baselines, administrative templates, and policies that affect updates). Then, set some criteria to define your operational readiness.
+
+## Infrastructure
+
+Do your deployment tools need updates?
+
+- If you use Configuration Manager, is it on the Current Branch with the latest release installed. This ensures that it supports the next Windows 10 feature update. Configuration Manager releases are supported for 18 months.
+- Using a cloud-based management tool like Microsoft Intune reduces support challenges, since no related products need to be updated.
+- If you use a non-Microsoft tool, check with its product support to make sure you're using the current version and that it supports the next Windows 10 feature update.
+
+Rely on your experiences and data from previous deployments to help you judge how long infrastructure changes take and identify any problems you've encountered while doing so.
+
+## Device settings
+
+Make sure your security basline, administrative templates, and policies have the right settings to support your devices once the new Windows 10 update is installed.
+
+### Security baseline
+
+Keep security baslines current to help ensure that your environment is secure and that new security feature in the coming Windows 10 update are set properly.
+
+- **Microsoft security baselines**: You should implement security baselines from Microsoft. They are included in the [Security Compliance Toolkit](https://www.microsoft.com/download/details.aspx?id=55319), along with tools for managing them. 
+- **Industry- or region-specific baselines**: Your specific industry or region might have particular baselines that you must follow per regulations. Ensure that any new baselines support the version of Windows 10 you are about to deploy.
+
+### Configuration updates
+
+There are a number of Windows policies (set by Group Policy, Intune, or other methods) that affect when Windows updates are installed, deferral, end-user experience, and many other aspects. Check these policies to make sure they are set appropriately.
+
+- **Windows 10 Administrative templates**: Each Windows 10 feature update has a supporting Administrative template (.admx) file. Group Policy tools use Administrative template files to populate policy settings in the user interface. The templates are available in the Download Center, for example, this one for [Windows 10, version 1909](https://www.microsoft.com/download/100591).
+- **Policies for update compliance and end-user experience**: A number of settings affect when a device installs updates, whether and for how long a user can defer an update, restart behavior after installation, and many other aspects of update behavior. It's especially important to look for existing policies that are out of date or could conflict with new ones. {SET COMPLIANCE and other policies}
+
+
+## Define operational readiness criteria
+
+When you’ve deployed an update, you’ll need to make sure the update isn’t introducing new operational issues. And you’ll also ensure that if incidents arise, the needed documentation and processes are available. To achieve this, work with your operations and support team to define acceptable trends and what documents or processes require updating:
+
+- **Call trend**: Define what percentage increase in calls relating to Windows 10 feature updates are acceptable or can be supported.
+- **Incident trend**: Define what percentage of increase in calls asking for support relating to Windows 10 feature updates are acceptable or can be supported.
+- **Support documentation**: Review supporting documentation that requires an update to support new infrastructure tooling or configuration as part of the Windows 10 feature update.
+- **Process changes:** Define and update any processes that will change as a result of the Windows 10 feature update.
+
+Your operations and support staff can help you determine if the appropriate information is being tracked at the moment. If it isn't, work out how to get get this information so you can gain the right insight. 
+
+## Tasks
+
+Finally, you can begin to carry out the work needed to ensure your infrastructure and configuration can support the update. To help you keep track, you can classify the work into the following overarching tasks:
+
+- **Review infrastructure requirements**: Go over the details of requirements to support the update, and ensure they’ve all been defined.
+- **Validate infrastructure against requirements**: Compare your infrastructure against the requirements that have been identified for the update.
+- **Define infrastructure update plan**: Detail how your infrastructure must change to support the update.
+- **Review current support volume**: Understand the current support volume to understand how much of an effect the update has when it’s been deployed.
+- **Identify gaps that require attention**: Identify issues that will need to be addressed to successfully deploy the update. For example, will your infrastructure engineer have to research how a new feature that comes with the update might affect the infrastructure?
+- **Define operational update plan**: Detail how your operational services and processes must change to support the update.

windows/deployment/update/update-policies.md

@@ -0,0 +1,204 @@
+---
+title: Policies for update compliance, activity, and end-user experience
+ms.reviewer: 
+manager: laurawi
+description: 
+keywords: updates, servicing, current, deployment, semi-annual channel, feature, quality, rings, insider, tools
+ms.prod: w10
+ms.mktglfcycl: manage
+audience: itpro
+author: jaimeo
+ms.localizationpriority: medium
+ms.audience: itpro
+author: jaimeo
+ms.topic: article
+ms.collection: M365-modern-desktop
+---
+
+# Policies for update compliance, activity, and end-user experience
+Keeping devices up to date is the best way to keep them working smoothly and securely. 
+
+## Deadlines for update compliance
+
+You can control how strictly devices must reliably keep to your desired update schedule by using update deadline policies. Windows components adapt based on these deadlines. Also, they can make tradeoffs between user experience and velocity in order to meet your desired update deadlines. For example, they can prioritize user experience well before the
+deadline approaches, and then prioritize velocity as the deadline nears, while still affording the user some control.
+
+### Deadlines
+
+Beginning with Windows 10, version 1903 and with the August 2019 security update for Windows 10, version 1709
+and late, a new policy was introduced to replace older deadline-like policies: **Specify deadlines for automatic updates and restarts**.
+
+The older policies started enforcing deadlines once the device reached a “restart pending” state for
+an update. The new policy starts the countdown for the update installation deadline from when the
+update is published plus any deferral. In addition, this policy includes a configurable grace period and the option
+to opt out of automatic restarts until the deadline is reached (although we recommend always allowing automatic
+restarts for maximum update velocity).
+
+> [!IMPORTANT]
+> If you use the new **Specify deadlines for automatic updates and restarts** setting in Windows 10,
+> version 1903, you must disable the [older deadline policies](wufb-compliancedeadlines.md#prior-to-windows-10-version-1709) because they could conflict.
+
+We recommend you set deadlines as follows:
+- Quality update deadline, in days: 3
+- Feature update deadline, in days: 7
+- 
+Notifications are automatically presented to the user at appropriate times, and users can choose to be reminded
+later, to reschedule, or to restart immediately, depending on how close the deadline is. We recommend that you
+do **not** set any notification policies, because they are automatically configured with appropriate defaults. An exception is if you
+have kiosks or digital signage.
+
+While three days for quality updates and seven days for feature updates is our recommendation, you might decide
+you want more or less, depending on your organization and its requirements, and this policy is configurable down
+to a minimum of two days.
+
+
+> [!IMPORTANT]
+> If the device is unable to reach the Internet, it can't determine when Microsoft
+> published the update, so it won't be able to enforce the deadline. Learn more about [low activity devices](#device-activity-policies).
+
+### Grace periods
+
+You can set a period of days for Windows to find a minimally disruptive automatic restart time before the restart is enforced. This
+is especially useful in cases where a user has been away for many days (for example, on vacation) so that the device will not
+be forced to update immediately when the user returns.
+
+We recommend you set the following:
+
+- Grace period, in days: 2
+
+Once the deadline and grace period have passed, updates are applied automatically, and a restart occurs
+regardless of [active hours](#active-hours).
+
+
+### Let Windows choose when to restart
+
+Windows can use user interactions to dynamically identify the least disruptive time for an
+automatic restart. To take advantage of this feature, ensure **ConfigureDeadlineNoAutoReboot** is set to
+**Disabled**.
+
+## Device activity policies
+
+Windows typically requires that a device is active and connected to the internet for at least six hours, with at least two
+of continuous activity {HOW DO YOU DEFINE ACTIVITY?}, in order to successfully complete a system update. The device could have other
+physical circumstances that prevent successful installation of an update--for example, if a laptop is running low
+on battery power, or the user has shut down the device before active hours end and the device cannot comply
+with the deadline.
+
+You can use the settings in this section to ensure that devices are actually available to install updates during the update compliance period.
+
+### Active hours
+
+"Active hours" identify the period of time when a device is expected to be in use. Normally, restarts will occur outside of
+these hours. Windows 10, version 1903 introduced "intelligent active hours," which allow the system to learn active hours based on a user’s activities, rather than you as an administrator having to make decisions for your organization or allowing the user to choose active hours that minimize the period when the system can install an update.
+
+> [!IMPORTANT]
+> If you used the **Configure Active Hours** setting in previous versions of Windows 10, these
+options must be **Disabled** in order to take advantage of intelligent active hours.
+
+If you do set active hours, we recommend setting the following policies to **Disabled** in order to increase update
+velocity:
+
+- [Delay automatic reboot](waas-restart.md#delay-automatic-reboot). While it’s possible to set the system to delay restarts for users who are logged
+in, this might delay an update indefinitely if a user is always either logged in or shut down. Instead, we
+recommend setting the following polices to **Disabled**:
+    - **Turn off auto-restart during active hours**
+    - **No auto-restart with logged on users for scheduled automatic updates**
+
+    - [Limit restart delays](waas-restart.md#limit-restart-delays). By using compliance deadlines, your users will receive notifications that
+updates will occur, so we recommend that you set this policy to **Disabled**, to allow compliance deadlines to eliminate the user’s ability to delay a restart outside of compliance deadline settings.
+
+- **Do not allow users to approve updates and reboots**. Letting users approve or engage with the update process outside of the deadline policies decreases update velocity and increases risk. These policies should be set to **Disabled**:
+    - [Update/RequireUpdateApproval](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-update#update-requireupdateapproval)
+    - [Update/EngagedRestartDeadline](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-update#update-engagedrestartdeadline)
+    - [Update/EngagedRestartDeadlineForFeatureUpdates](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-update#update-engagedrestartdeadlineforfeatureupdates)
+    - [Update/EngagedRestartSnoozeSchedule](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-update#update-engagedrestartsnoozeschedule)
+    - [Update/EngagedRestartSnoozeScheduleForFeatureUpdates](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-update#update-engagedrestartsnoozescheduleforfeatureupdates)
+    - [Update/EngagedRestartTransitionSchedule](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-update#update-engagedrestarttransitionschedule)
+
+- [Configure automatic update](waas-wu-settings.md#configure-automatic-updates). By properly setting policies to configure automatic updates, you can increase update velocity by having clients contact a Windows Server Update Services (WSUS) server so it can manage them. We recommend that you set this policy to **Disabled**. However, if you need to provide values, ensure that you set downloads to install automatically by setting the [Group Policy](waas-manage-updates-wsus.md#configure-automatic-updates-and-update-service-location) to **4**. If you’re using Microsoft Intune, setting the value to [Reset to Default](https://docs.microsoft.com/mem/intune/protect/windows-update-settings#user-experience-settings).
+- **Allow auto Windows Update to download over metered networks**. Since more and more devices primarily use cellular data and do not have wi-fi access, consider allowing users to automatically download updates from a metered network. Though the default setting does not allow download over a metered network, setting this value to **1** can increase velocity by enabling users to get updates whether they are connected to the internet or not, provided they have cellular service. 
+
+> [!IMPORTANT]
+> Older versions of Windows don't support intelligent active hours. If your device runs a version of Windows prior to Windows 10, version 1903, we recommend setting the following policies:
+>- [Configure active hours](waas-restart.md#configure-active-hours). Starting with Windows 10, version 1703, you can specify a maximum active-hour range which is counted from the active hours start time. We recommend setting
+this value to **10**.
+>- [Schedule update installation](waas-restart.md#schedule-update-installation). In the **Configure Automatic Updates** settings, there are two ways to control a forced restart after a specified installation time. If you use **schedule update installation**, do not enable both settings because they will most likely conflict.
+>    - **Specify automatic maintenance time**. This setting lets you set broader maintenance windows for updates and ensures that this schedule does not conflict with active hours. We
+recommend setting this value to **3** (corresponding to 3 AM). If 3:00 AM is in the middle of the work shift, pick another time that is at least a couple hours before your scheduled work time begins.
+>    - **Schedule the install time**. This setting allows you to schedule an installation time for a restart. We do *not* recommend you set this to **Disabled** as it could conflict with active hours. 
+
+### Power policies
+
+Devices must actually be available during non-active hours in order to an update. They can't do this if power policies prevent them from waking up. In our organization, we strive to set a balance between security and eco-friendly configurations. We recommend the following settings to achieve what we feel are the appropriate tradeoffs:
+
+To a user, a device is either on or off, but for Windows, there are states that will allow an update to occur (active) and states that do not (inactive). Some states are considered active (sleep), but the user may think the device is off. Also, there are power statuses (plugged in/battery) that Windows checks before starting an update.
+
+You can override the default settings and prevent users from changing them in order to ensure that devices are available for updates during non-active hours.
+
+> [!NOTE]
+> One way to ensure that devices can install updates when you need them to is to educate your users to keep devices plugged in during non-active hours. Even with the best policies, a device that isn't plugged in will not be updated, even in sleep mode.
+
+We recommend these power management settings:
+
+- Sleep mode (S1 or S0 Low Power Idle or [Modern Standby](https://docs.microsoft.com/windows-hardware/design/device-experiences/modern-standby)). When a device is in sleep mode, the system
+appears to be off but if an update is available, it can wake the device up in order to take an update. The
+power consumption in sleep mode is between working (system fully usable) and hibernate (S4 - lowest
+power level before shutdown). When a device is not being used, the system will generally move to sleep
+mode before it goes to hibernate. Issues in velocity arise when the time between sleep and hibernate is
+too short and Windows does not have time to complete an update. Sleep mode is an important setting
+because the system can wake the system from sleep in order to start the update process, as long as there
+is enough power.
+
+Set the following policies to **Enable** or **Do Not Configure** in order to allow the device to use sleep mode:
+- [Power/AllowStandbyStatesWhenSleepingOnBattery](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-power#power-allowstandbystateswhensleepingonbattery)
+- [Power/AllowStandbyWhenSleepingPluggedIn](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-power#power-selectlidcloseactionpluggedin)
+
+Set the following policies to **1 (Sleep)** so that when a user closes the lid of a device, the system goes to
+sleep mode and the device has an opportunity to take an update:
+- [Power/SelectLidCloseActionOnBattery](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-power#power-selectlidcloseactiononbattery)
+- [Power/SelectLidCloseActionPluggedIn](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-power#power-selectlidcloseactionpluggedin)
+
+- **Hibernate**. When a device is hibernating, power consumption is very low and the system cannot wake up
+without user intervention, like pressing the power button. If a device is in this state, it cannot be updated
+unless it supports an ACPI Time and Alarm Device (TAD). That said, if a device supporting Traditional Sleep
+(S3) is plugged in, and a Windows update is available, a hibernate state will be delayed until the update is complete.
+
+> [!NOTE]
+> This does not apply to devices that support Modern Standby (S0 Low Power Idle). You can check which system sleep state (S3 or S0 Low Power Idle) a device supports by running `powercfg /a` at a command prompt. For more, see [Powercfg options](https://docs.microsoft.com/windows-hardware/design/device-experiences/powercfg-command-line-options#option_availablesleepstates).
+
+The default timeout on devices that support traditional sleep is set to three hours. We recommend that you do not reduce these policies in order to allow Windows Update the opportunity to restart the device before sending it into hibernation:
+
+- [Power/HibernateTimeoutOnBattery](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-power#power-hibernatetimeoutonbattery)
+- [Power/HibernateTimeoutPluggedIn](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-power#power-hibernatetimeoutpluggedin)
+
+## Old or conflicting policies
+
+Each release of Windows 10 can introduce new policies to make the experience better for both administrators and their organizations. When we release a new client policy, we either release it purely for that release and later or we backport the policy to make it available on earlier versions. 
+
+> [!IMPORTANT]
+> If you are using Group Policy, note that we don't update the old ADMX templates and you must use the newer (1903) ADMX template in order to use the newer policy. Also, if you are
+> using an MDM tool (Microsoft or non-Microsoft), you can't use the new policy until it's available in the tool interface.
+
+As administrators, you have set up and expect certain behaviors, so we expressly do not remove older policies since they were set up for your particular use cases. However, if you set a new policy without disabling a similar older policy, you could have conflicting behavior and updates might not perform as expected.
+
+> [!IMPORTANT] 
+> We sometimes find that administrators set devices to get both Group Policy settings and MDM settings from an MDM server such as Microsoft Intune. Policy conflicts are handled differently, depending on how they are ultimately set up:
+> - Windows updates: Group Policy settings take precedence over MDM.
+> - Microsoft Intune: If you set different values for the same policy on two different groups, you will
+> receive an alert and neither policy will be set until the conflict is resolved.
+> It is crucial that you disable conflicting policies in order for devices in your organization to take updates as
+> expected. For example, if a device is not reacting to your MDM policy changes, check to see if a similar
+> policy is set in Group Policy with a differing value.
+> If you find that update velocity is not as high as you expect or if some devices are slower than others, it might be
+> time to clear all polices and settings and specify only the recommended update policies. See the Policy and settings reference for a consolidated list of recommended polices.
+
+The following are policies that you might want to disable because they could decrease update velocity or there are better policies to use that might conflict:
+- **Defer Feature Updates Period in Days**. For maximum update velocity, it's best to set this to **0** (no
+deferral) so that the feature update can complete and monthly security updates will be offered again. Even if there is an urgent quality update that must be quickly deployed, it is best to use **Pause Feature
+Updates** rather than setting a deferral policy. You can choose a longer period if you don't want to stay up to date with the latest feature update.
+- **Defer Quality Updates Period in Days**. To minimize risk and maximize update velocity, the maximum time you might want to consider while evaluating the update with a different ring of devices is two to three days.
+- **Pause Feature Updates Start Time**. Set to **Disabled** unless there is a known issue requiring time for a resolution.
+- **Pause Quality Updates Start Time**. Set to **Disabled** unless there is a known issue requiring time for a resolution.
+- **Deadline No Auto Reboot**. Default is **Disabled – Set to 0** . We recommend that devices automatically try to restart when an update is received. Windows uses user interactions to dynamically identify the least disruptive time to restart.
+
+There are additional policies are no longer supported or have been superseded. See {LINK TO Policies and settings reference guide – Policies to disable or not configure} for more information.

windows/deployment/windows-autopilot/known-issues.md

@@ -29,6 +29,9 @@ ms.topic: article
 <tr><td>Blocking apps specified in a user-targeted Enrollment Status Profile are ignored during device ESP.</td>
 <td>The services responsible for determining the list of apps that should be blocking during device ESP are not able to determine the correct ESP profile containing the list of apps because they do not know the user identity.  As a workaround, enable the default ESP profile (which targets all users and devices) and place the blocking app list there.  In the future, it will be possible to instead target the ESP profile to device groups to avoid this issue.</tr>
 
+<tr><td>That username looks like it belongs to another organization. Try signing in again or start over with a different account.</td>
+  <td>Confirm that all of your information is correct at HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Provisioning\Diagnostics\AutoPilot. See <a href="https://docs.microsoft.com/windows/deployment/windows-autopilot/troubleshooting#windows-10-version-1709-and-above">Troubleshooting Windows Auto Pilot </a> for more details.</td></tr>
+
 <tr><td>Windows Autopilot user-driven Hybrid Azure AD deployments do not grant users Administrator rights even when specified in the Windows Autopilot profile.</td>
 <td>This will occur when there is another user on the device that already has Administrator rights.  For example, a PowerShell script or policy could create an additional local account that is a member of the Administrators group.  To ensure this works properly, do not create an additional account until after the Windows Autopilot process has completed.</tr>