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

Merge branch 'main' into cz-22020816-feedback

Browse Source
This commit is contained in:
David Strome
2022-09-16 16:49:57 -07:00
committed by GitHub
parent d0660c3811 7255cee98b
commit b9f47341a8
232 changed files with 3372 additions and 1429 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
windows/deployment/TOC.yml
View File

@ -263,7 +263,7 @@
href: update/update-compliance-schema-waasupdatestatus.md
- name: WaaSInsiderStatus
href: update/update-compliance-schema-waasinsiderstatus.md
- name: WaaSDepoymentStatus
- name: WaaSDeploymentStatus
href: update/update-compliance-schema-waasdeploymentstatus.md
- name: WUDOStatus
href: update/update-compliance-schema-wudostatus.md

2
windows/deployment/deploy-windows-to-go.md
View File

@ -33,7 +33,7 @@ The following is a list of items that you should be aware of before you start th
* When running a Windows To Go workspace, always shutdown the workspace before unplugging the drive.
* Configuration Manager SP1 and later includes support for user self-provisioning of Windows To Go drives. You can download Configuration Manager for evaluation from the [Microsoft TechNet Evaluation Center](https://go.microsoft.com/fwlink/p/?LinkId=618746). For more information on this deployment option, see [How to Provision Windows To Go in Configuration Manager](/previous-versions/system-center/system-center-2012-R2/jj651035(v=technet.10)).
* Configuration Manager SP1 and later includes support for user self-provisioning of Windows To Go drives. For more information on this deployment option, see [How to Provision Windows To Go in Configuration Manager](/previous-versions/system-center/system-center-2012-R2/jj651035(v=technet.10)).
* If you're planning on using a USB drive duplicator to duplicate Windows To Go drives, don't configure offline domain join or BitLocker on the drive.

8
windows/deployment/docfx.json
View File

@ -21,9 +21,8 @@
"files": [
"**/*.png",
"**/*.jpg",
"**/*.gif",
"**/*.pdf",
"**/*.vsdx"
"**/*.svg",
"**/*.gif"
],
"exclude": [
"**/obj/**",
@ -37,9 +36,6 @@
"recommendations": true,
"breadcrumb_path": "/windows/resources/breadcrumb/toc.json",
"uhfHeaderId": "MSDocsHeader-M365-IT",
"ms.technology": "windows",
"audience": "ITPro",
"ms.topic": "article",
"feedback_system": "GitHub",
"feedback_github_repo": "MicrosoftDocs/windows-itpro-docs",
"feedback_product_url": "https://support.microsoft.com/windows/send-feedback-to-microsoft-with-the-feedback-hub-app-f59187f8-8739-22d6-ba93-f66612949332",

BIN
windows/deployment/media/Windows10AutopilotFlowchart.pdf
View File

Binary file not shown.

BIN
windows/deployment/media/Windows10Autopilotflowchart.vsdx
View File

Binary file not shown.

BIN
windows/deployment/media/Windows10DeploymentConfigManager.pdf
View File

Binary file not shown.

BIN
windows/deployment/media/Windows10DeploymentConfigManager.vsdx
View File

Binary file not shown.

11
windows/deployment/planning/windows-10-enterprise-faq-itpro.yml
View File

@ -50,10 +50,10 @@ sections:
- For some devices, Windows 10 may be unable to install drivers that are required for operation. If your device drivers aren't automatically installed, visit the manufacturer's support website for your device to download and manually install the drivers. If Windows 10 drivers aren't available, the most up-to-date drivers for Windows 8.1 will often work in Windows 10.
- For some devices, the manufacturer may provide more up-to-date drivers or drivers that enable more functionality than the drivers installed by Windows 10. Always follow the recommendations of the device manufacturer for optimal performance and stability.
- Some computer manufacturers provide packs of drivers for easy implementation in management and deployment solutions like the Microsoft Deployment Toolkit (MDT) or Microsoft Endpoint Configuration Manager. These driver packs contain all of the drivers needed for each device and can greatly simplify the process of deploying Windows to a new make or model of computer. Driver packs for some common manufacturers include:
- [HP driver pack](http://www8.hp.com/us/en/ads/clientmanagement/drivers-pack.html)
- [Dell driver packs for enterprise client OS deployment](http://en.community.dell.com/techcenter/enterprise-client/w/wiki/2065.dell-command-deploy-driver-packs-for-enterprise-client-os-deployment)
- [Lenovo Configuration Manager and MDT package index](https://support.lenovo.com/us/en/documents/ht074984)
- [Panasonic Driver Pack for Enterprise](http://pc-dl.panasonic.co.jp/itn/drivers/driver_packages.html)
- [HP driver pack](https://www.hp.com/us-en/solutions/client-management-solutions/drivers-pack.html)
- [Dell driver packs for enterprise client OS deployment](https://www.dell.com/support/kbdoc/en-us/000124139/dell-command-deploy-driver-packs-for-enterprise-client-os-deployment)
- [Lenovo Configuration Manager and MDT package index](https://support.lenovo.com/us/en/solutions/ht074984)
- [Panasonic Driver Pack for Enterprise](https://pc-dl.panasonic.co.jp/itn/drivers/driver_packages.html)
- question: |
Where can I find out if an application or device is compatible with Windows 10?
@ -125,7 +125,7 @@ sections:
answer: |
For an overview of the new enterprise features in Windows 10 Enterprise, see [What's new in Windows 10](/windows/whats-new/) and [What's new in Windows 10, version 1703](/windows/whats-new/whats-new-windows-10-version-1703) in the Docs library.
Another place to track the latest information about new features of interest to IT professionals is the [Windows for IT Pros blog](https://blogs.technet.microsoft.com/windowsitpro/). Here you'll find announcements of new features, information on updates to the Windows servicing model, and details about the latest resources to help you more easily deploy and manage Windows 10.
Another place to track the latest information about new features of interest to IT professionals is the [Windows for IT Pros blog](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/bg-p/Windows10Blog). Here you'll find announcements of new features, information on updates to the Windows servicing model, and details about the latest resources to help you more easily deploy and manage Windows 10.
To find out which version of Windows 10 is right for your organization, you can also [compare Windows editions](https://www.microsoft.com/WindowsForBusiness/Compare).
@ -152,4 +152,3 @@ sections:
- If you're an IT professional or if you have a question about administering, managing, or deploying Windows 10 in your organization or business, visit the [Windows 10 IT Professional forums](https://social.technet.microsoft.com/forums/home?category=windows10itpro) on TechNet.
- If you're an end user or if you have a question about using Windows 10, visit the [Windows 10 forums on Microsoft Community](https://answers.microsoft.com/windows/forum).
- If you're a developer or if you have a question about making apps for Windows 10, visit the [Windows Desktop Development forums](https://social.msdn.microsoft.com/forums/en-us/home?category=windowsdesktopdev).
- If you have a question about Internet Explorer, visit the [Internet Explorer forums](https://social.technet.microsoft.com/forums/ie/en-us/home).

2
windows/deployment/update/update-compliance-schema-waasdeploymentstatus.md
View File

@ -22,7 +22,7 @@ WaaSDeploymentStatus records track a specific update's installation progress on
|**DeferralDays** |[int](/azure/kusto/query/scalar-data-types/int) |`0` |The deferral policy for this content type or `UpdateCategory` (Windows `Feature` or `Quality`). |
|**DeploymentError** |[string](/azure/kusto/query/scalar-data-types/string) |`Disk Error` |A readable string describing the error, if any. If empty, there's either no string matching the error or there's no error. |
|**DeploymentErrorCode** |[int](/azure/kusto/query/scalar-data-types/int) |`8003001E` |Microsoft internal error code for the error, if any. If empty, there's either no error or there's *no error code*, meaning that the issue raised doesn't correspond to an error, but some inferred issue. |
|**DeploymentStatus** |[string](/azure/kusto/query/scalar-data-types/string) |`Failed` |The high-level status of installing this update on this device. Possible values are:<br><li> **Update completed**: Device has completed the update installation.<li> **In Progress**: Device is in one of the various stages of installing an update, detailed in `DetailedStatus`.<li> **Deferred**: A device's deferral policy is preventing the update from being offered by Windows Update.<li> **Canceled**: The update was canceled.<li> **Blocked**: There's a hard block on the update being completed. This could be that another update must be completed before this one, or some other task is blocking the installation of the update.<li> **Unknown**: Update Compliance generated WaaSDeploymentStatus records for devices as soon as it detects an update newer than the one installed on the device. Devices that haven't sent any deployment data for that update will have the status `Unknown`.<li> **Update paused**: Devices are paused via Windows Update for Business Pause policies, preventing the update from being offered by Windows Update. <li> **Failed**: Device encountered a failure in the update process, preventing it from installing the update. This may result in an automatic retry in the case of Windows Update, unless the `DeploymentError` indicates the issue requires action before the update can continue.|
|**DeploymentStatus** |[string](/azure/kusto/query/scalar-data-types/string) |`Failed` |The high-level status of installing this update on this device. Possible values are:<br><li> **Update completed**: Device has completed the update installation.<li> **In Progress**: Device is in one of the various stages of installing an update, detailed in `DetailedStatus`.<li> **Deferred**: A device's deferral policy is preventing the update from being offered by Windows Update.<li> **Canceled**: The update was canceled.<li> **Blocked**: There's a hard block on the update being completed. This could be that another update must be completed before this one, or some other task is blocking the installation of the update.<li> **Unknown**: Update Compliance generated WaaSDeploymentStatus records for devices as soon as it detects an update newer than the one installed on the device. Devices that haven't sent any deployment data for that update will have the status `Unknown`.<li> **Update paused**: Devices are paused via Windows Update for Business Pause policies, preventing the update from being offered by Windows Update. <li> **Failed**: Device encountered a failure in the update process, preventing it from installing the update. This may result in an automatic retry in the case of Windows Update, unless the `DeploymentError` indicates the issue requires action before the update can continue.<li> **Progress stalled**: The update is in progress, but has not completed over a period of 7 days.|
|**DetailedStatus** |[string](/azure/kusto/query/scalar-data-types/string) |`Reboot required` |A detailed status for the installation of this update on this device. Possible values are:<br><li> **Not Started**: Update hasn't started because the device isn't targeting the latest 2 builds<li> **Update deferred**: When a device's Windows Update for Business policy dictates the update is deferred.<li> **Update paused**: The device's Windows Update for Business policy dictates the update is paused from being offered.<li> **Update offered**: The device has been offered the update, but hasn't begun downloading it.<li> **Pre-Download tasks passed**: The device has finished all necessary tasks prior to downloading the update.<li> **Compatibility hold**: The device has been placed under a *compatibility hold* to ensure a smooth feature update experience and won't resume the update until the hold has been cleared. For more information, see [Feature Update Status report](update-compliance-feature-update-status.md#safeguard-holds).<li> **Download started**: The update has begun downloading on the device.<li> **Download Succeeded**: The update has successfully completed downloading. <li> **Pre-Install Tasks Passed**: Tasks that must be completed prior to installing the update have been completed.<li> **Install Started**: Installation of the update has begun.<li> **Reboot Required**: The device has finished installing the update, and a reboot is required before the update can be completed.<li> **Reboot Pending**: The device has a scheduled reboot to apply the update.<li> **Reboot Initiated**: The scheduled reboot has been initiated.<li> **Commit**: Changes are being committed post-reboot. This is another step of the installation process.<li> **Update Completed**: The update has successfully installed.|
|**ExpectedInstallDate** |[datetime](/azure/kusto/query/scalar-data-types/datetime)|`3/28/2020, 1:00:01.318 PM`|Rather than the expected date this update will be installed, this should be interpreted as the minimum date Windows Update will make the update available for the device. This takes into account Deferrals. |
|**LastScan** |[datetime](/azure/kusto/query/scalar-data-types/datetime)|`3/22/2020, 1:00:01.318 PM`|The last point in time that this device sent Update Session data. |

79
windows/deployment/update/update-compliance-v2-configuration-mem.md
View File

@ -9,7 +9,7 @@ ms.author: mstewart
ms.localizationpriority: medium
ms.collection: M365-analytics
ms.topic: article
ms.date: 06/06/2022
ms.date: 08/24/2022
---
# Configuring Microsoft Endpoint Manager devices for Update Compliance (preview)
@ -29,48 +29,79 @@ This article is specifically targeted at configuring devices enrolled to [Micros
## Create a configuration profile
Take the following steps to create a configuration profile that will set required policies for Update Compliance:
Create a configuration profile that will set the required policies for Update Compliance. There are two profile types that can be used to create a configuration profile for Update Compliance:
- The [settings catalog](#settings-catalog)
- [Template](#custom-oma-uri-based-profile) for a custom OMA URI based profile
1. Go to the Admin portal in Endpoint Manager and navigate to **Devices/Windows/Configuration profiles**.
1. On the **Configuration profiles** view, select **Create a profile**.
### Settings catalog
1. Go to the Admin portal in Endpoint Manager and navigate to **Devices** > **Windows** > **Configuration profiles**.
1. On the **Configuration profiles** view, select **Create profile**.
1. Select **Platform**="Windows 10 and later" and **Profile type**="Settings Catalog", and then select **Create**.
1. You're now on the Configuration profile creation screen. On the **Basics** tab, give a **Name** and **Description**.
1. On the **Configuration settings** page, you'll be adding multiple settings from the **System** category. Using the **Settings picker**, select the **System** category, then add the following settings and values:
1. Required settings for Update Compliance:
- **Setting**: Allow Commercial Data Pipeline
- **Value**: Enabled
- **Setting**: Allow Telemetry
- **Value**: Basic (*Basic is the minimum value, but it can be safely set to a higher value*)
- **Setting**: Allow Update Compliance Processing
- **Value**: Enabled
1. (*Recommended, but not required*) Add settings for **disabling devices' Diagnostic Data opt-in settings interface**. If these aren't disabled, users of each device can potentially override the diagnostic data level of devices such that data won't be available for those devices in Update Compliance:
- **Setting**: Configure Telemetry Opt In Change Notification
- **Value**: Disable telemetry change notifications
- **Setting**: Configure Telemetry Opt In Settings Ux
- **Value**: Disable Telemetry opt-in Settings
1. (*Recommended, but not required*) Allow device name to be sent in Windows Diagnostic Data. If this policy is disabled, the device name won't be sent and won't be visible in Update Compliance:
- **Setting**: Allow device name to be sent in Windows diagnostic data
- **Value**: Allowed
1. Proceed through the next set of tabs **Scope tags**, **Assignments**, and **Applicability Rules** to assign the configuration profile to devices you wish to enroll.
1. Review the settings and then select **Create**.
### Custom OMA URI based profile
1. Go to the Admin portal in Endpoint Manager and navigate to **Devices** > **Windows** > **Configuration profiles**.
1. On the **Configuration profiles** view, select **Create profile**.
1. Select **Platform**="Windows 10 and later" and **Profile type**="Templates".
1. For **Template name**, select **Custom**, and then press **Create**.
1. For **Template name**, select **Custom**, and then select **Create**.
1. You're now on the Configuration profile creation screen. On the **Basics** tab, give a **Name** and **Description**.
1. On the **Configuration settings** page, you'll be adding multiple OMA-URI Settings that correspond to the policies described in [Manually configuring devices for Update Compliance](update-compliance-v2-configuration-manual.md).
1. Add a setting to **Allow commercial data pipeline**; this policy is required for Update Compliance:
- **Name**: Allow commercial data pipeline
- **Description**: Configures Microsoft to be the processor of the Windows diagnostic data collected from an Azure Active Directory-joined device.
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowCommercialDataPipeline`
- **Data type**: Integer
- **Value**: 1
1. Add a setting configuring the **Windows Diagnostic Data level** for devices:
- **Name**: Allow Telemetry
- **Description**: Sets the maximum allowed diagnostic data to be sent to Microsoft, required for Update Compliance.
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowTelemetry`
- **Data type**: Integer
- **Value**: 1 (*all that is required is 1, but it can be safely set to a higher value*).
1. (*Recommended, but not required*) Add a setting for **disabling devices' Diagnostic Data opt-in settings interface**. If this isn't disabled, users of each device can potentially override the diagnostic data level of devices such that data won't be available for those devices in Update Compliance:
- **Name**: Disable Telemetry opt-in interface
- **Description**: Disables the ability for end-users of devices can adjust diagnostic data to levels lower than defined by the Allow Telemetry setting.
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/ConfigureTelemetryOptInSettingsUx`
- **Data type**: Integer
- **Value**: 1
1. Add a setting to **Allow device name in diagnostic data**; otherwise, there will be no device name in Update Compliance:
- **Name**: Allow device name in Diagnostic Data
- **Description**: Allows device name in Diagnostic Data.
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowDeviceNameInDiagnosticData`
- **Data type**: Integer
- **Value**: 1
- **Value**: 1 (*1 is the minimum value meaning basic, but it can be safely set to a higher value*).
1. Add a setting to **Allow Update Compliance processing**; this policy is required for Update Compliance:
- **Name**: Allow Update Compliance Processing
- **Description**: Opts device data into Update Compliance processing. Required to see data.
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowUpdateComplianceProcessing`
- **Data type**: Integer
- **Value**: 16
1. Add a setting to **Allow commercial data pipeline**; this policy is required for Update Compliance:
- **Name**: Allow commercial data pipeline
- **Description**: Configures Microsoft to be the processor of the Windows diagnostic data collected from an Azure Active Directory-joined device.
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowCommercialDataPipeline`
1. (*Recommended, but not required*) Add settings for **disabling devices' Diagnostic Data opt-in settings interface**. If these aren't disabled, users of each device can potentially override the diagnostic data level of devices such that data won't be available for those devices in Update Compliance:
- **Name**: Disable Telemetry opt-in interface
- **Description**: Disables the ability for end-users of devices can adjust diagnostic data to levels lower than defined by the Allow Telemetry setting.
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/ConfigureTelemetryOptInSettingsUx`
- **Data type**: Integer
- **Value**: 1
1. (*Recommended, but not required*) Add a setting to **Allow device name in diagnostic data**; otherwise, the device name won't be in Update Compliance:
- **Name**: Allow device name in Diagnostic Data
- **Description**: Allows device name in Diagnostic Data.
- **OMA-URI**: `./Vendor/MSFT/Policy/Config/System/AllowDeviceNameInDiagnosticData`
- **Data type**: Integer
- **Value**: 1
1. Proceed through the next set of tabs **Scope tags**, **Assignments**, and **Applicability Rules** to assign the configuration profile to devices you wish to enroll.
1. Review and select **Create**.
1. Review the settings and then select **Create**.
## Deploy the configuration script

2
windows/deployment/update/update-compliance-v2-help.md
View File

@ -86,7 +86,7 @@ If you create an issue for something not related to documentation, Microsoft wil
- [Product questions (using Microsoft Q&A)](/answers/products/)
- [Support requests](#open-a-microsoft-support-case) for Update Compliance
To share feedback on the fundamental docs.microsoft.com platform, see [Docs feedback](https://aka.ms/sitefeedback). The platform includes all of the wrapper components such as the header, table of contents, and right menu. Also how the articles render in the browser, such as the font, alert boxes, and page anchors.
To share feedback about the Microsoft Docs platform, see [Microsoft Docs feedback](https://aka.ms/sitefeedback). The platform includes all of the wrapper components such as the header, table of contents, and right menu. Also how the articles render in the browser, such as the font, alert boxes, and page anchors.
## Troubleshooting tips

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

@ -17,6 +17,8 @@ ms.collection: highpri
- Windows 10
- Windows 11
<p class="alert is-flex is-primary"><span class="has-padding-left-medium has-padding-top-extra-small"><a class="button is-primary" href="https://vsa.services.microsoft.com/v1.0/?partnerId=7d74cf73-5217-4008-833f-87a1a278f2cb&flowId=DMC&initialQuery=31806295" target='_blank'><b>Try our Virtual Agent</b></a></span><span class="has-padding-small"> - It can help you quickly identify and fix common Windows Update issues</span>
The following table provides information about common errors you might run into with Windows Update, as well as steps to help you mitigate them.
## 0x8024402F

2
windows/deployment/upgrade/troubleshoot-upgrade-errors.md
View File

@ -18,6 +18,8 @@ ms.topic: article
> This is a 300 level topic (moderately advanced).<br>
> See [Resolve Windows 10 upgrade errors](resolve-windows-10-upgrade-errors.md) for a full list of topics in this article.
<p class="alert is-flex is-primary"><span class="has-padding-left-medium has-padding-top-extra-small"><a class="button is-primary" href="https://vsa.services.microsoft.com/v1.0/?partnerId=7d74cf73-5217-4008-833f-87a1a278f2cb&flowId=DMC&initialQuery=31806293" target='_blank'><b>Try our Virtual Agent</b></a></span><span class="has-padding-small"> - It can help you quickly identify and fix common Windows boot issues</span>
If a Windows 10 upgrade is not successful, it can be very helpful to understand *when* an error occurred in the upgrade process.
> [!IMPORTANT]

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

@ -1,50 +1,44 @@
---
title: Activate using Active Directory-based activation (Windows 10)
description: Learn how active directory-based activation is implemented as a role service that relies on AD DS to store activation objects.
ms.custom: seo-marvel-apr2020
title: Activate using Active Directory-based activation
description: Learn how active directory-based activation is implemented as a role service that relies on AD DS to store activation objects.
manager: dougeby
ms.author: aaroncz
ms.prod: w10
author: aczechowski
ms.author: aaroncz
ms.prod: windows-client
ms.technology: itpro-deploy
ms.localizationpriority: medium
ms.date: 01/13/2022
ms.topic: article
ms.date: 09/16/2022
ms.topic: how-to
ms.collection: highpri
---
# Activate using Active Directory-based activation
**Applies to**
**Applies to supported versions of**
Windows 11
Windows 10
Windows 8.1
Windows 8
Windows Server 2012 R2
Windows Server 2012
Windows Server 2016
Windows Server 2019
Office 2021*
Office 2019*
Office 2016*
Office 2013*
- Windows
- Windows Server
- Office
**Looking for retail activation?**
> [!TIP]
> Are you looking for information on retail activation?
>
> - [Product activation for Windows](https://support.microsoft.com/windows/product-activation-for-windows-online-support-telephone-numbers-35f6a805-1259-88b4-f5e9-b52cccef91a0)
> - [Activate Windows](https://support.microsoft.com/windows/activate-windows-c39005d4-95ee-b91e-b399-2820fda32227)
- [Get Help Activating Microsoft Windows 7 or Windows 8.1](https://support.microsoft.com/help/15083/windows-activate-windows-7-or-8-1)
- [Get Help Activating Microsoft Windows 10](https://support.microsoft.com/help/12440/windows-10-activate)
Active Directory-based activation is implemented as a role service that relies on AD DS to store activation objects. Active Directory-based activation requires that you update the forest schema using *adprep.exe* on a supported server OS. After the schema is updated, older domain controllers can still activate clients.
Active Directory-based activation is implemented as a role service that relies on AD DS to store activation objects. Active Directory-based activation requires that the forest schema be updated using *adprep.exe* on a supported server OS, but after the schema is updated, older domain controllers can still activate clients.
Any domain-joined computers running a supported OS with a Generic Volume License Key (GVLK) will be activated automatically and transparently. They'll stay activated as long as they remain members of the domain and maintain periodic contact with a domain controller. Activation takes place after the Licensing service starts. When this service starts, the computer contacts AD DS automatically, receives the activation object, and is activated without user intervention.
Any domain-joined computers running a supported operating system with a Generic Volume License Key (GVLK) will be activated automatically and transparently. They will stay activated as long as they remain members of the domain and maintain periodic contact with a domain controller. Activation takes place after the Licensing service starts. When this service starts, the computer contacts AD DS automatically, receives the activation object, and is activated without user intervention.
To allow computers with GVLKs to activate themselves, use the Volume Activation Tools console or the [Volume Activation Management Tool (VAMT)](volume-activation-management-tool.md) in earlier versions of Windows Server to create an object in the AD DS forest. You create this activation object by submitting a KMS host key to Microsoft, as shown in Figure 10.
To allow computers with GVLKs to activate themselves, use the Volume Activation Tools console or the [Volume Activation Management Tool (VAMT)](volume-activation-management-tool.md) in earlier versions of Windows Server to create an object in the AD DS forest. You create this activation object by submitting a KMS host key to Microsoft, as shown in Figure 10.
The process proceeds as follows:
1. Perform one of the following tasks:
- Install the Volume Activation Services server role on a domain controller and add a KMS host key by using the Volume Activation Tools Wizard.
- Extend the domain to the Windows Server 2012 R2 or higher schema level, and add a KMS host key by using the VAMT.
1. Do _one_ of the following tasks:
- Install the Volume Activation Services server role on a domain controller. Then add a KMS host key by using the Volume Activation Tools Wizard.
- Extend the domain schema level to Windows Server 2012 R2 or later. Then add a KMS host key by using the VAMT.
2. Microsoft verifies the KMS host key, and an activation object is created.
@ -55,87 +49,91 @@ The process proceeds as follows:
**Figure 10**. The Active Directory-based activation flow
For environments in which all computers are running an operating system listed under *Applies to*, 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.
For environments in which all computers are running a supported OS version, and they're joined to a domain, Active Directory-based activation is the best option for activating all client computers and servers. 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.
If an environment will continue to contain earlier versions of volume licensed operating systems and applications, or if you have workgroup computers outside the domain, you need to maintain a KMS host to maintain activation status.
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.
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. They'll 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, and 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.
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 can't be retrieved, client computers use KMS activation. If the computer is removed from the domain, and the computer or the Software Protection service is restarted, Windows will change the status to "not activated" and the computer will try to activate with KMS.
## Step-by-step configuration: Active Directory-based activation
> [!NOTE]
> You must be a member of the local Administrators group on all computers mentioned in these steps. You also need to be a member of the Enterprise Administrators group, because setting up Active Directory-based activation changes forest-wide settings.
> You must be a member of the local **Administrators** group on all computers mentioned in these steps. You also need to be a member of the **Enterprise Administrators** group, because setting up Active Directory-based activation changes forest-wide settings.
**To configure Active Directory-based activation on Windows Server 2012 R2 or higher, complete the following steps:**
To configure Active Directory-based activation on a supported version of Windows Server, complete the following steps:
1. Use an account with Domain Administrator and Enterprise Administrator credentials to sign in to a domain controller.
1. Use an account with **Domain Administrator** and **Enterprise Administrator** credentials to sign in to a domain controller.
2. Launch Server Manager.
2. Launch **Server Manager**.
3. Add the Volume Activation Services role, as shown in Figure 11.
3. Add the **Volume Activation Services** role, as shown in Figure 11.
![Adding the Volume Activation Services role.](../images/volumeactivationforwindows81-11.jpg)
**Figure 11**. Adding the Volume Activation Services role
4. Click the link to launch the Volume Activation Tools (Figure 12).
4. Select the **Volume Activation Tools**, as shown in Figure 12.
![Launching the Volume Activation Tools.](../images/volumeactivationforwindows81-12.jpg)
**Figure 12**. Launching the Volume Activation Tools
5. Select the **Active Directory-Based Activation** option (Figure 13).
5. Select the **Active Directory-Based Activation** option, as shown in Figure 13.
![Selecting Active Directory-Based Activation.](../images/volumeactivationforwindows81-13.jpg)
**Figure 13**. Selecting Active Directory-Based Activation
6. Enter your KMS host key and (optionally) a display name (Figure 14).
6. Enter your KMS host key and optionally specify a display name, as shown in Figure 14.
![Choosing how to activate your product.](../images/volumeactivationforwindows81-15.jpg)
**Figure 14**. Entering your KMS host key
7. Activate your KMS host key by phone or online (Figure 15).
7. Activate your KMS host key by phone or online, as shown in Figure 15.
![Entering your KMS host key.](../images/volumeactivationforwindows81-14.jpg)
**Figure 15**. Choosing how to activate your product
> [!NOTE]
> To activate a KMS Host Key (CSVLK) for Microsoft Office, you need to install the version-specific Office Volume License Pack on the server where the Volume Activation Server Role is installed. For more details, see [Activate volume licensed versions of Office by using Active Directory](/deployoffice/vlactivation/activate-office-by-using-active-directory).
>
>
> To activate a KMS Host Key (CSVLK) for Microsoft Office, you need to install the version-specific Office Volume License Pack on the server where the Volume Activation Server Role is installed.
>
> - [Office 2013 VL pack](https://www.microsoft.com/download/details.aspx?id=35584)
>
>
> - [Office 2016 VL pack](https://www.microsoft.com/download/details.aspx?id=49164)
>
> - [Office 2019 VL pack](https://www.microsoft.com/download/details.aspx?id=57342)
>
> - [Office LTSC 2021 VL pack](https://www.microsoft.com/download/details.aspx?id=103446)
>
> For more information, see [Activate volume licensed versions of Office by using Active Directory](/deployoffice/vlactivation/activate-office-by-using-active-directory).
8. After activating the key, click **Commit**, and then click **Close**.
8. After activating the key, select **Commit**, and then select **Close**.
## Verifying the configuration of Active Directory-based activation
To verify your Active Directory-based activation configuration, complete the following steps:
1. After you configure Active Directory-based activation, start a computer that is running an edition of Windows that is configured by volume licensing.
2. If the computer has been previously configured with a MAK key, replace the MAK key with the GVLK by running the **slmgr.vbs /ipk** command and specifying the GLVK as the new product key.
3. If the computer is not joined to your domain, join it to the domain.
1. After you configure Active Directory-based activation, start a computer that is running an edition of Windows that's configured by volume licensing.
2. If the computer has been previously configured with a MAK key, replace the MAK key with the GVLK. Run the `slmgr.vbs /ipk` command and specifying the GLVK as the new product key.
3. If the computer isn't joined to your domain, join it to the domain.
4. Sign in to the computer.
5. Open Windows Explorer, right-click **Computer**, and then click **Properties**.
5. Open Windows Explorer, right-click **Computer**, and then select **Properties**.
6. Scroll down to the **Windows activation** section, and verify that this client has been activated.
> [!NOTE]
> If you are using both KMS and Active Directory-based activation, it may be difficult to see whether a client has been activated by KMS or by Active Directory-based activation. Consider disabling KMS during the test, or make sure that you are using a client computer that has not already been activated by KMS. The **slmgr.vbs /dlv** command also indicates whether KMS has been used.
>
> To manage individual activations or apply multiple (mass) activations, please consider using the [VAMT](./volume-activation-management-tool.md).
> If you're using both KMS and Active Directory-based activation, it may be difficult to see whether a client has been activated by KMS or by Active Directory-based activation. Consider disabling KMS during the test, or make sure that you are using a client computer that hasn't already been activated by KMS. The `slmgr.vbs /dlv` command also indicates whether KMS has been used.
>
> To manage individual activations or apply multiple (mass) activations, use the [VAMT](./volume-activation-management-tool.md).
## See also
- [Volume Activation for Windows 10](volume-activation-windows-10.md)
[Volume Activation for Windows 10](volume-activation-windows-10.md)

63
windows/deployment/volume-activation/introduction-vamt.md
View File

@ -4,61 +4,62 @@ description: VAMT enables administrators to automate and centrally manage the Wi
ms.reviewer:
manager: dougeby
ms.author: aaroncz
ms.prod: w10
ms.prod: windows-client
ms.technology: itpro-deploy
author: aczechowski
ms.date: 04/25/2017
ms.topic: article
ms.date: 09/16/2022
ms.topic: overview
---
# Introduction to VAMT
The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows®, Microsoft® Office®, and select other Microsoft products volume and retail activation process. VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in and can be installed on any computer that has one of the following Windows operating systems: Windows® 7, Windows 8, Windows 8.1, Windows 10, Windows Server 2008 R2, or Windows Server 2012.
The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows, Office, and select other Microsoft products volume and retail activation process. VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in and can be installed on any computer that has a supported Windows OS version.
> [!NOTE]
> VAMT can be installed on, and can manage, physical or virtual instances. VAMT cannot detect whether or not the remote products are virtual. As long as the products can respond to Windows Management Instrumentation (WMI) calls, they will be discovered and activated.
> VAMT can be installed on, and can manage, physical or virtual instances. VAMT can't detect whether or not the remote products are virtual. As long as the products can respond to Windows Management Instrumentation (WMI) calls, they will be discovered and activated.
## In this Topic
- [Managing Multiple Activation Key (MAK) and Retail Activation](#bkmk-managingmak)
- [Managing Key Management Service (KMS) Activation](#bkmk-managingkms)
- [Enterprise Environment](#bkmk-enterpriseenvironment)
- [VAMT User Interface](#bkmk-userinterface)
## <a href="" id="bkmk-managingmak"></a>Managing Multiple Activation Key (MAK) and Retail Activation
## <a href="" id="bkmk-managingmak"></a>Managing MAK and retail activation
You can use a MAK or a retail product key to activate Windows, Windows Server, or Office on an individual computer or a group of computers. VAMT enables two different activation scenarios:
- **Online activation.** Many enterprises maintain a single Windows system image or Office installation package for deployment across the enterprise. Occasionally there is also a need to use retail product keys in special situations. Online activation enables you to activate over the Internet any products installed with MAK, KMS host, or retail product keys on one or more connected computers within a network. This process requires that each product communicate activation information directly to Microsoft.
- **Proxy activation.** This activation method enables you to perform volume activation for products installed on client computers that do not have Internet access. The VAMT host computer distributes a MAK, KMS Host key (CSVLK), or retail product key to one or more client products and collects the installation ID (IID) from each client product. The VAMT host sends the IIDs to Microsoft on behalf of the client products and obtains the corresponding Confirmation IDs (CIDs). The VAMT host then installs the CIDs on the client products to complete the activation. Using this method, only the VAMT host computer needs Internet access. You can also activate products installed on computers in a workgroup that is isolated from any larger network, by installing a second instance of VAMT on a computer within the workgroup. Then, use removable media to transfer activation data between this new instance of VAMT and the Internet-connected VAMT host.
- **Online activation**: Many organizations maintain a single Windows system image or Office installation package for deployment across the organization. Occasionally there's also a need to use retail product keys in special situations. Online activation enables you to activate over the internet any products installed with MAK, KMS host, or retail product keys on one or more connected computers within a network. This process requires that each product communicate activation information directly to Microsoft.
## <a href="" id="bkmk-managingkms"></a>Managing Key Management Service (KMS) Activation
- **Proxy activation**: This activation method enables you to perform volume activation for products installed on client computers that don't have internet access. The VAMT host computer distributes a MAK, KMS host key (CSVLK), or retail product key to one or more client products and collects the installation ID (IID) from each client product. The VAMT host sends the IIDs to Microsoft on behalf of the client products and obtains the corresponding Confirmation IDs (CIDs). The VAMT host then installs the CIDs on the client products to complete the activation. Using this method, only the VAMT host computer needs internet access. You can also activate products installed on computers in a workgroup that's isolated from any larger network, by installing a second instance of VAMT on a computer within the workgroup. Then, use removable media to transfer activation data between this new instance of VAMT and the internet-connected VAMT host.
In addition to MAK or retail activation, you can use VAMT to perform volume activation using the Key Management Service (KMS). VAMT can install and activate GVLK (KMS client) keys on client products. GVLKs are the default product keys used by Volume License editions of Windows Vista, Windows 7, Windows 8, Windows 10, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012 and Microsoft Office 2010.\
VAMT treats a KMS Host key (CSVLK) product key identically to a retail-type product key; therefore, the experience for product key entry and activation management are identical for both these product key types.
## <a href="" id="bkmk-managingkms"></a>Managing KMS activation
## <a href="" id="bkmk-enterpriseenvironment"></a>Enterprise Environment
In addition to MAK or retail activation, you can use VAMT to perform volume activation using the KMS. VAMT can install and activate GVLK (KMS client) keys on client products. GVLKs are the default product keys used by volume license editions of Windows, Windows Server, and Office.
VAMT is commonly implemented in enterprise environments. The following screenshot illustrates three common environments—Core Network, Secure Zone, and Isolated Lab.
VAMT treats a KMS host key (CSVLK) product key identically to a retail-type product key. The experience for product key entry and activation management are identical for both these product key types.
## <a href="" id="bkmk-enterpriseenvironment"></a>Enterprise environment
VAMT is commonly implemented in enterprise environments. The following screenshot illustrates three common environments: core network, secure zone, and isolated lab.
![VAMT in the enterprise.](images/dep-win8-l-vamt-image001-enterprise.jpg)
In the Core Network environment, all computers are within a common network managed by Active Directory® Domain Services (AD DS). The Secure Zone represents higher-security Core Network computers that have extra firewall protection.
The Isolated Lab environment is a workgroup that is physically separate from the Core Network, and its computers do not have Internet access. The network security policy states that no information that could identify a specific computer or user may be transferred out of the Isolated Lab.
- In the core network environment, all computers are within a common network managed by Active Directory Domain Services (AD DS).
- The secure zone represents higher-security core network computers that have extra firewall protection.
- The isolated lab environment is a workgroup that is physically separate from the core network, and its computers don't have internet access. The network security policy states that no information that could identify a specific computer or user may be transferred out of the isolated lab.
## <a href="" id="bkmk-userinterface"></a>VAMT User Interface
## <a href="" id="bkmk-userinterface"></a>VAMT user interface
The following screenshot shows the VAMT graphical user interface.
The following screenshot shows the VAMT graphical user interface:
![VAMT user interface.](images/vamtuserinterfaceupdated.jpg)
VAMT provides a single, graphical user interface for managing activations, and for performing other activation-related tasks such as:
- **Adding and removing computers.** You can use VAMT to discover computers in the local environment. VAMT can discover computers by querying AD DS, workgroups, by individual computer name or IP address, or via a general LDAP query.
- **Discovering products.** You can use VAMT to discover Windows, Windows Server, Office, and select other products installed on the client computers.
- **Monitoring activation status.** You can collect activation information about each product, including the last five characters of the product key being used, the current license state (such as Licensed, Grace, Unlicensed), and the product edition information.
- **Managing product keys.** You can store multiple product keys and use VAMT to install these keys to remote client products. You can also determine the number of activations remaining for MAKs.
- **Managing activation data.** VAMT stores activation data in a SQL database. VAMT can export this data to other VAMT hosts or to an archive in XML format.
- **Adding and removing computers**: You can use VAMT to discover computers in the local environment. VAMT can discover computers by querying AD DS, workgroups, by individual computer name or IP address, or via a general LDAP query.
## Related topics
- **Discovering products**: You can use VAMT to discover Windows, Windows Server, Office, and select other products installed on the client computers.
- [VAMT Step-by-Step Scenarios](vamt-step-by-step.md)
- **Monitoring activation status**: You can collect activation information about each product, including the last five characters of the product key being used, the current license state (such as Licensed, Grace, Unlicensed), and the product edition information.
- **Managing product keys**: You can store multiple product keys and use VAMT to install these keys to remote client products. You can also determine the number of activations remaining for MAKs.
- **Managing activation data**: VAMT stores activation data in a SQL database. VAMT can export this data to other VAMT hosts or to an archive in XML format.
## Next steps
[VAMT step-by-step scenarios](vamt-step-by-step.md)

40
windows/deployment/volume-activation/volume-activation-management-tool.md
View File

@ -1,40 +1,36 @@
---
title: Volume Activation Management Tool (VAMT) Technical Reference (Windows 10)
title: VAMT technical reference
description: The Volume Activation Management Tool (VAMT) enables network administrators to automate and centrally manage volume activation and retail activation.
manager: dougeby
ms.author: aaroncz
ms.prod: w10
ms.prod: windows-client
ms.technology: itpro-deploy
author: aczechowski
ms.date: 04/25/2017
ms.topic: article
ms.date: 09/16/2022
ms.topic: overview
ms.custom: seo-marvel-apr2020
ms.collection: highpri
---
# Volume Activation Management Tool (VAMT) Technical Reference
# Volume Activation Management Tool (VAMT) technical reference
The Volume Activation Management Tool (VAMT) enables network administrators and other IT professionals to automate and centrally manage the Windows&reg;, Microsoft&reg; Office, and select other Microsoft products volume and retail-activation process.
VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in that requires the Microsoft Management Console (MMC) 3.0. VAMT can be installed on any computer that has one of the following Windows operating systems:
- Windows&reg; 7 or above
- Windows Server 2008 R2 or above
The Volume Activation Management Tool (VAMT) lets you automate and centrally manage the Windows, Office, and select other Microsoft products volume and retail-activation process. VAMT can manage volume activation using Multiple Activation Keys (MAKs) or the Windows Key Management Service (KMS). VAMT is a standard Microsoft Management Console (MMC) snap-in. VAMT can be installed on any computer that has a supported Windows OS version.
**Important**  
VAMT is designed to manage volume activation for: Windows 7, Windows 8, Windows 8.1, Windows 10, Windows Server 2008 (or later), Microsoft Office 2010 (or above).
> [!IMPORTANT]
> VAMT is designed to manage volume activation for supported versions of Windows, Windows Server, and Office.
VAMT is only available in an EN-US (x86) package.
## In this section
|Topic |Description |
|Article |Description |
|------|------------|
|[Introduction to VAMT](introduction-vamt.md) |Provides a description of VAMT and common usages. |
|[Active Directory-Based Activation Overview](active-directory-based-activation-overview.md) |Describes Active Directory-Based Activation scenarios. |
|[Install and Configure VAMT](install-configure-vamt.md) |Describes how to install VAMT and use it to configure client computers on your network. |
|[Add and Manage Products](add-manage-products-vamt.md) |Describes how to add client computers into VAMT. |
|[Manage Product Keys](manage-product-keys-vamt.md) |Describes how to add and remove a product key from VAMT. |
|[Manage Activations](manage-activations-vamt.md) |Describes how to activate a client computer by using a variety of activation methods. |
|[Manage VAMT Data](manage-vamt-data.md) |Describes how to save, import, export, and merge a Computer Information List (CILX) file using VAMT. |
|[VAMT Step-by-Step Scenarios](vamt-step-by-step.md) |Provides step-by-step instructions for using VAMT in typical environments. |
|[VAMT Known Issues](vamt-known-issues.md) |Lists known issues in VAMT. |
|[Active Directory-based activation overview](active-directory-based-activation-overview.md) |Describes Active Directory-based activation scenarios. |
|[Install and configure VAMT](install-configure-vamt.md) |Describes how to install VAMT and use it to configure client computers on your network. |
|[Add and manage products](add-manage-products-vamt.md) |Describes how to add client computers into VAMT. |
|[Manage product keys](manage-product-keys-vamt.md) |Describes how to add and remove a product key from VAMT. |
|[Manage activations](manage-activations-vamt.md) |Describes how to activate a client computer by using various activation methods. |
|[Manage VAMT data](manage-vamt-data.md) |Describes how to save, import, export, and merge a Computer Information List (CILX) file using VAMT. |
|[VAMT step-by-step scenarios](vamt-step-by-step.md) |Provides step-by-step instructions for using VAMT in typical environments. |
|[VAMT known issues](vamt-known-issues.md) |Lists known issues in VAMT. |

24
windows/deployment/windows-10-deployment-posters.md
View File

@ -5,31 +5,33 @@ ms.reviewer:
manager: dougeby
author: aczechowski
ms.author: aaroncz
ms.prod: w10
ms.prod: windows-client
ms.technology: itpro-deploy
ms.localizationpriority: medium
ms.topic: article
ms.topic: reference
---
# Windows 10 deployment process posters
# Windows 10 deployment process posters
**Applies to**
- Windows 10
- Windows 10
The following posters step through various options for deploying Windows 10 with Windows Autopilot or Microsoft Endpoint Configuration Manager.
The following posters step through various options for deploying Windows 10 with Windows Autopilot or Microsoft Endpoint Configuration Manager.
## Deploy Windows 10 with Autopilot
The Windows Autopilot poster is two pages in portrait mode (11x17). Click the image to view a PDF in your browser. You can also download this poster in [PDF](https://github.com/MicrosoftDocs/windows-itpro-docs/raw/public/windows/deployment/media/Windows10AutopilotFlowchart.pdf) or [Visio](https://github.com/MicrosoftDocs/windows-itpro-docs/raw/public/windows/deployment/media/Windows10Autopilotflowchart.vsdx) format.
The Windows Autopilot poster is two pages in portrait mode (11x17). Select the image to download a PDF version.
[![Deploy Windows 10 with Autopilot.](./media/windows10-autopilot-flowchart.png)](./media/Windows10AutopilotFlowchart.pdf)
[![Deploy Windows 10 with Autopilot.](./media/windows10-autopilot-flowchart.png)](https://download.microsoft.com/download/8/4/b/84b5e640-8f66-4b43-81a9-1c3b9ea18eda/Windows10AutopilotFlowchart.pdf)
## Deploy Windows 10 with Microsoft Endpoint Configuration Manager
The Configuration Manager poster is one page in landscape mode (17x11). Click the image to view a PDF in your browser. You can also download this poster in [PDF](https://github.com/MicrosoftDocs/windows-itpro-docs/raw/public/windows/deployment/media/Windows10DeploymentConfigManager.pdf) or [Visio](https://github.com/MicrosoftDocs/windows-itpro-docs/raw/public/windows/deployment/media/Windows10DeploymentConfigManager.vsdx) format.
The Configuration Manager poster is one page in landscape mode (17x11). Select the image to download a PDF version.
[![Deploy Windows 10 with Configuration Manager.](./media/windows10-deployment-config-manager.png)](./media/Windows10DeploymentConfigManager.pdf)
[![Deploy Windows 10 with Configuration Manager.](./media/windows10-deployment-config-manager.png)](https://download.microsoft.com/download/e/2/a/e2a70587-d3cc-4f1a-ba49-cfd724a1736b/Windows10DeploymentConfigManager.pdf)
## See also
[Overview of Windows Autopilot](/windows/deployment/windows-autopilot/windows-autopilot)<br>
[Scenarios to deploy enterprise operating systems with Configuration Manager](/configmgr/osd/deploy-use/scenarios-to-deploy-enterprise-operating-systems)
[Overview of Windows Autopilot](/mem/autopilot/windows-autopilot)
[Scenarios to deploy enterprise operating systems with Configuration Manager](/mem/configmgr/osd/deploy-use/scenarios-to-deploy-enterprise-operating-systems)

2
windows/deployment/windows-autopatch/TOC.yml
View File

@ -32,6 +32,8 @@
href: deploy/windows-autopatch-device-registration-overview.md
- name: Register your devices
href: deploy/windows-autopatch-register-devices.md
- name: Post-device registration readiness checks
href: deploy/windows-autopatch-post-reg-readiness-checks.md
- name: Operate
href: operate/index.md
items:

6
windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md
View File

@ -1,7 +1,7 @@
---
title: Device registration overview
description: This article provides and overview on how to register devices in Autopatch
ms.date: 07/28/2022
ms.date: 09/07/2022
ms.prod: w11
ms.technology: windows
ms.topic: conceptual
@ -44,12 +44,12 @@ See the following detailed workflow diagram. The diagram covers the Windows Auto
| **Step 1: Identify devices** | IT admin identifies devices to be managed by the Windows Autopatch service. |
| **Step 2: Add devices** | IT admin adds devices through direct membership or nests other Azure AD assigned or dynamic groups into the **Windows Autopatch Device Registration** Azure AD assigned group. |
| **Step 3: Discover devices** | The Windows Autopatch Discover Devices function hourly discovers devices previously added by the IT admin into the **Windows Autopatch Device Registration** Azure AD assigned group in **step #2**. The Azure AD device ID is used by Windows Autopatch to query device attributes in both Microsoft Endpoint Manager-Intune and Azure AD when registering devices into its service.<ol><li>Once devices are discovered from the Azure AD group, the same function gathers additional device attributes and saves it into its memory during the discovery operation. The following device attributes are gathered from Azure AD in this step:</li><ol><li>**AzureADDeviceID**</li><li>**OperatingSystem**</li><li>**DisplayName (Device name)**</li><li>**AccountEnabled**</li><li>**RegistrationDateTime**</li><li>**ApproximateLastSignInDateTime**</li></ol><li>In this same step, the Windows Autopatch discover devices function calls another function, the device prerequisite check function. The device prerequisite check function evaluates software-based device-level prerequisites to comply with Windows Autopatch device readiness requirements prior to registration.</li></ol> |
| **Step 4: Check prerequisites** | The Windows Autopatch prerequisite function makes an Intune Graph API call to sequentially validate device readiness attributes required for the registration process. For detailed information, see the [Detailed prerequisite check workflow diagram](#detailed-prerequisite-check-workflow-diagram) section. The service checks the following device readiness attributes, and/or prerequisites:<ol><li>**Serial number, model, and manufacturer.**</li><ol><li>Checks if the serial number already exists in the Windows Autopatch’s managed device database.</li></ol><li>**If the device is Intune-managed or not.**</li><ol><li>Windows Autopatch looks to see **if the Azure AD device ID has an Intune device ID associated with it**.</li><ol><li>If **yes**, it means this device is enrolled into Intune.</li><li>If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol><li>**If the device is not managed by Intune**, the Windows Autopatch service can't gather device attributes such as operating system version, Intune enrollment date, device name and other attributes. When this happens, the Windows Autopatch service uses the Azure AD device attributes gathered and saved to its memory in **step 3a**.</li><ol><li>Once it has the device attributes gathered from Azure AD in **step 3a**, the device is flagged with the **Prerequisite failed** status, then added to the **Not ready** tab so the IT admin can review the reason(s) the device wasn't registered into Windows Autopatch. The IT admin will remediate these devices. In this case, the IT admin should check why the device wasn’t enrolled into Intune.</li><li>A common reason is when the Azure AD device ID is stale, it doesn’t have an Intune device ID associated with it anymore. To remediate, [clean up any stale Azure AD device records from your tenant](windows-autopatch-register-devices.md#clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant).</li></ol><li>**If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device has checked into Intune in the last 28 days.</li></ol><li>**If the device is a Windows device or not.**</li><ol><li>Windows Autopatch looks to see if the Azure AD device ID has an Intune device ID associated with it.</li><ol><li>**If yes**, it means this device is enrolled into Intune.</li><li>**If not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol></ol><li>**Windows Autopatch checks the Windows SKU family**. The SKU must be either:</li><ol><li>**Enterprise**</li><li>**Pro**</li><li>**Pro Workstation**</li></ol><li>**If the device meets the operating system requirements**, Windows Autopatch checks whether the device is either:</li><ol><li>**Only managed by Intune.**</li><ol><li>If the device is only managed by Intune, the device is marked as Passed all prerequisites.</li></ol><li>**Co-managed by both Configuration Manager and Intune.**</li><ol><li>If the device is co-managed by both Configuration Manager and Intune, an additional prerequisite check is evaluated to determine if the device satisfies the co-management-enabled workloads required by Windows Autopatch to manage devices in a co-managed state. The required co-management workloads evaluated in this step are:</li><ol><li>**Windows Updates Policies**</li><li>**Device Configuration**</li><li>**Office Click to Run**</li></ol><li>If Windows Autopatch determines that one of these workloads isn’t enabled on the device, the service marks the device as **Prerequisite failed** and moves the device to the **Not Ready** tab.</li></ol></ol></ol>|
| **Step 4: Check prerequisites** | The Windows Autopatch prerequisite function makes an Intune Graph API call to sequentially validate device readiness attributes required for the registration process. For detailed information, see the [Detailed prerequisite check workflow diagram](#detailed-prerequisite-check-workflow-diagram) section. The service checks the following device readiness attributes, and/or prerequisites:<ol><li>**Serial number, model, and manufacturer.**</li><ol><li>Checks if the serial number already exists in the Windows Autopatch’s managed device database.</li></ol><li>**If the device is Intune-managed or not.**</li><ol><li>Windows Autopatch looks to see **if the Azure AD device ID has an Intune device ID associated with it**.</li><ol><li>If **yes**, it means this device is enrolled into Intune.</li><li>If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol><li>**If the device is not managed by Intune**, the Windows Autopatch service can't gather device attributes such as operating system version, Intune enrollment date, device name and other attributes. When this happens, the Windows Autopatch service uses the Azure AD device attributes gathered and saved to its memory in **step 3a**.</li><ol><li>Once it has the device attributes gathered from Azure AD in **step 3a**, the device is flagged with the **Prerequisite failed** status, then added to the **Not registered** tab so the IT admin can review the reason(s) the device wasn't registered into Windows Autopatch. The IT admin will remediate these devices. In this case, the IT admin should check why the device wasn’t enrolled into Intune.</li><li>A common reason is when the Azure AD device ID is stale, it doesn’t have an Intune device ID associated with it anymore. To remediate, [clean up any stale Azure AD device records from your tenant](windows-autopatch-register-devices.md#clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant).</li></ol><li>**If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device has checked into Intune in the last 28 days.</li></ol><li>**If the device is a Windows device or not.**</li><ol><li>Windows Autopatch looks to see if the Azure AD device ID has an Intune device ID associated with it.</li><ol><li>**If yes**, it means this device is enrolled into Intune.</li><li>**If not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.</li></ol></ol><li>**Windows Autopatch checks the Windows SKU family**. The SKU must be either:</li><ol><li>**Enterprise**</li><li>**Pro**</li><li>**Pro Workstation**</li></ol><li>**If the device meets the operating system requirements**, Windows Autopatch checks whether the device is either:</li><ol><li>**Only managed by Intune.**</li><ol><li>If the device is only managed by Intune, the device is marked as Passed all prerequisites.</li></ol><li>**Co-managed by both Configuration Manager and Intune.**</li><ol><li>If the device is co-managed by both Configuration Manager and Intune, an additional prerequisite check is evaluated to determine if the device satisfies the co-management-enabled workloads required by Windows Autopatch to manage devices in a co-managed state. The required co-management workloads evaluated in this step are:</li><ol><li>**Windows Updates Policies**</li><li>**Device Configuration**</li><li>**Office Click to Run**</li></ol><li>If Windows Autopatch determines that one of these workloads isn’t enabled on the device, the service marks the device as **Prerequisite failed** and moves the device to the **Not registered** tab.</li></ol></ol></ol>|
| **Step 5: Calculate deployment ring assignment** | Once the device passes all prerequisites described in **step #4**, Windows Autopatch starts its deployment ring assignment calculation. The following logic is used to calculate the Windows Autopatch deployment ring assignment:<ol><li>If the Windows Autopatch tenant’s existing managed device size is **≤ 200**, the deployment ring assignment is **First (5%)**, **Fast (15%)**, remaining devices go to the **Broad ring (80%)**.</li><li>If the Windows Autopatch tenant’s existing managed device size is **>200**, the deployment ring assignment will be **First (1%)**, **Fast (9%)**, remaining devices go to the **Broad ring (90%)**.</li></ol> |
| **Step 6: Assign devices to a deployment ring group** | Once the deployment ring calculation is done, Windows Autopatch assigns devices to one of the following deployment ring groups:<ol><li>**Modern Workplace Devices-Windows Autopatch-First**</li><ol><li>The Windows Autopatch device registration process doesn’t automatically assign devices to the Test ring represented by the Azure AD group (Modern Workplace Devices-Windows Autopatch-Test). It’s important that you assign devices to the Test ring to validate the update deployments before the updates are deployed to a broader population of devices.</li></ol><li>**Modern Workplace Devices-Windows Autopatch-Fast**</li><li>**Modern Workplace Devices-Windows Autopatch-Broad**</li></ol> |
| **Step 7: Assign devices to an Azure AD group** | Windows Autopatch also assigns devices to the following Azure AD groups when certain conditions apply:<ol><li>**Modern Workplace Devices - All**</li><ol><li>This group has all devices managed by Windows Autopatch.</li></ol><li>When registering **Windows 10 devices**, use **Modern Workplace Devices Dynamic - Windows 10**</li><ol><li>This group has all devices managed by Windows Autopatch and that have Windows 10 installed.</li></ol><li>When registering **Windows 11 devices**, use **Modern Workplace Devices Dynamic - Windows 11**</li><ol><li>This group has all devices managed by Windows Autopatch and that have Windows 11 installed.</li></ol><li>When registering **virtual devices**, use **Modern Workplace Devices - Virtual Machine**</li><ol><li>This group has all virtual devices managed by Windows Autopatch.</li></ol> |
| **Step 8: Post-device registration** | In post-device registration, three actions occur:<ol><li>Windows Autopatch adds devices to its managed database.</li><li>Flags devices as **Active** in the **Ready** tab.</li><li>The Azure AD device ID of the device successfully registered is added into the Microsoft Cloud Managed Desktop Extension’s allowlist. Windows Autopatch installs the Microsoft Cloud Managed Desktop Extension agent once devices are registered, so the agent can communicate back to the Microsoft Cloud Managed Desktop Extension service.</li><ol><li>The agent is the **Modern Workplace - Autopatch Client setup** PowerShell script that was created during the Windows Autopatch tenant enrollment process. The script is executed once devices are successfully registered into the Windows Autopatch service.</li></ol> |
| **Step 9: Review device registration status** | IT admins review the device registration status in both the **Ready** and **Not ready** tabs.<ol><li>If the device was **successfully registered**, the device shows up in the **Ready** tab.</li><li>If **not**, the device shows up in the **Not ready** tab.</li></ol> |
| **Step 9: Review device registration status** | IT admins review the device registration status in both the **Ready** and **Not registered** tabs.<ol><li>If the device was **successfully registered**, the device shows up in the **Ready** tab.</li><li>If **not**, the device shows up in the **Not registered** tab.</li></ol> |
| **Step 10: End of registration workflow** | This is the end of the Windows Autopatch device registration workflow. |
## Detailed prerequisite check workflow diagram

102
windows/deployment/windows-autopatch/deploy/windows-autopatch-post-reg-readiness-checks.md Normal file
View File

@ -0,0 +1,102 @@
---
title: Post-device registration readiness checks
description: This article details how post-device registration readiness checks are performed in Windows Autopatch
ms.date: 09/16/2022
ms.prod: w11
ms.technology: windows
ms.topic: conceptual
ms.localizationpriority: medium
author: tiaraquan
ms.author: tiaraquan
manager: dougeby
msreviewer: andredm7
---
# Post-device registration readiness checks (public preview)
> [!IMPORTANT]
> This feature is in "public preview". It is being actively developed, and may not be complete. They're made available on a “Preview” basis. You can test and use these features in production environments and scenarios, and provide feedback.
One of the most expensive aspects of the software update management process is to make sure devices are always healthy to receive and report software updates for each software update release cycle.
Having a way of measuring, quickly detecting and remediating when something goes wrong with on-going change management processes is important; it helps mitigate high Helpdesk ticket volumes, reduces cost, and improves overall update management results.
Windows Autopatch provides proactive device readiness information about devices that are and aren't ready to be fully managed by the service. IT admins can easily detect and fix device-related issues that are preventing them from achieving their update management compliance report goals.
## Device readiness scenarios
Device readiness in Windows Autopatch is divided into two different scenarios:
| Scenario | Description |
| ----- | ----- |
| Prerequisite checks | Ensures devices follow software-based requirements before being registered with the service. |
| Post-device registration readiness checks | Provides continuous monitoring of device health for registered devices.<p>IT admins can easily detect and remediate configuration mismatches in their environments or issues that prevent devices from having one or more software update workloads (Windows quality, feature updates, Microsoft Office, Microsoft Teams, or Microsoft Edge) fully managed by the Windows Autopatch service. Configuration mismatches can leave devices in a vulnerable state, out of compliance and exposed to security threats.</p>|
### Device readiness checks available for each scenario
| Required device readiness (prerequisite checks) prior to device registration (powered by Intune Graph API) | Required post-device registration readiness checks (powered by Microsoft Cloud Managed Desktop Extension) |
| ----- | ----- |
| <ul><li>Windows OS (build, architecture and edition)</li></li><li>Managed by either Intune or ConfigMgr co-management</li><li>ConfigMgr co-management workloads</li><li>Last communication with Intune</li><li>Personal or non-Windows devices</li></ul> | <ul><li>Windows OS (build, architecture and edition)</li><li>Windows updates & Office Group Policy Object (GPO) versus Intune mobile device management (MDM) policy conflict</li><li>Bind network endpoints (Microsoft Defender, Microsoft Teams, Microsoft Edge, Microsoft Office)</li><li>Internet connectivity</li></ul> |
The status of each post-device registration readiness check is shown in the Windows Autopatch’s Devices blade under the **Not ready** tab. You can take appropriate action(s) on devices that aren't ready to be fully managed by the Windows Autopatch service.
## About the three tabs in the Devices blade
You deploy software updates to secure your environment, but these deployments only reach healthy and active devices. Unhealthy or not ready devices affect the overall software update compliance. Figuring out device health can be challenging and disruptive to the end user when IT can’t obtain proactive data sent by the device to the service for IT admins to proactively detect, troubleshoot, and fix issues.
Windows Autopatch has three tabs within its Devices blade. Each tab is designed to provide a different set of device readiness statuses so IT admins know where to go to monitor, and troubleshoot potential device health issues:
| Tab | Description |
| ----- | ----- |
| Ready | This tab only lists devices with the **Active** status. Devices with the **Active** status successfully:<ul><li>Passed the prerequisite checks.</li><li>Registered with Windows Autopatch.</li></ul>This tab also lists devices that have passed all postdevice registration readiness checks. |
| Not ready | This tab only lists devices with the **Readiness failed** and **Inactive** status.<ul><li>**Readiness failed status**: Devices that didn’t pass one or more post-device registration readiness checks.</li><li>**Inactive**: Devices that haven’t communicated with the Microsoft Endpoint Manager-Intune service in the last 28 days.</li></ul> |
| Not registered | Only lists devices with the **Prerequisite failed** status in it. Devices with the **Prerequisite failed** status didn’t pass one or more prerequisite checks during the device registration process. |
## Details about the post-device registration readiness checks
A healthy or active device in Windows Autopatch is:
- Online
- Actively sending data
- Passes all post-device registration readiness checks
The post-device registration readiness checks are powered by the **Microsoft Cloud Managed Desktop Extension**. It's installed right after devices are successfully registered with Windows Autopatch. The **Microsoft Cloud Managed Desktop Extension** has the Device Readiness Check Plugin. The Device Readiness Check Plugin is responsible for performing the readiness checks and reporting the results back to the service. The **Microsoft Cloud Managed Desktop Extension** is a subcomponent of the overall Windows Autopatch service.
The following list of post-device registration readiness checks is performed in Windows Autopatch:
| Check | Description |
| ----- | ----- |
| **Windows OS build, architecture, and edition** | Checks to see if devices support Windows 1809+ build (10.0.17763), 64-bit architecture and either Pro or Enterprise SKUs. |
| **Windows update policies managed via Microsoft Endpoint Manager-Intune** | Checks to see if devices have Windows Updates policies managed via Microsoft Endpoint Manager-Intune (MDM). |
| **Windows update policies managed via Group Policy Object (GPO)** | Checks to see if devices have Windows update policies managed via GPO. Windows Autopatch doesn’t support Windows update policies managed via GPOs. Windows update must be managed via Microsoft Endpoint Manager-Intune. |
| **Microsoft Office update policy managed via Group Policy Object (GPO)** | Checks to see if devices have Microsoft Office updates policies managed via GPO. Windows Autopatch doesn’t support Microsoft Office update policies managed via GPOs. Office updates must be managed via Microsoft Endpoint Manager-Intune or another Microsoft Office policy management method where Office update bits are downloaded directly from the Office Content Delivery Network (CDN). |
| **Windows Autopatch network endpoints** | There's a set of [network endpoints](../prepare/windows-autopatch-configure-network.md) that Windows Autopatch services must be able to reach for the various aspects of the Windows Autopatch service. |
| **Microsoft Teams network endpoints** | There's a set of [network endpoints](../prepare/windows-autopatch-configure-network.md) that devices with Microsoft Teams must be able to reach for software updates management. |
| **Microsoft Edge network endpoints** | There's a set of [network endpoints](../prepare/windows-autopatch-configure-network.md) that devices with Microsoft Edge must be able to reach for software updates management. |
| **Internet connectivity** | Checks to see if a device has internet connectivity to communicate with Microsoft cloud services. Windows Autopatch uses the PingReply class. Windows Autopatch tries to ping at least three different Microsoft’s public URLs two times each, to confirm that ping results aren't coming from the device’s cache. |
## Post-device registration readiness checks workflow
See the following diagram for the post-device registration readiness checks workflow:
:::image type="content" source="../media/windows-autopatch-post-device-registration-readiness-checks.png" alt-text="Post-device registration readiness checks" lightbox="../media/windows-autopatch-post-device-registration-readiness-checks.png":::
| Step | Description |
| ----- | ----- |
| **Steps 1-7** | For more information, see the [Device registration overview diagram](windows-autopatch-device-registration-overview.md).|
| **Step 8: Perform readiness checks** |<ol><li>Once devices are successfully registered with Windows Autopatch, the devices are added to the **Ready** tab.</li><li>The Microsoft Cloud Managed Desktop Extension agent performs readiness checks against devices in the **Ready** tab every 24 hours.</li></ol> |
| **Step 9: Check readiness status** |<ol><li>The Microsoft Cloud Managed Desktop Extension service evaluates the readiness results gathered by its agent.</li><li>The readiness results are sent from the Microsoft Cloud Managed Desktop Extension service component to the Device Readiness component within the Windows Autopatch’s service.</li></ol>|
| **Step 10: Add devices to the Not ready** | When devices don’t pass one or more readiness checks, even if they’re registered with Windows Autopatch, they’re added to the **Not ready** tab so IT admins can remediate devices based on Windows Autopatch recommendations. |
| **Step 11: IT admin understands what the issue is and remediates** | The IT admin checks and remediates issues in the Devices blade (**Not ready** tab). It can take up to 24 hours for devices to show back up into the **Ready** tab. |
## FAQ
| Question | Answer |
| ----- | ----- |
| **How frequent are the post-device registration readiness checks performed?** |<ul><li>The **Microsoft Cloud Managed Desktop Extension** agent collects device readiness statuses when it runs (once a day).</li><li>Once the agent collects results for the post-device registration readiness checks, it generates readiness results in the device in the `%programdata%\Microsoft\CMDExtension\Plugins\DeviceReadinessPlugin\Logs\DRCResults.json.log`.</li><li>The readiness results are sent over to the **Microsoft Cloud Managed Desktop Extension service**.</li><li>The **Microsoft Cloud Managed Desktop Extension** service component sends the readiness results to the Device Readiness component. The results appear in the Windows Autopatch Devices blade (**Not ready** tab).</li></ul>|
| **What to expect when one or more checks fail?** | Devices are automatically sent to the **Ready** tab once they're successfully registered with Windows Autopatch. When devices don’t meet one or more post-device registration readiness checks, the devices are moved to the **Not ready** tab. IT admins can learn about these devices and take appropriate actions to remediate them. Windows Autopatch will provide information about the failure and how to potentially remediate devices.<p>Once devices are remediated, it can take up to **24 hours** to show up in the **Ready** tab.</p>|
## Additional resources
- [Device registration overview](windows-autopatch-device-registration-overview.md)
- [Register your devices](windows-autopatch-register-devices.md)

45
windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md
View File

@ -1,7 +1,7 @@
---
title: Register your devices
description: This article details how to register devices in Autopatch
ms.date: 08/08/2022
ms.date: 09/07/2022
ms.prod: w11
ms.technology: windows
ms.topic: how-to
@ -28,7 +28,13 @@ Windows Autopatch can take over software update management control of devices th
### About the use of an Azure AD group to register devices
You must choose what devices to manage with Windows Autopatch by either adding them through direct membership or by nesting other Azure AD dynamic/assigned groups into the **Windows Autopatch Device Registration** Azure AD assigned group. Windows Autopatch automatically runs its discover devices function every hour to discover new devices added to this group. Once new devices are discovered, Windows Autopatch attempts to register these devices.
You must choose what devices to manage with Windows Autopatch by adding them to the **Windows Autopatch Device Registration** Azure AD assigned group. Devices can be added using the following methods:
- Direct membership
- Nesting other Azure AD dynamic/assigned groups
- [Bulk add/import group members](/azure/active-directory/enterprise-users/groups-bulk-import-members)
Windows Autopatch automatically runs its discover devices function every hour to discover new devices added to this group. Once new devices are discovered, Windows Autopatch attempts to register these devices.
> [!NOTE]
> Devices that are intended to be managed by the Windows Autopatch service **must** be added into the **Windows Autopatch Device Registration** Azure AD assigned group. Devices can only be added to this group if they have an Azure AD device ID. Windows Autopatch scans the Azure AD group hourly to discover newly added devices to be registered. You can also use the **Discover devices** button in either the **Ready** or **Not ready** tab to register devices on demand.
@ -78,14 +84,26 @@ To be eligible for Windows Autopatch management, devices must meet a minimum set
For more information, see [Windows Autopatch Prerequisites](../prepare/windows-autopatch-prerequisites.md).
## About the Ready and Not ready tabs
## About the Ready, Not ready and Not registered tabs
Windows Autopatch introduces a new user interface to help IT admins detect and troubleshoot device readiness statuses seamlessly with actionable in-UI device readiness reports for unregistered devices or unhealthy devices.
Windows Autopatch has three tabs within its device blade. Each tab is designed to provide a different set of device readiness status so IT admin knows where to go to monitor, and troubleshoot potential device health issues.
| Tab | Purpose |
| ----- | ----- |
| Ready | The purpose of the Ready tab is to show devices that were successfully registered to the Windows Autopatch service. |
| Not ready | The purpose of the Not ready tab is to help you identify and remediate devices that don't meet the pre-requisite checks to register into the Windows Autopatch service. This tab only shows devices that didn't successfully register into Windows Autopatch. |
| Device blade tab | Purpose | Expected device readiness status |
| ----- | ----- | ----- |
| Ready | The purpose of this tab is to show devices that were successfully registered with the Windows Autopatch service. | Active |
| Not ready | The purpose of this tab is to help you identify and remediate devices that failed to pass one or more post-device registration readiness checks. Devices showing up in this tab were successfully registered with Windows Autopatch. However, these devices aren't ready to have one or more software update workloads managed by the service. | Readiness failed and/or Inactive |
| Not registered | The purpose of this tab is to help you identify and remediate devices that don't meet one or more prerequisite checks to successfully register with the Windows Autopatch service. | Pre-requisites failed |
## Device readiness statuses
See all possible device readiness statuses in Windows Autopatch:
| Readiness status | Description | Device blade tab |
| ----- | ----- | ----- |
| Active | Devices with this status successfully passed all prerequisite checks and subsequently successfully registered with Windows Autopatch. Additionally, devices with this status successfully passed all post-device registration readiness checks. | Ready |
| Readiness failed | Devices with this status haven't passed one or more post-device registration readiness checks. These devices aren't ready to have one or more software update workloads managed by Windows Autopatch. | Not ready |
| Inactive | Devices with this status haven't communicated with Microsoft Endpoint Manager-Intune in the last 28 days. | Not ready |
| Pre-requisites failed | Devices with this status haven't passed one or more pre-requisite checks and haven't successfully registered with Windows Autopatch | Not registered |
## Built-in roles required for device registration
@ -117,18 +135,18 @@ Since existing Windows 365 Cloud PCs already have an existing Azure AD device ID
**To register devices with Windows Autopatch:**
1. Go to the [Microsoft Endpoint Manager admin center](https://endpoint.microsoft.com/).
2. Select **Windows Autopatch** from the left navigation menu.
3. Select **Devices**.
4. Select either the **Ready** or the **Not ready** tab, then select the **Windows Autopatch Device Registration** hyperlink. The Azure Active Directory group blade opens.
2. Select **Devices** from the left navigation menu.
3. Under the **Windows Autopatch** section, select **Devices**.
4. Select either the **Ready** or the **Not registered** tab, then select the **Windows Autopatch Device Registration** hyperlink. The Azure Active Directory group blade opens.
5. Add either devices through direct membership, or other Azure AD dynamic or assigned groups as nested groups in the **Windows Autopatch Device Registration** group.
> [!NOTE]
> The **Windows Autopatch Device Registration** hyperlink is in the center of the Ready tab when there's no devices registered with the Windows Autopatch service. Once you have one or more devices registered with the Windows Autopatch service, the **Windows Autopatch Device registration** hyperlink is at the top of both **Ready** and **Not ready** tabs.
> The **Windows Autopatch Device Registration** hyperlink is in the center of the Ready tab when there's no devices registered with the Windows Autopatch service. Once you have one or more devices registered with the Windows Autopatch service, the **Windows Autopatch Device registration** hyperlink is at the top of both **Ready** and **Not registered** tabs.
Once devices or other Azure AD groups (either dynamic or assigned) containing devices are added to the **Windows Autopatch Device Registration** group, Windows Autopatch's device discovery hourly function discovers these devices, and runs software-based prerequisite checks to try to register them with its service.
> [!TIP]
> You can also use the **Discover Devices** button in either the **Ready** or **Not ready** tab to discover devices from the **Windows Autopatch Device Registration** Azure AD group on demand.
> You can also use the **Discover Devices** button in either one of the **Ready**, **Not ready**, or **Not registered** device blade tabs to discover devices from the **Windows Autopatch Device Registration** Azure AD group on demand. On demand means you don't have to wait for Windows Autopatch to discover devices from the Azure AD group on your behalf.
### Windows Autopatch on Windows 365 Enterprise Workloads
@ -148,6 +166,7 @@ Windows 365 Enterprise gives IT admins the option to register devices with the W
1. Select **Create**. Now your newly provisioned Windows 365 Enterprise Cloud PCs will automatically be enrolled and managed by Windows Autopatch.
For more information, see [Create a Windows 365 Provisioning Policy](/windows-365/enterprise/create-provisioning-policy).
### Contact support for device registration-related incidents
Support is available either through Windows 365, or the Windows Autopatch Service Engineering team for device registration-related incidents.

BIN
windows/deployment/windows-autopatch/media/windows-autopatch-device-registration-workflow-diagram.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 560 KiB

After

Width:  |  Height:  |  Size: 561 KiB

BIN
windows/deployment/windows-autopatch/media/windows-autopatch-post-device-registration-readiness-checks.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 443 KiB

BIN
windows/deployment/windows-autopatch/media/windows-quality-update-grace-period.png
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 216 KiB

After

Width:  |  Height:  |  Size: 1006 KiB

6
windows/deployment/windows-autopatch/operate/windows-autopatch-fu-end-user-exp.md
View File

@ -37,7 +37,7 @@ In this example, we'll be discussing a device in the First ring. The Autopatch s
In the following example, the user schedules the restart and is notified 15 minutes prior to the scheduled restart time. The user can reschedule, if necessary, but isn't able to reschedule past the deadline.
:::image type="content" source="../media/windows-feature-typical-update-experience.png" alt-text="Typical Windows feature update experience":::
:::image type="content" source="../media/windows-feature-typical-update-experience.png" alt-text="Typical Windows feature update experience" lightbox="../media/windows-feature-typical-update-experience.png":::
### Feature update deadline forces an update
@ -45,7 +45,7 @@ The following example builds on the scenario outlined in the typical user experi
The deadline specified in the update policy is five days. Therefore, once this deadline is passed, the device will ignore the active hours and force a restart to complete the installation. The user will receive a 15-minute warning, after which, the device will install the update and restart.
:::image type="content" source="../media/windows-feature-force-update.png" alt-text="Force Windows feature update":::
:::image type="content" source="../media/windows-feature-force-update.png" alt-text="Force Windows feature update" lightbox="../media/windows-feature-force-update.png":::
### Feature update grace period
@ -53,7 +53,7 @@ In the following example, the user is on holiday and the device is offline beyon
Since the deadline has already passed, the device is granted a two-day grace period to install the update and restart. The user will be notified of a pending installation and given options to choose from. Once the two-day grace period has expired, the user is forced to restart with a 15-minute warning notification.
:::image type="content" source="../media/windows-feature-update-grace-period.png" alt-text="Window feature update grace period":::
:::image type="content" source="../media/windows-feature-update-grace-period.png" alt-text="Windows feature update grace period" lightbox="../media/windows-feature-update-grace-period.png":::
## Servicing window

4
windows/deployment/windows-autopatch/operate/windows-autopatch-fu-overview.md
View File

@ -46,7 +46,7 @@ The final release schedule is communicated prior to release and may vary a littl
| Fast | Release start + 60 days |
| Broad | Release start + 90 days |
:::image type="content" source="../media/windows-feature-release-process-timeline.png" alt-text="Windows feature release timeline":::
:::image type="content" source="../media/windows-feature-release-process-timeline.png" alt-text="Windows feature release timeline" lightbox="../media/windows-feature-release-process-timeline.png":::
## New devices to Windows Autopatch
@ -64,7 +64,7 @@ When releasing a feature update, there are two policies that are configured by t
| Ring | Target version (DSS) Policy | Feature update deferral | Feature update deadline | Feature update grace period |
| ----- | ----- | ----- | ----- | ----- |
| Test | 21H2 | 0 | 5 | 0 |
| First | 21H2 | 0 | 5 | 0 |
| First | 21H2 | 0 | 5 | 2 |
| Fast | 21H2 | 0 | 5 | 2 |
| Broad | 21H2 | 0 | 5 | 2 |

5
windows/deployment/windows-autopatch/operate/windows-autopatch-maintain-environment.md
View File

@ -26,5 +26,8 @@ After you've completed enrollment in Windows Autopatch, some management settings
| Setting | Description |
| ----- | ----- |
| Conditional access policies | If you create any new conditional access or multi-factor authentication policies related to Azure AD, or Microsoft Intune after Windows Autopatch enrollment, exclude the Modern Workplace Service Accounts Azure AD group from them. For more information, see [Conditional Access: Users and groups](/azure/active-directory/conditional-access/concept-conditional-access-users-groups). Windows Autopatch maintains separate conditional access policies to restrict access to these accounts.<p>**To review the Windows Autopatch conditional access policy (Modern Workplace – Secure Workstation):**</p><p>Go to Microsoft Endpoint Manager and navigate to **Conditional Access** in **Endpoint Security**. Do **not** modify any Azure AD conditional access policies created by Windows Autopatch that have "**Modern Workplace**" in the name.</p> |
| Update rings for Windows 10 or later | For any update rings for Windows 10 or later policies you've created, exclude the **Modern Workplace Devices - All** Azure AD group from each policy. For more information, see [Create and assign update rings](/mem/intune/protect/windows-10-update-rings#create-and-assign-update-rings).<p>Windows Autopatch will also have created some update ring policies. all of which The policies will have "**Modern Workplace**" in the name. For example:</p><ul><li>Modern Workplace Update Policy [Broad]-[Windows Autopatch]</li><li>Modern Workplace Update Policy [Fast]-[Windows Autopatch]</li><li>Modern Workplace Update Policy [First]-[Windows Autopatch]</li><li>Modern Workplace Update Policy [Test]-[Windows Autopatch]</li></ul><p>When you update your own policies, ensure that you don't exclude the **Modern Workplace Devices - All** Azure AD group from the policies that Windows Autopatch created.</p><p>**To resolve the Not ready result:**</p><p>After enrolling into Autopatch, make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group.For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).</p><p>**To resolve the Advisory result:**</p><ol><li>Make sure that any update ring policies you have **exclude** the **Modern Workplace Devices - All** Azure Active Directory (AD) group.</li> <li>If you have assigned Azure AD user groups to these policies, make sure that any update ring policies you have also **exclude** the **Modern Workplace - All** Azure AD group that you add your Windows Autopatch users to (or an equivalent group).</li></ol><p>For more information, see [Manage Windows 10 software updates in Intune](/mem/intune/protect/windows-update-for-business-configure).</p> |
## Windows Autopatch configurations
Windows Autopatch deploys, manages and maintains all configurations related to the operation of the service, as described in [Changes made at tenant enrollment](../references/windows-autopatch-changes-to-tenant.md). Don't make any changes to any of the Windows Autopatch configurations.

2
windows/deployment/windows-autopatch/operate/windows-autopatch-microsoft-365-apps-enterprise.md
View File

@ -33,7 +33,7 @@ For a device to be eligible for Microsoft 365 Apps for enterprise updates, as a
All devices registered for Windows Autopatch will receive updates from the [Monthly Enterprise Channel](/deployoffice/overview-update-channels#monthly-enterprise-channel-overview). This practice provides your users with new features each month, and they'll receive just one update per month on a predictable release schedule. Updates are released on the second Tuesday of the month; these updates can include feature, security, and quality updates. These updates occur automatically and are pulled directly from the Office Content Delivery Network (CDN).
Unlike Windows update, the Office CDN doesn't make the update available to all devices at once. Over the course of the release, the Office CDN gradually makes the update available to the whole population of devices. Windows Autopatch doesn't control the order in which updates are offered to devices across your estate. After the update has been downloaded, there's a three-day [update deadline](/deployoffice/configure-update-settings-microsoft-365-apps) that specifies how long the user has until the user must apply the update.
Unlike Windows update, the Office CDN doesn't make the update available to all devices at once. Over the course of the release, the Office CDN gradually makes the update available to the whole population of devices. Windows Autopatch doesn't control the order in which updates are offered to devices across your estate. After the update has been downloaded, there's a seven day [update deadline](/deployoffice/configure-update-settings-microsoft-365-apps) that specifies how long the user has until the user must apply the update.
## Update rings

2
windows/deployment/windows-autopatch/operate/windows-autopatch-unenroll-tenant.md
View File

@ -41,8 +41,6 @@ Unenrolling from Windows Autopatch requires manual actions from both you and fro
| ----- | ----- |
| Updates | After the Windows Autopatch service is unenrolled, we’ll no longer provide updates to your devices. You must ensure that your devices continue to receive updates through your own policies to ensure they're secure and up to date. |
| Optional Windows Autopatch configuration | Windows Autopatch won’t remove the configuration policies or groups used to enable updates on your devices. You're responsible for these policies following tenant unenrollment. If you don’t wish to use these policies for your devices after unenrollment, you may safely delete them. For more information, see [Changes made at tenant enrollment](../references/windows-autopatch-changes-to-tenant.md). |
| Windows Autopatch cloud service accounts | After unenrollment, you may safely remove the cloud service accounts created during the enrollment process. The accounts are:<ul><li>MsAdmin</li><li>MsAdminInt</li><li>MsTest</li></ul> |
| Conditional access policy | After unenrollment, you may safely remove the **Modern Workplace – Secure Workstation** conditional access policy. |
| Microsoft Endpoint Manager roles | After unenrollment, you may safely remove the Modern Workplace Intune Admin role. |
## Unenroll from Windows Autopatch

12
windows/deployment/windows-autopatch/operate/windows-autopatch-update-management.md
View File

@ -40,13 +40,16 @@ During the [tenant enrollment process](../prepare/windows-autopatch-enroll-tenan
Each deployment ring has a different set of update deployment policies to control the updates rollout.
> [!WARNING]
> Adding or importing devices into any of these groups directly is not supported and doing so might cause an unexpected impact on the Windows Autopatch service. To move devices between these groups, see [Moving devices in between deployment rings](../operate/windows-autopatch-update-management.md#moving-devices-in-between-deployment-rings).
> [!IMPORTANT]
> Windows Autopatch device registration doesn't assign devices to its test deployment ring (**Modern Workplace Devices-Windows Autopatch-Test**). This is intended to prevent devices that are essential to a business from being affected or devices that are used by executives from receiving early software update deployments.
Also, during the [device registration process](../deploy/windows-autopatch-device-registration-overview.md), Windows Autopatch assigns each device being registered to one of its deployment rings so that the service has the proper representation of the device diversity across the organization in each deployment ring. The deployment ring distribution is designed to release software update deployments to as few devices as possible to get the signals needed to make a quality evaluation of a given update deployment.
> [!NOTE]
> Windows Autopatch deployment rings only apply to Windows quality updates. Additionally, you can't create additional deployment rings or use your own for devices managed by the Windows Autopatch service.
> You can't create additional deployment rings or use your own for devices managed by the Windows Autopatch service.
### Deployment ring calculation logic
@ -58,7 +61,7 @@ The Windows Autopatch deployment ring calculation happens during the [device reg
| Deployment ring | Default device balancing percentage | Description |
| ----- | ----- | ----- |
| Test | **zero** | Windows Autopatch doesn't automatically add devices to this deployment ring. You must manually add devices to the Test ring. The recommended number of devices in this ring, based upon your environment size, is as follows:<br><ul><li>**0–500** devices: minimum **one** device.</li><li>**500–5000** devices: minimum **five** devices.</li><li>**5000+** devices: minimum **50** devices.</li></ul>Devices in this group are intended for your IT Administrators and testers since changes are released here first. This release schedule provides your organization the opportunity to validate updates prior to reaching production users. |
| Test | **zero** | Windows Autopatch doesn't automatically add devices to this deployment ring. You must manually add devices to the Test ring following the required procedure. For more information on these procedures, see [Moving devices in between deployment rings](/windows/deployment/windows-autopatch/operate/windows-autopatch-update-management#moving-devices-in-between-deployment-rings). The recommended number of devices in this ring, based upon your environment size, is as follows:<br><ul><li>**0–500** devices: minimum **one** device.</li><li>**500–5000** devices: minimum **five** devices.</li><li>**5000+** devices: minimum **50** devices.</li></ul>Devices in this group are intended for your IT Administrators and testers since changes are released here first. This release schedule provides your organization the opportunity to validate updates prior to reaching production users. |
| First | **1%** | The First ring is the first group of production users to receive a change.<p><p>This group is the first set of devices to send data to Windows Autopatch and are used to generate a health signal across all end-users. For example, Windows Autopatch can generate a statistically significant signal saying that critical errors are trending up in a specific release for all end-users, but can't be confident that it's doing so in your organization.<p><p>Since Windows Autopatch doesn't yet have sufficient data to inform a release decision, devices in this deployment ring might experience outages if there are scenarios that weren't covered during early testing in the Test ring.|
| Fast | **9%** | The Fast ring is the second group of production users to receive changes. The signals from the First ring are considered as a part of the release process to the Broad ring.<p><p>The goal with this deployment ring is to cross the **500**-device threshold needed to generate statistically significant analysis at the tenant level. These extra devices allow Windows Autopatch to consider the effect of a release on the rest of your devices and evaluate if a targeted action for your tenant is needed.</p> |
| Broad | Either **80%** or **90%** | The Broad ring is the last group of users to receive software update deployments. Since it contains most of the devices registered with Windows Autopatch, it favors stability over speed in an software update deployment.|
@ -80,7 +83,10 @@ When the assignment is complete, the **Ring assigned by** column changes to **Ad
> [!NOTE]
> You can only move devices to other deployment rings when they're in an active state in the **Ready** tab.<p>If you don't see the **Ring assigned by column** change to **Pending** in Step 5, check to see whether the device exists in Microsoft Endpoint Manager-Intune or not by searching for it in its device blade. For more information, see [Device details in Intune](/mem/intune/remote-actions/device-inventory).
> [!WARNING]
> Moving devices between deployment rings through directly changing Azure AD group membership isn't supported and may cause unintended configuration conflicts within the Windows Autopatch service. To avoid service interruption to devices, use the **Assign device to ring** action described previously to move devices between deployment rings.
## Automated deployment ring remediation functions
Windows Autopatch monitors device membership in its deployment rings, except for the **Modern Workplace Devices-Windows Autopatch-Test** ring, to provide automated deployment ring remediation functions to mitigate the risk of not having its managed devices being part of one of its deployment rings. These automated functions help mitigate risk of potentially having devices in a vulnerable state, and exposed to security threats in case they're not receiving update deployments due to either:

6
windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-end-user-exp.md
View File

@ -36,7 +36,7 @@ Once the deferral period has passed, the device will download the update and not
In the following example, the user schedules the restart and is notified 15 minutes prior to the scheduled restart time. The user can reschedule, if necessary, but isn't able to reschedule past the deadline.
:::image type="content" source="../media/windows-quality-typical-update-experience.png" alt-text="Typical windows quality update experience":::
:::image type="content" source="../media/windows-quality-typical-update-experience.png" alt-text="Typical windows quality update experience" lightbox="../media/windows-quality-typical-update-experience.png":::
### Quality update deadline forces an update
@ -48,7 +48,7 @@ In the following example, the user:
The deadline specified in the update policy is five days. Therefore, once this deadline is passed, the device will ignore the [active hours](#servicing-window) and force a restart to complete the update installation. The user will receive a 15-minute warning, after which, the device will install the update and restart.
:::image type="content" source="../media/windows-quality-force-update.png" alt-text="Force Windows quality update":::
:::image type="content" source="../media/windows-quality-force-update.png" alt-text="Force Windows quality update" lightbox="../media/windows-quality-force-update.png":::
### Quality update grace period
@ -56,7 +56,7 @@ In the following example, the user is on holiday and the device is offline beyon
Since the deadline has already passed, the device is granted a two-day grace period to install the update and restart. The user will be notified of a pending installation and given options to choose from. Once the two-day grace period has expired, the user is forced to restart with a 15-minute warning notification.
:::image type="content" source="../media/windows-quality-update-grace-period.png" alt-text="Windows quality update grace period":::
:::image type="content" source="../media/windows-quality-update-grace-period.png" alt-text="Windows quality update grace period" lightbox="../media/windows-quality-update-grace-period.png":::
## Servicing window

6
windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-overview.md
View File

@ -50,7 +50,7 @@ To release updates to devices in a gradual manner, Windows Autopatch deploys a s
Windows Autopatch configures these policies differently across update rings to gradually release the update to devices in your estate. Devices in the Test ring receive changes first and devices in the Broad ring receive changes last. For more information, see [Windows Autopatch deployment rings](../operate/windows-autopatch-update-management.md#windows-autopatch-deployment-rings).
:::image type="content" source="../media/release-process-timeline.png" alt-text="Release process timeline":::
:::image type="content" source="../media/release-process-timeline.png" alt-text="Release process timeline" lightbox="../media/release-process-timeline.png":::
## Expedited releases
@ -74,10 +74,6 @@ If we pause the release, a policy will be deployed which prevents devices from u
You can pause or resume a Windows quality update from the Release management tab in Microsoft Endpoint Manager.
## Rollback
Windows Autopatch will rollback updates if we detect a [significant issue with a release](../operate/windows-autopatch-wqu-signals.md).
## Incidents and outages
If devices in your tenant aren't meeting the [service level objective](../operate/windows-autopatch-wqu-overview.md#service-level-objective) for Windows quality updates, an incident will be raised, and the Windows Autopatch Service Engineering Team will work to bring the devices back into compliance.

8
windows/deployment/windows-autopatch/operate/windows-autopatch-wqu-signals.md
View File

@ -40,9 +40,9 @@ The update is released to the Test ring on the second Tuesday of the month. Thos
## Device reliability signals
Windows Autopatch monitors devices for a set of core reliability metrics as a part of the service.
Windows Autopatch monitors devices for a set of core reliability metrics as a part of the service.
The service then uses statistical models to assess if there are significant differences between the two Windows versions. To make a statistically significant assessment, Windows Autopatch requires that at least 500 devices have upgraded to the new version.
The service then uses statistical models to assess if there are significant differences between the two Windows versions. To make a statistically significant assessment, Windows Autopatch requires that at least 500 devices in your tenant have upgraded to the new version.
As more devices update, the confidence of the analysis increases and gives us a clearer picture of release quality. If we determine that the user experience is impaired, Autopatch will either post a customer advisory or pause the release, depending on the criticality of the update.
@ -51,8 +51,8 @@ Autopatch monitors the following reliability signals:
| Device reliability signal | Description |
| ----- | ----- |
| Blue screens | These events are highly disruptive to end users so are closely watched. |
| Overall app reliability | Tracks the total number of app crashes and freezes on a device. A known issue with this measure is that if one app becomes 10% more reliable and another becomes 10% less reliable then it shows up as a flat line in the measure. |
| Microsoft Office reliability | Tracks the number of Office crashes or freezes per application per device. |
| Overall app reliability | Tracks the total number of app crashes and freezes on a device. A known limitation with this measure is that if one app becomes 10% more reliable and another becomes 10% less reliable then it shows up as a flat line in the measure. |
| Microsoft Office reliability | Tracks the number of Office crashes and freezes per application per device. |
| Microsoft Edge reliability | Tracks the number of Microsoft Edge crashes and freezes per device. |
| Microsoft Teams reliability | Tracks the number of Microsoft Teams crashes and freezes per device. |

13
windows/deployment/windows-autopatch/overview/windows-autopatch-faq.yml
View File

@ -4,7 +4,7 @@ metadata:
description: Answers to frequently asked questions about Windows Autopatch.
ms.prod: w11
ms.topic: faq
ms.date: 08/08/2022
ms.date: 08/26/2022
audience: itpro
ms.localizationpriority: medium
manager: dougeby
@ -51,7 +51,7 @@ sections:
- [Switch workloads for device configuration, Windows Update and Microsoft 365 Apps from Configuration Manager to Intune](/mem/configmgr/comanage/how-to-switch-workloads) (minimum Pilot Intune. Pilot collection must contain the devices you want to register into Autopatch.)
- question: What are the licensing requirements for Windows Autopatch?
answer: |
- Windows Autopatch is included with Window 10/11 Enterprise E3 or higher. For more information, see [More about licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses).
- Windows Autopatch is included with Window 10/11 Enterprise E3 or higher (user-based only). For more information, see [More about licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses).
- [Azure AD Premium](/azure/active-directory/fundamentals/active-directory-whatis#what-are-the-azure-ad-licenses) (for Co-management)
- [Microsoft Intune](/mem/intune/fundamentals/licenses) (includes Configuration Manager 2010 or greater via co-management)
- question: Are there hardware requirements for Windows Autopatch?
@ -67,21 +67,22 @@ sections:
No, Windows 365 Enterprise Cloud PC's support all features of Windows Autopatch. For more information, see [Virtual devices](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices#virtual-devices).
- question: Do my Cloud PCs appear any differently in the Windows Autopatch admin center?
answer: |
Cloud PC displays the model as the license type you have provisioned. For more information, see [Virtual devices](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices#virtual-devices).
Cloud PC displays the model as the license type you have provisioned. For more information, see [Windows Autopatch on Windows 365 Enterprise Workloads](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices#windows-autopatch-on-windows-365-enterprise-workloads).
- question: Can I run Autopatch on my Windows 365 Business Workloads?
answer: |
No. Autopatch is only available on enterprise workloads. For more information, see [Virtual devices](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices#virtual-devices).
No. Autopatch is only available on enterprise workloads. For more information, see [Windows Autopatch on Windows 365 Enterprise Workloads](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices#windows-autopatch-on-windows-365-enterprise-workloads).
- name: Update Management
questions:
- question: What systems does Windows Autopatch update?
answer: |
- Windows 10/11 quality updates: Windows Autopatch manages all aspects of update rings.
- Windows 10/11 feature updates: Windows Autopatch manages all aspects of update rings.
- Microsoft 365 Apps for enterprise updates: All devices registered for Windows Autopatch will receive updates from the Monthly Enterprise Channel.
- Microsoft Edge: Windows Autopatch configures eligible devices to benefit from Microsoft Edge's progressive rollouts on the Stable channel and will provide support for issues with Microsoft Edge updates.
- Microsoft Teams: Windows Autopatch allows eligible devices to benefit from the standard automatic update channels and will provide support for issues with Teams updates.
- question: What does Windows Autopatch do to ensure updates are done successfully?
answer: |
For Windows quality updates, updates are applied to device in the Test ring first. The devices are evaluated, and then rolled out to the First, Fast then Broad rings. There's an evaluation period at each progression. This process is dependent on customer testing and verification of all updates during these rollout stages. The outcome is to ensure that registered devices are always up to date and disruption to business operations is minimized to free up your IT department from that ongoing task.
For Windows quality updates, updates are applied to devices in the Test ring first. The devices are evaluated, and then rolled out to the First, Fast then Broad rings. There's an evaluation period at each progression. This process is dependent on customer testing and verification of all updates during these rollout stages. The outcome is to ensure that registered devices are always up to date and disruption to business operations is minimized to free up your IT department from that ongoing task.
- question: What happens if there's an issue with an update?
answer: |
Autopatch relies on the following capabilities to help resolve update issues:
@ -98,7 +99,7 @@ sections:
No, you can't customize update scheduling. However, you can specify [active hours](../operate/windows-autopatch-wqu-end-user-exp.md#servicing-window) to prevent users from updating during business hours.
- question: Does Autopatch support include and exclude groups, or dynamic groups to define deployment ring membership?
answer: |
Windows autopatch doesn't support managing update deployment ring membership using your Azure AD groups. For more information, see [Moving devices in between deployment rings](../operate/windows-autopatch-update-management.md#moving-devices-in-between-deployment-rings).
Windows Autopatch doesn't support managing update deployment ring membership using your Azure AD groups. For more information, see [Moving devices in between deployment rings](../operate/windows-autopatch-update-management.md#moving-devices-in-between-deployment-rings).
- question: Does Autopatch have two release cadences per update or are there two release cadences per-ring?
answer: |
The release cadences are defined based on the update type. For example, a [regular cadence](../operate/windows-autopatch-wqu-overview.md#windows-quality-update-releases) (for a Windows quality update would be a gradual rollout from the Test ring to the Broad ring over 14 days whereas an [expedited release](../operate/windows-autopatch-wqu-overview.md#expedited-releases) would roll out more rapidly.

10
windows/deployment/windows-autopatch/prepare/windows-autopatch-enroll-tenant.md
View File

@ -14,7 +14,7 @@ msreviewer: hathind
# Enroll your tenant
Before you enroll in Windows Autopatch, there are settings and other parameters you must set ahead of time.
Before you enroll in Windows Autopatch, there are settings, and other parameters you must set ahead of time.
> [!IMPORTANT]
> You must be a Global Administrator to enroll your tenant.
@ -30,7 +30,7 @@ To start using the Windows Autopatch service, ensure you meet the [Windows Autop
> [!IMPORTANT]
> The online Readiness assessment tool helps you check your readiness to enroll in Windows Autopatch for the first time. Once you enroll, you'll no longer be able to access the tool again.
The Readiness assessment tool checks the settings in [Microsoft Endpoint Manager](#microsoft-intune-settings) (specifically, Microsoft Intune) and [Azure Active Directory](#azure-active-directory-settings) (Azure AD) to ensure they'll work with Windows Autopatch. We aren't, however, checking the workloads in Configuration Manager necessary for Windows Autopatch. For more information about workload prerequisites, see [Configuration Manager Co-management requirements](../prepare/windows-autopatch-prerequisites.md#configuration-manager-co-management-requirements).
The Readiness assessment tool checks the settings in [Microsoft Endpoint Manager](#microsoft-intune-settings) (specifically, Microsoft Intune) and [Azure Active Directory](#azure-active-directory-settings) (Azure AD) to ensure they'll work with Windows Autopatch. We aren't, however, checking the workloads in Configuration Manager necessary for Windows Autopatch. For more information about workload prerequisites, see [Configuration Manager co-management requirements](../prepare/windows-autopatch-prerequisites.md#configuration-manager-co-management-requirements).
**To access and run the Readiness assessment tool:**
@ -43,8 +43,6 @@ The Readiness assessment tool checks the settings in [Microsoft Endpoint Manager
> [!IMPORTANT]
> If you don't see the Tenant enrollment blade, this is because you don't meet the prerequisites or the proper licenses. For more information, see [Windows Autopatch prerequisites](windows-autopatch-prerequisites.md#more-about-licenses).
A Global Administrator should be used to run this tool. Other roles, such as the Global Reader and Intune Administrator have insufficient permissions to complete the checks on Conditional Access Policies and Multi-factor Authentication. For more information about the extra permissions, see [Conditional access policies](../prepare/windows-autopatch-fix-issues.md#conditional-access-policies).
The Readiness assessment tool checks the following settings:
### Microsoft Intune settings
@ -62,9 +60,7 @@ The following are the Azure Active Directory settings:
| Check | Description |
| ----- | ----- |
| Conditional access | Verifies that conditional access policies and multi-factor authentication aren't assigned to all users.<p><p>Your conditional access policies must not prevent our service accounts from accessing the service and must not require multi-factor authentication. For more information, see [Conditional access policies](../prepare/windows-autopatch-fix-issues.md#conditional-access-policies). |
| Windows Autopatch cloud service accounts | Checks that no usernames conflict with ones that Windows Autopatch reserves for its own use. The cloud service accounts are:<ul><li>MsAdmin</li><li>MsAdminInt</li><li>MsTest</li></ul> For more information, see [Tenant access](../references/windows-autopatch-privacy.md#tenant-access). |
| Security defaults | Checks whether your Azure Active Directory organization has security defaults enabled. |
| Co-management | This advisory check only applies if co-management is applied to your tenant. This check ensures that the proper workloads are in place for Windows Autopatch. If co-management doesn't apply to your tenant, this check can be safely disregarded, and won't block device deployment. |
| Licenses | Checks that you've obtained the necessary [licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses). |
### Check results

25
windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md
View File

@ -25,7 +25,7 @@ For each check, the tool will report one of four possible results:
| Ready | No action is required before completing enrollment. |
| Advisory | Follow the steps in the tool or this article for the best experience with enrollment and for users.<p><p>You can complete enrollment, but you must fix these issues before you deploy your first device. |
| Not ready | You must fix these issues before enrollment. You won’t be able to enroll into Windows Autopatch if you don't fix these issues. Follow the steps in the tool or this article to resolve them. |
| Error | The Azure Active Directory (AD) role you're using doesn't have sufficient permission to run this check or your tenant is not properly licensed for Microsoft Intune. |
| Error | The Azure Active Directory (AD) role you're using doesn't have sufficient permission to run this check or your tenant isn't properly licensed for Microsoft Intune. |
> [!NOTE]
> The results reported by this tool reflect the status of your settings only at the time that you ran it. If you make changes later to policies in Microsoft Intune, Azure Active Directory (AD), or Microsoft 365, items that were "Ready" can become "Not ready". To avoid problems with Windows Autopatch operations, review the specific settings described in this article before you change any policies.
@ -55,14 +55,13 @@ Your "Windows 10 update ring" policy in Intune must not target any Windows Autop
You can access Azure Active Directory (AD) settings in the [Azure portal](https://portal.azure.com/).
### Conditional access policies
### Co-management
Conditional access policies must not prevent Windows Autopatch from connecting to your tenant.
Co-management enables you to concurrently manage Windows 10 or later devices by using both Configuration Manager and Microsoft Intune.
| Result | Meaning |
| ----- | ----- |
| Advisory | You have at least one conditional access policy that targets all users or at least one conditional access policy set as required for multi-factor authentication. These policies could prevent Windows Autopatch from managing the Windows Autopatch service.<p><p>During enrollment, we'll attempt to exclude Windows Autopatch service accounts from relevant conditional access policies and apply new conditional access policies to restrict access to these accounts. However, if we're unsuccessful, this can cause errors during your enrollment experience.<p><p>For best practice, [create an assignment that targets a specific Azure Active Directory (AD) group](/azure/active-directory/fundamentals/active-directory-groups-create-azure-portal) that doesn't include Windows Autopatch service accounts.</p> |
| Error | The Intune Administrator role doesn't have sufficient permissions for this check. You'll also need to have these Azure Active Directory (AD) roles assigned to run this check:<br><ul><li>Security Reader</li><li>Security Administrator</li><li>Conditional Access Administrator</li><li>Global Reader</li><li>Devices Administrator</li></ul> |
| Advisory | To successfully enroll devices that are co-managed into Windows Autopatch, it's necessary that the following co-managed workloads are set to **Intune**:<ul><li>Device configuration</li><li>Windows update policies</li><li>Office 365 client apps</li></ul><p>If co-management doesn't apply to your tenant, this check can be safely disregarded, and it won't block device deployment.</p> |
### Licenses
@ -71,19 +70,3 @@ Windows Autopatch requires the following licenses:
| Result | Meaning |
| ----- | ----- |
| Not ready | Windows Autopatch requires Windows 10/11 Enterprise E3 (or higher) to be assigned to your users. Additionally, Azure Active Directory Premium, and Microsoft Intune are required. For more information, see [more about licenses](../prepare/windows-autopatch-prerequisites.md#more-about-licenses). |
### Windows Autopatch cloud service accounts
Certain account names could conflict with account names created by Windows Autopatch.
| Result | Meaning |
| ----- | ----- |
| Not ready | You have at least one account name that will conflict with account names created by Windows Autopatch. The cloud service accounts are:<ul><li>MsAdmin</li><li>MsAdminInt</li><li>MsTest</li></ul><p>You must either rename or remove conflicting accounts to move forward with enrolling to the Windows Autopatch service as we'll create these accounts as part of running our service. For more information, see [Tenant Access](../references/windows-autopatch-privacy.md#tenant-access).</p> |
### Security defaults
Security defaults in Azure Active Directory (AD) will prevent Windows Autopatch from managing your devices.
| Result | Meaning |
| ----- | ----- |
| Not ready | You have Security defaults turned on. Turn off Security defaults and set up conditional access policies. For more information, see [Common conditional access policies](/azure/active-directory/conditional-access/concept-conditional-access-policy-common). |

12
windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites.md
View File

@ -1,7 +1,7 @@
---
title: Prerequisites
description: This article details the prerequisites needed for Windows Autopatch
ms.date: 08/04/2022
ms.date: 09/16/2022
ms.prod: w11
ms.technology: windows
ms.topic: conceptual
@ -24,12 +24,12 @@ Getting started with Windows Autopatch has been designed to be easy. This articl
| Licensing | Windows Autopatch requires Windows 10/11 Enterprise E3 (or higher) to be assigned to your users. Additionally, Azure Active Directory Premium and Microsoft Intune are required. For details about the specific service plans, see [more about licenses](#more-about-licenses).<p><p>For more information on available licenses, see [Microsoft 365 licensing](https://www.microsoft.com/microsoft-365/compare-microsoft-365-enterprise-plans).<p><p>For more information about licensing terms and conditions for products and services purchased through Microsoft Commercial Volume Licensing Programs, see the [Product Terms site](https://www.microsoft.com/licensing/terms/). |
| Connectivity | All Windows Autopatch devices require connectivity to multiple Microsoft service endpoints from the corporate network.<p><p>For the full list of required IPs and URLs, see [Configure your network](../prepare/windows-autopatch-configure-network.md). |
| Azure Active Directory | Azure Active Directory must either be the source of authority for all user accounts, or user accounts must be synchronized from on-premises Active Directory using the latest supported version of Azure Active Directory Connect to enable Hybrid Azure Active Directory join.<br><ul><li>For more information, see [Azure Active Directory Connect](/azure/active-directory/hybrid/whatis-azure-ad-connect) and [Hybrid Azure Active Directory join](/azure/active-directory/devices/howto-hybrid-azure-ad-join)</li><li>For more information on supported Azure Active Directory Connect versions, see [Azure AD Connect:Version release history](/azure/active-directory/hybrid/reference-connect-version-history).</li></ul> |
| Device management | Windows Autopatch devices must be managed by Microsoft Intune. Intune must be set as the Mobile Device Management (MDM) authority or co-management must be turned on and enabled on the target devices.<p><p>At a minimum, the Windows Update, Device configuration and Office Click-to-Run apps workloads must be set to Pilot Intune or Intune. You must also ensure that the devices you intend on bringing to Windows Autopatch are in the targeted device collection. For more information, see Co-management requirements for Windows Autopatch below.<p>Other device management prerequisites include:<ul><li>Devices must be corporate-owned. Windows bring-your-own-devices (BYOD) are blocked during device registration prerequisite checks.</li><li>Devices must be managed by either Intune or Configuration Manager Co-management. Devices only managed by Configuration Manager aren't supported.</li><li>Devices must be in communication with Microsoft Intune in the **last 28 days**. Otherwise, the devices won't be registered with Autopatch.</li><li>Devices must be connected to the internet.</li><li>Devices must have a **Serial number**, **Model** and **Manufacturer**. Device emulators that don't generate this information fail to meet **Intune or Cloud-attached** prerequisite check.</li></ul><p>See [Register your devices](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices) for more details on device prerequisites and on how the device registration process works.<p>For more information on co-management, see [Co-management for Windows devices](/mem/configmgr/comanage/overview).</p> |
| Device management | Windows Autopatch devices must be managed by Microsoft Intune. Intune must be set as the Mobile Device Management (MDM) authority or co-management must be turned on and enabled on the target devices.<p><p>At a minimum, the Windows Update, Device configuration and Office Click-to-Run apps workloads must be set to Pilot Intune or Intune. You must also ensure that the devices you intend on bringing to Windows Autopatch are in the targeted device collection. For more information, see [co-management requirements for Windows Autopatch](#configuration-manager-co-management-requirements).<p>Other device management prerequisites include:<ul><li>Devices must be corporate-owned. Windows bring-your-own-devices (BYOD) are blocked during device registration prerequisite checks.</li><li>Devices must be managed by either Intune or Configuration Manager co-management. Devices only managed by Configuration Manager aren't supported.</li><li>Devices must be in communication with Microsoft Intune in the **last 28 days**. Otherwise, the devices won't be registered with Autopatch.</li><li>Devices must be connected to the internet.</li><li>Devices must have a **Serial number**, **Model** and **Manufacturer**. Device emulators that don't generate this information fail to meet **Intune or Cloud-attached** prerequisite check.</li></ul><p>See [Register your devices](/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices) for more details on device prerequisites and on how the device registration process works.<p>For more information on co-management, see [co-management for Windows devices](/mem/configmgr/comanage/overview).</p> |
| Data and privacy | For more information on Windows Autopatch privacy practices, see [Windows Autopatch Privacy](../references/windows-autopatch-privacy.md). |
## More about licenses
Windows Autopatch is included with Window 10/11 Enterprise E3 or higher. The following are the other licenses that grant entitlement to Windows Autopatch:
Windows Autopatch is included with Window 10/11 Enterprise E3 or higher (user-based only). The following are the service plan SKUs that are eligible for Windows Autopatch:
| License | ID | GUID number |
| ----- | ----- | ------|
@ -45,13 +45,13 @@ The following Windows OS 10 editions, 1809 builds and architecture are supported
- Windows 10 (1809+)/11 Enterprise
- Windows 10 (1809+)/11 Pro for Workstations
## Configuration Manager Co-management requirements
## Configuration Manager co-management requirements
Windows Autopatch fully supports co-management. The following co-management requirements apply:
- Use a currently supported [Configuration Manager version](/mem/configmgr/core/servers/manage/updates#supported-versions).
- ConfigMgr must be [cloud-attached with Intune (Co-management)](/mem/configmgr/cloud-attach/overview) and must have the following Co-management workloads enabled:
- Set the [Windows Update workload](/mem/configmgr/comanage/workloads#windows-update-policies) to Pilot Intune or Intune.
- ConfigMgr must be [cloud-attached with Intune (co-management)](/mem/configmgr/cloud-attach/overview) and must have the following co-management workloads enabled:
- Set the [Windows Update policies workload](/mem/configmgr/comanage/workloads#windows-update-policies) to Pilot Intune or Intune.
- Set the [Device configuration workload](/mem/configmgr/comanage/workloads#device-configuration) to Pilot Intune or Intune.
- Set the [Office Click-to-Run apps workload](/mem/configmgr/comanage/workloads#office-click-to-run-apps) to Pilot Intune or Intune.

43
windows/deployment/windows-autopatch/references/windows-autopatch-changes-to-tenant.md
View File

@ -14,6 +14,11 @@ msreviewer: hathind
# Changes made at tenant enrollment
The following configuration details are provided as information to help you understand the changes made to your tenant when enrolling into the Windows Autopatch service.
> [!IMPORTANT]
> The service manages and maintains the following configuration items. Don't change, edit, add to, or remove any of the configurations. Doing so might cause unintended configuration conflicts and impact the Windows Autopatch service.
## Service principal
Windows Autopatch will create a service principal in your tenant allowing the service to establish an identity and restrict access to what resources the service has access to within the tenant. For more information, see [Application and service principal objects in Azure Active Directory](/azure/active-directory/develop/app-objects-and-service-principals#service-principal-object). The service principal created by Windows Autopatch is:
@ -22,25 +27,21 @@ Windows Autopatch will create a service principal in your tenant allowing the se
## Azure Active Directory groups
Windows Autopatch will create Azure Active Directory groups that are required to operate the service. The following groups are used for targeting Windows Autopatch configurations to devices and management of the service by our service accounts.
Windows Autopatch will create Azure Active Directory groups that are required to operate the service. The following groups are used for targeting Windows Autopatch configurations to devices and management of the service by our [first party enterprise applications](#windows-autopatch-enterprise-applications).
| Group name | Description |
| ----- | ----- |
| Modern Workplace-All | All Modern Workplace users |
| Modern Workplace - Windows 11 Pre-Release Test Devices | Device group for Windows 11 Pre-Release testing. |
| Modern Workplace Devices-All | All Modern Workplace devices |
| Modern Workplace Devices-Windows Autopatch-Test | Immediate ring for device rollout |
| Modern Workplace Devices-Windows Autopatch-First | First production ring for early adopters |
| Modern Workplace Devices-Windows Autopatch-Fast | Fast ring for quick rollout and adoption |
| Modern Workplace Devices-Windows Autopatch-Broad | Final ring for broad rollout into an organization |
| Modern Workplace Devices-Windows Autopatch-Test | Deployment ring for testing update deployments prior production rollout |
| Modern Workplace Devices-Windows Autopatch-First | First production deployment ring for early adopters |
| Modern Workplace Devices-Windows Autopatch-Fast | Fast deployment ring for quick rollout and adoption |
| Modern Workplace Devices-Windows Autopatch-Broad | Final deployment ring for broad rollout into the organization |
| Modern Workplace Devices Dynamic - Windows 10 | Microsoft Managed Desktop Devices with Windows 10<p>Group Rule:<ul><li>`(device.devicePhysicalIds -any _ -startsWith \"[OrderID]:Microsoft365Managed_\")`</li><li>`(device.deviceOSVersion -notStartsWith \"10.0.22000\")`</li></ul><br>Exclusions:<ul><li>Modern Workplace - Telemetry Settings for Windows 11</li></ul> |
| Modern Workplace Devices Dynamic - Windows 11 | Microsoft Managed Desktop Devices with Windows 11<p>Group Rule:<ul><li>`(device.devicePhysicalIds -any _ -startsWith \"[OrderID]:Microsoft365Managed_\")`</li><li>`(device.deviceOSVersion -startsWith \"10.0.22000\")`</li></ul><br>Exclusions:<ul><li>Modern Workplace - Telemetry Settings for Windows 10</li></ul> |
| Modern Workplace Roles - Service Administrator | All users granted access to Modern Workplace Service Administrator Role |
| Modern Workplace Roles - Service Reader | All users granted access to Modern Workplace Service Reader Role |
| Modern Workplace Service - Intune Admin All | Group for Intune Admins<p>Assigned to: <ul><li>Modern Workplace Service Accounts</li></ul>|
| Modern Workplace Service - Intune Reader All | Group for Intune readers<p>Assigned to: <ul><li>Modern Workplace Service Accounts</li></ul>|
| Modern Workplace Service - Intune Reader MMD | Group for Intune readers of MMD devices and users<p>Assigned to:<ul><li>Modern Workplace Service Accounts</li></ul>|
| Modern Workplace Service Accounts | Group for Windows Autopatch service accounts |
| Windows Autopatch Device Registration | Group for automatic device registration for Windows Autopatch |
## Windows Autopatch enterprise applications
@ -56,19 +57,6 @@ Windows Autopatch creates an enterprise application in your tenant. This enterpr
> [!NOTE]
> Enterprise application authentication is only available on tenants enrolled after July 9th, 2022. For tenants enrolled before this date, Enterprise Application authentication will be made available for enrollment soon.
## Windows Autopatch cloud service accounts
Windows Autopatch will create three cloud service accounts in your tenant. These accounts are used to run the service and all need to be excluded from any multi-factor authentication controls.
> [!NOTE]
> Effective Aug 15th, 2022, these accounts will no longer be added to newly enrolled tenants, and existing tenants will be provided an option to migrate to enterprise application-based authentication. These accounts will be removed with that transition.
| Cloud service account name | Usage | Mitigating controls |
| ----- | ----- | ------ |
| MsAdmin@tenantDomain.onmicrosoft.com | <ul><li>This account is a limited-service account with administrator privileges. This account is used as an Intune and User administrator to define and configure the tenant for Microsoft Modern desktop devices.</li><li>This account doesn't have interactive sign-in permissions.  The account performs operations only through the service.</li></ul> | Audited sign-ins |
| MsAdminInt@tenantDomain.onmicrosoft.com | <ul><li>This account is an Intune and User administrator account used to define and configure the tenant for Modern Workplace devices.</li><li>This account is used for interactive sign-in to the customers’ tenant.</li><li>The use of this account is extremely limited as most operations are exclusively through msadmin (non-interactive).</li> | <ul><li>Restricted to be accessed only from defined secure access workstations (SAWs) through the Modern Workplace - Secure Workstation conditional access policy.</li><li>Audited sign-ins</li></ul> |
| MsTest@tenantDomain.onmicrosoft.com | This is a standard account used as a validation account for initial configuration and roll out of policy, application, and device compliance settings. | Audited sign-ins |
## Device configuration policies
- Modern Workplace - Set MDM to Win Over GPO
@ -145,17 +133,8 @@ Windows Autopatch will create three cloud service accounts in your tenant. These
| Modern Workplace - Edge Update Channel Stable | Deploys updates via the Edge Stable Channel<p>Assigned to:<ul><li>Modern Workplace Devices-Windows Autopatch-First</li><li>Modern Workplace Devices-Windows Autopatch-Fast</li><li>Modern Workplace Devices-Windows Autopatch-Broad</li></ul>| `./Device/Vendor/MSFT/Policy/Config/MicrosoftEdgeUpdate~Policy~Cat_EdgeUpdate~Cat_Applications~Cat_MicrosoftEdge/Pol_TargetChannelMicrosoftEdge` | Enabled |
| Modern Workplace - Edge Update Channel Beta | Deploys updates via the Edge Beta Channel<p>Assigned to:<ul><li>Modern Workplace Devices-Windows Autopatch-Test </li></ul>| `./Device/Vendor/MSFT/Policy/Config/MicrosoftEdgeUpdate~Policy~Cat_EdgeUpdate~Cat_Applications~Cat_MicrosoftEdge/Pol_TargetChannelMicrosoftEdge` | Enabled |
## Conditional access policies
> [!NOTE]
> Effective Aug 15, 2022, the following policy will no longer be added to newly enrolled tenants, and existing tenants will be provided an option to migrate to enterprise application-based authentication. This policy will be removed with that transition.
| Conditional access policy | Description |
| ----- | ----- |
| Modern Workplace - Secure Workstation | This policy is targeted to only the Windows Autopatch cloud service accounts. The policy blocks access to the tenant unless the user is accessing the tenant from a Microsoft authorized location. |
## PowerShell scripts
| Script | Description |
| ----- | ----- |
| Modern Workplace - Autopatch Client Setup | Installs necessary client components for the Windows Autopatch service |
| Modern Workplace - Autopatch Client Setup v1.1 | Installs necessary client components for the Windows Autopatch service |

4
windows/deployment/windows-autopatch/references/windows-autopatch-privacy.md
View File

@ -20,7 +20,7 @@ Windows Autopatch is a cloud service for enterprise customers designed to keep e
Windows Autopatch provides its service to enterprise customers, and properly administers customers' enrolled devices by using data from various sources.
The sources include Azure Active Directory (AD), Microsoft Intune, and Microsoft Windows 10/11. The sources provide a comprehensive view of the devices that Windows Autopatch manages. The service also uses these Microsoft services to enable Windows Autopatch to provide IT as a Service (ITaaS) capabilities:
The sources include Azure Active Directory (Azure AD), Microsoft Intune, and Microsoft Windows 10/11. The sources provide a comprehensive view of the devices that Windows Autopatch manages.
| Data source | Purpose |
| ------ | ------ |
@ -74,7 +74,7 @@ Microsoft Windows Update for Business uses data from Windows diagnostics to anal
## Microsoft Azure Active Directory
Identifying data used by Windows Autopatch is stored by Azure Active Directory (Azure AD) in a geographical location. The geographical location is based on the location provided by the organization upon subscribing to Microsoft online services, such as Microsoft Apps for Enterprise and Azure. For more information on where your Azure AD data is located, see [Azure Active Directory - Where is your data located?](https://msit.powerbi.com/view?r=eyJrIjoiODdjOWViZDctMWRhZS00ODUzLWI4MmQtNWM5NjBkZTBkNjFlIiwidCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsImMiOjV9)
Identifying data used by Windows Autopatch is stored by Azure Active Directory (AD) in a geographical location. The geographical location is based on the location provided by the organization upon subscribing to Microsoft online services, such as Microsoft Apps for Enterprise and Azure. For more information on where your Azure AD data is located, see [Azure Active Directory - Where is your data located?](https://msit.powerbi.com/view?r=eyJrIjoiODdjOWViZDctMWRhZS00ODUzLWI4MmQtNWM5NjBkZTBkNjFlIiwidCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsImMiOjV9)
## Microsoft Intune

10
windows/deployment/windows-autopilot/demonstrate-deployment-on-vm.md
View File

@ -419,15 +419,9 @@ Your VM (or device) can be registered either via Intune or Microsoft Store for B
> [!IMPORTANT]
> If you've already registered your VM (or device) using Intune, then skip this step.
Optional: see the following video for an overview of the process.
&nbsp;
> [!video https://www.youtube.com/embed/IpLIZU_j7Z0]
First, you need a Microsoft Store for Business account. You can use the same one you created above for Intune, or follow [these instructions](/microsoft-store/windows-store-for-business-overview) to create a new one.
Next, to sign in to [Microsoft Store for Business](https://businessstore.microsoft.com/en-us/store) with your test account, select **Sign in** on the upper-right-corner of the main page.
Next, to sign in to [Microsoft Store for Business](https://businessstore.microsoft.com/store) with your test account, select **Sign in** on the upper-right-corner of the main page.
Select **Manage** from the top menu, then select the **Windows Autopilot Deployment Program** link under the **Devices** card. See the following example:
@ -528,8 +522,6 @@ Select **OK**, and then select **Create**.
If you already created and assigned a profile via Intune with the steps immediately above, then skip this section.
A [video](https://www.youtube.com/watch?v=IpLIZU_j7Z0) is available that covers the steps required to create and assign profiles in Microsoft Store for Business. These steps are also summarized below.
First, sign in to the [Microsoft Store for Business](https://businessstore.microsoft.com/manage/dashboard) using the Intune account you initially created for this lab.
Select **Manage** from the top menu, then select **Devices** from the left navigation tree.