deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-13 13:57:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge branch 'release-mcc-ent' into nidos-mcc

Browse Source
This commit is contained in:
Nidhi Doshi 2024-09-19 11:20:34 -07:00 committed by GitHub
commit 18a3d5fe0b
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
164 changed files with 3455 additions and 3383 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
.openpublishing.redirection.json
View File

@ -11492,12 +11492,12 @@
},
{
"source_path": "windows/plan/windows-10-deployment-considerations.md",
"redirect_url": "/windows/deployment/planning/windows-10-deployment-considerations",
"redirect_url": "/previous-versions/windows/it-pro/windows-10/deployment/planning/windows-10-deployment-considerations",
"redirect_document_id": false
},
{
"source_path": "windows/plan/windows-10-enterprise-faq-itpro.md",
"redirect_url": "/windows/deployment/planning/windows-10-enterprise-faq-itpro",
"redirect_url": "/previous-versions/windows/it-pro/windows-10/deployment/planning/windows-10-enterprise-faq-itpro",
"redirect_document_id": false
},
{
@ -11507,7 +11507,7 @@
},
{
"source_path": "windows/plan/windows-10-infrastructure-requirements.md",
"redirect_url": "/windows/deployment/planning/windows-10-infrastructure-requirements",
"redirect_url": "/previous-versions/windows/it-pro/windows-10/deployment/planning/windows-10-infrastructure-requirements",
"redirect_document_id": false
},
{

60
.openpublishing.redirection.windows-deployment.json
View File

@ -1595,6 +1595,51 @@
"redirect_url": "/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-update-policies",
"redirect_document_id": false
},
{
"source_path": "windows/deployment/windows-autopatch/prepare/windows-autopatch-fix-issues.md",
"redirect_url": "/windows/deployment/windows-autopatch/prepare/windows-autopatch-feature-activation",
"redirect_document_id": false
},
{
"source_path": "windows/deployment/windows-autopatch/prepare/windows-autopatch-enrollment-support-request.md",
"redirect_url": "/windows/deployment/windows-autopatch/prepare/windows-autopatch-feature-activation",
"redirect_document_id": false
},
{
"source_path": "windows/deployment/windows-autopatch/manage/windows-autopatch-manage-windows-feature-update-releases.md",
"redirect_url": "/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-overview",
"redirect_document_id": false
},
{
"source_path": "windows/deployment/update/deployment-service-overview.md",
"redirect_url": "/windows/deployment/windows-autopatch/overview/windows-autopatch-overview",
"redirect_document_id": true
},
{
"source_path": "windows/deployment/update/deployment-service-prerequisites.md",
"redirect_url": "/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites",
"redirect_document_id": false
},
{
"source_path": "windows/deployment/update/deployment-service-feature-updates.md",
"redirect_url": "/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-programmatic-controls",
"redirect_document_id": true
},
{
"source_path": "windows/deployment/update/deployment-service-expedited-updates.md",
"redirect_url": "/windows/deployment/windows-autopatch/manage/windows-autopatch-windows-quality-update-programmatic-controls",
"redirect_document_id": true
},
{
"source_path": "windows/deployment/update/deployment-service-drivers.md",
"redirect_url": "/windows/deployment/windows-autopatch/manage/windows-autopatch-driver-and-firmware-update-programmatic-controls",
"redirect_document_id": true
},
{
"source_path": "windows/deployment/update/deployment-service-troubleshoot.md",
"redirect_url": "/windows/deployment/windows-autopatch/manage/windows-autopatch-troubleshoot-programmatic-controls",
"redirect_document_id": false
},
{
"source_path": "windows/deployment/update/PSFxWhitepaper.md",
"redirect_url": "/windows/deployment/update/forward-reverse-differentials",
@ -1604,6 +1649,21 @@
"source_path": "windows/deployment/upgrade/windows-10-upgrade-paths.md",
"redirect_url": "/windows/deployment/upgrade/windows-upgrade-paths",
"redirect_document_id": false
},
{
"source_path": "windows/deployment/planning/windows-10-infrastructure-requirements.md",
"redirect_url": "/previous-versions/windows/it-pro/windows-10/deployment/planning/windows-10-infrastructure-requirements",
"redirect_document_id": false
},
{
"source_path": "windows/deployment/planning/windows-10-enterprise-faq-itpro.yml",
"redirect_url": "/previous-versions/windows/it-pro/windows-10/deployment/planning/windows-10-enterprise-faq-itpro",
"redirect_document_id": false
},
{
"source_path": "windows/deployment/planning/windows-10-deployment-considerations.md",
"redirect_url": "/previous-versions/windows/it-pro/windows-10/deployment/planning/windows-10-deployment-considerations",
"redirect_document_id": false
}
]
}

4
education/windows/edu-take-a-test-kiosk-mode.md
View File

@ -1,7 +1,7 @@
---
title: Configure Take a Test in kiosk mode
description: Learn how to configure Windows to execute the Take a Test app in kiosk mode, using Intune and provisioning packages.
ms.date: 11/08/2023
ms.date: 09/06/2024
ms.topic: how-to
---
@ -26,7 +26,7 @@ The other options allow you to configure Take a Test in kiosk mode using a local
Follow the instructions below to configure your devices, selecting the option that best suits your needs.
# [:::image type="icon" source="images/icons/intune.svg"::: **Intune**](#tab/intune)
# [:::image type="icon" source="images/icons/intune.svg"::: **Intune/CSP**](#tab/intune)
You can use Intune for Education or a custom profile in Microsoft Intune:

2
education/windows/take-a-test-app-technical.md
View File

@ -1,7 +1,7 @@
---
title: Take a Test app technical reference
description: List of policies and settings applied by the Take a Test app.
ms.date: 11/02/2023
ms.date: 09/06/2024
ms.topic: reference
---

6
windows/application-management/overview-windows-apps.md
View File

@ -4,7 +4,7 @@ description: Learn about the different types of apps that run on Windows. For ex
author: aczechowski
ms.author: aaroncz
manager: aaroncz
ms.date: 06/28/2024
ms.date: 09/03/2024
ms.topic: overview
ms.service: windows-client
ms.subservice: itpro-apps
@ -126,9 +126,7 @@ For more information, see:
When you use the Microsoft Store app, Windows users can download apps from the public store. They can also download apps provided by your organization, which is called the *private store*. If your organization creates its own apps, you can use [Windows Package Manager](/windows/package-manager) to add apps to the private store.
> [!NOTE]
> Retirement of the Microsoft Store for Business and Microsoft Store for Education has been postponed. We will update this notice when a new retirement date is announced. Customers may continue to use the current capabilities for free apps until that time. There will be no support for Microsoft Store for Business and Education for Windows 11.
>
> For more information, see [Evolving the Microsoft Store for Business and Education](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/evolving-the-microsoft-store-for-business-and-education/bc-p/3771217). This blog post describes the new Microsoft Store experience for both Windows 11 and Windows 10. To learn about other options for getting and managing apps, see [Add Microsoft Store apps to Microsoft Intune](/mem/intune/apps/store-apps-microsoft).
> The Microsoft Store for Business and Microsoft Store for Education are retired. For more information, see [Microsoft Store for Business and Education retiring March 31, 2023](/lifecycle/announcements/microsoft-store-for-business-education-retiring). There will be no support for Microsoft Store for Business and Education for Windows 11.
To help manage the Microsoft Store on your devices, you can use policies:

4
windows/application-management/private-app-repository-mdm-company-portal-windows-11.md
View File

@ -4,7 +4,7 @@ description: Use the Company Portal app in Windows 11 devices to access the priv
author: aczechowski
ms.author: aaroncz
manager: aaroncz
ms.date: 04/04/2023
ms.date: 09/03/2023
ms.topic: conceptual
ms.service: windows-client
ms.subservice: itpro-apps
@ -104,4 +104,4 @@ If you use a third party or partner MDM provider, be sure to configure the setti
## Windows Package Manager
If your organization creates its own apps, your app developers can use [Windows Package Manager](/windows/package-manager/) to deploy apps. For more information on Intune and Windows Package Manager, see [Evolving the Microsoft Store for Business and Education](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/evolving-the-microsoft-store-for-business-and-education/ba-p/2569423).
If your organization creates its own apps, your app developers can use [Windows Package Manager](/windows/package-manager/) to deploy apps. For more information on Intune and Windows Package Manager, see [Evolving the Microsoft Store for Business and Education](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/evolving-the-microsoft-store-for-business-and-education/ba-p/2569423) and [Microsoft Store for Business and Education retiring March 31, 2023](/lifecycle/announcements/microsoft-store-for-business-education-retiring).

3
windows/client-management/client-tools/quick-assist.md
View File

@ -106,6 +106,7 @@ For more information, visit [Install Quick Assist](https://support.microsoft.com
To deploy Quick Assist with Intune, see [Add Microsoft Store apps to Microsoft Intune](/mem/intune/apps/store-apps-microsoft).
<!-- commenting out since Store for Business and Microsoft Store for Education retired May 31, 20203
### Install Quick Assist Offline
To install Quick Assist offline, you need to download your APPXBUNDLE and unencoded XML file from [Microsoft Store for Business](https://businessstore.microsoft.com). Visit [Download an offline-licensed app](/microsoft-store/distribute-offline-apps#download-an-offline-licensed-app) for more information.
@ -113,7 +114,7 @@ To install Quick Assist offline, you need to download your APPXBUNDLE and unenco
1. Start **Windows PowerShell** with Administrative privileges
1. In PowerShell, change the directory to the location where you saved the file in step 1: `cd <location of package file>`
1. To install Quick Assist, run the following command: `Add-AppxProvisionedPackage -Online -PackagePath "MicrosoftCorporationII.QuickAssist_8wekyb3d8bbwe.AppxBundle" -LicensePath "MicrosoftCorporationII.QuickAssist_8wekyb3d8bbwe_4bc27046-84c5-8679-dcc7-d44c77a47dd0.xml"`
1. After Quick Assist is installed, run this command to confirm that Quick Assist is installed for the user: `Get-AppxPackage *QuickAssist* -AllUsers`
1. After Quick Assist is installed, run this command to confirm that Quick Assist is installed for the user: `Get-AppxPackage *QuickAssist* -AllUsers` -->
### Microsoft Edge WebView2

197
windows/client-management/declared-configuration-discovery.md Normal file
View File

@ -0,0 +1,197 @@
---
title: Windows declared configuration discovery
description: Learn more about configuring discovery for Windows declared configuration enrollment.
ms.date: 09/12/2024
ms.topic: how-to
---
# Declared configuration discovery
Windows Declared configuration (WinDC) discovery uses a dedicated JSON schema to query enrollment details from the [discovery service endpoint (DS)](/openspecs/windows_protocols/ms-mde2/60deaa44-52df-4a47-a844-f5b42037f7d3#gt_8d76dac8-122a-452b-8c97-b25af916f19b). This process involves sending HTTP requests with specific headers and a JSON body containing details such as user domain, tenant ID, and OS version. The DS responds with the necessary enrollment service URLs and authentication policies based on the enrollment type (Microsoft Entra joined or registered devices).
This article outlines the schema structure for the HTTP request and response bodies, and provides examples to guide the implementation.
## Schema structure
### HTTP request headers
| Header | Required | Description |
|----------------------------------|----------|-----------------------------------|
| `MS-CV: %s` | No | Correlation vector for enrollment |
| `client-request-id: %s` | No | Request ID |
| `Content-Type: application/json` | Yes | HTTP Content-Type |
### HTTP request body (JSON)
| Field | Required | Description |
|--|--|--|
| `userDomain` | No | Domain name of the enrolled account |
| `upn` | No | User Principal Name (UPN) of the enrolled account |
| `tenantId` | No | Tenant ID of the enrolled account |
| `emmDeviceId` | No | Enterprise mobility management (EMM) device ID of the enrolled account |
| `enrollmentType` | Entra joined: No <br>Entra registered: Yes | Enrollment type of the enrolled account. <br><br>Supported Values: <br>- `Device`: Indicates the parent enrollment type is Entra joined (DS response should specify "AuthPolicy": "Federated"). <br>- `User`: Indicates parent enrollment type is Entra registered (DS response should specify "AuthPolicy": "Certificate"). <br>- Legacy case (Entra joined only): If the `enrollmentType` parameter isn't included in the request body, the device should be treated as Entra joined. |
| `osVersion` | Yes | OS version on the device. The DS can use the `osVersion` to determine if the client platform supports WinDC enrollment. Review [supported platforms](declared-configuration.md#supported-platforms) for details. |
### HTTP DS response body (JSON)
| Field | Required | Description |
|------------------------------|----------|--------------------------------------------------------------------------------------------------------------------------------------------|
| `EnrollmentServiceUrl` | Yes | URL of the WinDC enrollment service |
| `EnrollmentVersion` | No | Enrollment version |
| `EnrollmentPolicyServiceUrl` | Yes | Enrollment Policy Service URL |
| `AuthenticationServiceUrl` | Yes | Authentication Service URL |
| `ManagementResource` | No | Management Resource |
| `TouUrl` | No | Terms of use URL |
| `AuthPolicy` | Yes | Authentication policy. Supported values: <br>- `Federated` (required for Entra joined) <br>- `Certificate` (required for Entra registered) |
| `errorCode` | No | Error code |
| `message` | No | Status message |
## Examples
### Discovery request
**Headers**
`Content-Type: application/json`
**Body**
1. Single template approach: Client sends the **UPN** value in the initial request, along with the **tenantId** parameter.
1. Microsoft Entra joined:
```json
{
"userDomain" : "contoso.com",
"upn" : "johndoe@contoso.com",
"tenantId" : "00000000-0000-0000-0000-000000000000",
"emmDeviceId" : "00000000-0000-0000-0000-000000000000",
"enrollmentType" : "Device",
"osVersion" : "10.0.00000.0"
}
```
1. Microsoft Entra registered:
```json
{
"userDomain" : "contoso.com",
"upn" : "johndoe@contoso.com",
"tenantId" : "00000000-0000-0000-0000-000000000000",
"emmDeviceId" : "00000000-0000-0000-0000-000000000000",
"enrollmentType" : "Device",
"osVersion" : "10.0.00000.0"
}
```
1. No UPN (legacy)
1. Microsoft Entra joined:
```json
{
"userDomain" : "contoso.com",
"emmDeviceId" : "00000000-0000-0000-0000-000000000000",
"enrollmentType" : "Device",
"osVersion" : "10.0.00000.0"
}
```
1. Microsoft Entra registered:
```json
{
"userDomain" : "contoso.com",
"emmDeviceId" : "00000000-0000-0000-0000-000000000000",
"enrollmentType" : "User",
"osVersion" : "10.0.00000.0"
}
```
1. UPN requested by the server (legacy format). Review [error handling](#error-handling) for details on how the server can request UPN data if it isn't provided in the initial request.
1. Microsoft Entra joined:
```json
{
"upn" : "johndoe@contoso.com",
"emmDeviceId" : "00000000-0000-0000-0000-000000000000",
"enrollmentType" : "Device",
"osVersion" : "10.0.00000.0"
}
```
1. Microsoft Entra registered:
```json
{
"upn" : "johndoe@contoso.com",
"emmDeviceId" : "00000000-0000-0000-0000-000000000000",
"enrollmentType" : "User",
"osVersion" : "10.0.00000.0"
}
```
### Discovery response
**Headers**
`Content-Type: application/json`
**Body**
1. Microsoft Entra joined (requires `"AuthPolicy": "Federated"`):
```json
{
"EnrollmentServiceUrl" : "https://manage.contoso.com/Enrollment/Discovery",
"EnrollmentPolicyServiceUrl" : "https://manage.contoso.com/Enrollment/GetPolicies",
"AuthenticationServiceUrl" : "https://manage.contoso.com/Enrollment/AuthService",
"AuthPolicy" : "Federated",
"ManagementResource":"https://manage.contoso.com",
"TouUrl" : "https://manage.contoso.com/Enrollment/tou.aspx"
}
```
1. Microsoft Entra registered (requires `"AuthPolicy": "Certificate"`):
```json
{
"EnrollmentServiceUrl" : "https://manage.contoso.com/Enrollment/Discovery",
"EnrollmentPolicyServiceUrl" : "https://manage.contoso.com/Enrollment/GetPolicies",
"AuthenticationServiceUrl" : "https://manage.contoso.com/Enrollment/AuthService",
"AuthPolicy" : "Certificate",
"ManagementResource":"https://manage.contoso.com",
"TouUrl" : "https://manage.contoso.com/Enrollment/tou.aspx"
}
```
### Authentication
WinDC enrollment requires different authentication mechanisms for Microsoft Entra joined and registered devices. The WinDC DS must integrate with the authentication model by specifying the appropriate `AuthPolicy` value in the discovery response, based on the `enrollmentType` property of the request.
- **Microsoft Entra joined devices** use **Federated** authentication (Entra device token).
- **Microsoft Entra registered devices** use **Certificate** authentication (MDM certificate provisioned for the parent enrollment).
#### Rules
- **For Microsoft Entra joined devices**:
- **Discovery request**: `"enrollmentType": "Device"`
- **Discovery response**: `"AuthPolicy": "Federated"`
- **Authentication**: The client uses the Entra device token to authenticate with the WinDC enrollment server.
- **For legacy cases (where `enrollmentType` value is empty)**:
- **Discovery request**: `"enrollmentType": ""`
- **Discovery response**: `"AuthPolicy": "Federated"`
- **Authentication**: The client uses the Entra device token to authenticate with the WinDC enrollment server.
- **For Microsoft Entra registered devices**:
- **Discovery request**: `"enrollmentType": "User"`
- **Discovery response**: `"AuthPolicy": "Certificate"`
- **Authentication**: The client uses the MDM certificate from the parent enrollment to authenticate with the WinDC enrollment server.
## Error handling
- **UPNRequired**: If no UPN value is provided in the discovery request, the DS can set the `errorCode` to **UPNRequired** in the response to trigger the client to retry the request with a UPN value, if available.
- **WINHTTP_QUERY_RETRY_AFTER**: The server can set this flag to configure the client request to retry after a specified delay. This flag is useful for handling timeout or throttling scenarios.

51
windows/client-management/declared-configuration-enrollment.md Normal file
View File

@ -0,0 +1,51 @@
---
title: Windows declared configuration enrollment
description: Learn more about configuring enrollment for Windows declared configuration protocol.
ms.date: 09/12/2024
ms.topic: how-to
---
# Declared configuration enrollment
Windows declared configuration (WinDC) enrollment uses new [DMClient CSP](mdm/dmclient-csp.md) policies to facilitate dual enrollment for Windows devices. This process involves setting specific configuration service provider (CSP) policies and executing SyncML commands to manage the enrollment state.
The key CSP policies used for WinDC enrollment include:
- [LinkedEnrollment/Enroll](mdm/dmclient-csp.md#deviceproviderprovideridlinkedenrollmentenroll)
- [LinkedEnrollment/Unenroll](mdm/dmclient-csp.md#deviceproviderprovideridlinkedenrollmentunenroll)
- [LinkedEnrollment/EnrollStatus](mdm/dmclient-csp.md#deviceproviderprovideridlinkedenrollmentenrollstatus)
- [LinkedEnrollment/LastError](mdm/dmclient-csp.md#deviceproviderprovideridlinkedenrollmentlasterror)
- [LinkedEnrollment/DiscoveryEndpoint](mdm/dmclient-csp.md#deviceproviderprovideridlinkedenrollmentdiscoveryendpoint)
The following SyncML example sets **LinkedEnrolment/DiscoveryEndpoint** and triggers **LinkedEnrollment/Enroll**:
```xml
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/DMClient/Provider/MS%20DM%20SERVER/LinkedEnrollment/DiscoveryEndpoint</LocURI>
</Target>
<Data>https://discovery.dm.microsoft.com/EnrollmentConfiguration?api-version=1.0</Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Exec>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/DMClient/Provider/MS%20DM%20SERVER/LinkedEnrollment/Enroll</LocURI>
</Target>
</Item>
</Exec>
<Final/>
</SyncBody>
</SyncML>
```

191
windows/client-management/declared-configuration-extensibility.md
View File

@ -1,13 +1,13 @@
---
title: Declared configuration extensibility
description: Learn more about declared configuration extensibility through native WMI providers.
ms.date: 07/08/2024
title: Windows declared configuration extensibility
description: Learn more about Windows declared configuration extensibility through native WMI providers.
ms.date: 09/12/2024
ms.topic: how-to
---
# Declared configuration extensibility providers
# Declared configuration extensibility
The declared configuration enrollment, which supports the declared configuration client stack, offers extensibility through native WMI providers. This feature instantiates and interfaces with a Windows Management Instrumentation (WMI) provider that implements a management infrastructure (MI) interface. The interface must implement GetTargetResource, TestTargetResource, and SetTargetResource methods, and can implement any number of string properties.
The Windows declared configuration (WinDC) enrollment offers extensibility through native WMI providers. This feature instantiates and interfaces with a Windows Management Instrumentation (WMI) provider that implements a management infrastructure (MI) interface. The interface must implement GetTargetResource, TestTargetResource, and SetTargetResource methods, and can implement any number of string properties.
> [!NOTE]
> Only string properties are currently supported by extensibility providers.
@ -58,7 +58,7 @@ To create a native WMI provider, follow the steps outlined in [How to implement
5. Copy the generated files into the provider's project folder.
6. Start the development process.
## Example
## Example MI provider
This example provides more details about each step to demonstrate how to implement a sample native resource named `MSFT_FileDirectoryConfiguration`.
@ -235,15 +235,180 @@ The `MSFT_FileDirectoryConfiguration_Invoke_GetTargetResource` function does the
1. Clean up resources, for example, free allocated memory.
## WinDC document
> [!IMPORTANT]
> The target of the scenario settings can only be device wide for extensibility. The CSP **scope** defined in `<LocURI>` and WinDC **context** must be `Device`.
The value of the `Document` leaf node in the [DeclaredConfiguration CSP](mdm/declaredconfiguration-csp.md) is an XML document that describes the request. Here's a sample WinDC document with the configuration data specified for extensibility.
```xml
<DeclaredConfiguration schema="1.0" context="Device" id="27FEA311-68B9-4320-9FC4-296F6FDFAFE2" checksum="99925209110918B67FE962460137AA3440AFF4DB6ABBE15C8F499682457B9999" osdefinedscenario="MSFTExtensibilityMIProviderConfig">
<DSC namespace="root/Microsoft/Windows/DesiredStateConfiguration" className="MSFT_FileDirectoryConfiguration">
<Key name="DestinationPath">c:\data\test\bin\ut_extensibility.tmp</Key>
<Value name="Contents">TestFileContent1</Value>
</DSC>
</DeclaredConfiguration>
```
Only supported values for `osdefinedscenario` can be used. Unsupported values result in an error message similar to `Invalid scenario name`.
| osdefinedscenario | Description |
|--------------------------------------|----------------------------------------------|
| MSFTExtensibilityMIProviderConfig | Used to configure MI provider settings. |
| MSFTExtensibilityMIProviderInventory | Used to retrieve MI provider setting values. |
Both `MSFTExtensibilityMIProviderConfig` and `MSFTExtensibilityMIProviderInventory` scenarios that require the same tags and attributes.
- The `<DSC>` XML tag describes the targeted WMI provider expressed by a namespace and class name along with the values either to be applied to the device or queried by the MI provider.
This tag has the following attributes:
| Attribute | Description |
|--|--|
| `namespace` | Specifies the targeted MI provider namespace. |
| `classname` | The targeted MI provider. |
- The `<Key>` XML tag describes the required parameter name and value. It only needs a value for configuration. The name is an attribute and the value is `<Key>` content.
This tag has the following attributes:
| Attribute | Description |
|--|--|
| `name` | Specifies the name of an MI provider parameter. |
- The `<Value>` XML tag describes the optional parameter name and value. It only needs a value for configuration. The name is an attribute and the value is `<Value>` content.
This tag has the following attributes:
| Attribute | Description |
|--|--|
| `name` | Specifies the name of an MI provider parameter. |
## SyncML examples
The standard OMA-DM SyncML syntax is used to specify the DeclaredConfiguration CSP operations such as **Replace**, **Add**, and **Delete**. The payload of the SyncML's `<Data>` element must be XML-encoded. For this XML encoding, there are various online encoders that you can use. To avoid encoding the payload, you can use [CDATA Section](https://www.w3.org/TR/REC-xml/#sec-cdata-sect) as shown in the following SyncML examples.
### Configuration request
This example demonstrates how to send a configuration request using the `MSFT_FileDirectoryConfiguration` MI provider with the `MSFTExtensibilityMIProviderConfig` scenario.
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Replace>
<CmdID>14</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Documents/27FEA311-68B9-4320-9FC4-296F6FDFAFE2/Document</LocURI>
</Target>
<Data><![CDATA[
<DeclaredConfiguration schema="1.0" context="Device" id="27FEA311-68B9-4320-9FC4-296F6FDFAFE2" checksum="99925209110918B67FE962460137AA3440AFF4DB6ABBE15C8F499682457B9999" osdefinedscenario="MSFTExtensibilityMIProviderConfig">
<DSC namespace="root/Microsoft/Windows/DesiredStateConfiguration" className="MSFT_FileDirectoryConfiguration">
<Key name="DestinationPath">c:\data\test\bin\ut_extensibility.tmp</Key>
<Value name="Contents">TestFileContent1</Value>
</DSC>
</DeclaredConfiguration>
]]></Data>
</Item>
</Replace>
</SyncBody>
</SyncML>
```
### Inventory request
This example demonstrates how to send an inventory request using the MSFT_FileDirectoryConfiguration MI provider with the MSFTExtensibilityMIProviderInventory scenario.
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Replace>
<CmdID>15</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/Inventory/Documents/12345678-1234-1234-1234-123456789012/Document</LocURI>
</Target>
<Data><![CDATA[
<DeclaredConfiguration schema="1.0" context="Device" id="12345678-1234-1234-1234-123456789012" checksum="1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF1234567890ABCDEF" osdefinedscenario="MSFTExtensibilityMIProviderInventory">
<DSC namespace="root/Microsoft/Windows/DesiredStateConfiguration" className="MSFT_FileDirectoryConfiguration">
<Key name="DestinationPath">c:\data\test\bin\ut_extensibility.tmp</Key>
</DSC>
</DeclaredConfiguration>
]]></Data>
</Item>
</Replace>
</SyncBody>
</SyncML>
```
### Retrieve results
This example retrieves the results of a configuration or inventory request:
**Request**:
```xml
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Get>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Results/27FEA311-68B9-4320-9FC4-296F6FDFAFE2/Document</LocURI>
</Target>
</Item>
</Get>
<Final />
</SyncBody>
</SyncML>
```
**Response**:
```xml
<Status>
<CmdID>2</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>2</CmdRef>
<Cmd>Get</Cmd>
<Data>200</Data>
</Status>
<Results>
<CmdID>3</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>2</CmdRef>
<Item>
<Source>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Results/27FEA311-68B9-4320-9FC4-296F6FDFAFE2/Document</LocURI>
</Source>
<Data>
<DeclaredConfigurationResult context="Device" schema="1.0" id="99988660-9080-3433-96e8-f32e85011999" osdefinedscenario="MSFTPolicies" checksum="99925209110918B67FE962460137AA3440AFF4DB6ABBE15C8F499682457B9999" result_checksum="EE4F1636201B0D39F71654427E420E625B9459EED17ACCEEE1AC9B358F4283FD" operation="Set" state="60">
<DSC namespace="root/Microsoft/Windows/DesiredStateConfiguration" className="MSFT_FileDirectoryConfiguration" status="200" state="60">
<Key name="DestinationPath" />
<Value name="Contents" />
</DSC>
</DeclaredConfigurationResult>
</Data>
</Item>
</Results>
```
## MI implementation references
- [Introducing the management infrastructure (MI) API](/archive/blogs/wmi/introducing-new-management-infrastructure-mi-api)
- [Implementing MI provider (1) - Overview](/archive/blogs/wmi/implementing-mi-provider-1-overview)
- [Implementing MI provider (2) - Define schema](/archive/blogs/wmi/implementing-mi-provider-2-define-schema)
- [Implementing MI provider (3) - Generate code](/archive/blogs/wmi/implementing-mi-provider-3-generate-code)
- [Implementing MI provider (4) - Generate code (continue)](/archive/blogs/wmi/implementing-mi-provider-4-generate-code-continute)
- [Implementing MI provider (5) - Implement](/archive/blogs/wmi/implementing-mi-provider-5-implement)
- [Implementing MI provider (6) - Build, register, and debug](/archive/blogs/wmi/implementing-mi-provider-6-build-register-and-debug)
- [Management infrastructure (MI) API](/archive/blogs/wmi/introducing-new-management-infrastructure-mi-api)
- [MI provider (1) - Overview](/archive/blogs/wmi/implementing-mi-provider-1-overview)
- [MI provider (2) - Define schema](/archive/blogs/wmi/implementing-mi-provider-2-define-schema)
- [MI provider (3) - Generate code](/archive/blogs/wmi/implementing-mi-provider-3-generate-code)
- [MI provider (4) - Generate code (continue)](/archive/blogs/wmi/implementing-mi-provider-4-generate-code-continute)
- [MI provider (5) - Implement](/archive/blogs/wmi/implementing-mi-provider-5-implement)
- [MI provider (6) - Build, register, and debug](/archive/blogs/wmi/implementing-mi-provider-6-build-register-and-debug)
- [MI interfaces](/previous-versions/windows/desktop/wmi_v2/mi-interfaces)
- [MI datatypes](/previous-versions/windows/desktop/wmi_v2/mi-datatypes)
- [MI structures and unions](/previous-versions/windows/desktop/wmi_v2/mi-structures-and-unions)

463
windows/client-management/declared-configuration-resource-access.md Normal file
View File

@ -0,0 +1,463 @@
---
title: Windows declared configuration resource access
description: Learn more about configuring resource access using Windows declared Configuration.
ms.date: 09/12/2024
ms.topic: how-to
---
# Declared configuration resource access
Windows declared configuration (WinDC) resource access is used to manage device configurations and enforce policies to ensure the devices remain in a desired state. It's crucial for maintaining security, compliance, and operational efficiency in organizations. WinDC cloud service is used to send the desired state of a resource to the device where correspondingly the device has the responsibility to enforce and maintain the resource configuration state.
[Configuration Service Providers (CSPs)](mdm/index.yml) play a vital role for configuring Resource access and act as an interface between the device and the WinDC protocol. They provide a consistent and standardized approach to deploying and enforcing configurations. CSPs support various resource access scenarios, including:
- [VPNv2 CSP](mdm/vpnv2-csp.md) and [VPN CSP](mdm/vpn-csp.md)
- [Wi-Fi CSP](mdm/wifi-csp.md)
- [ClientCertificateInstall CSP](mdm/clientcertificateinstall-csp.md)
- [ActiveSync CSP](mdm/activesync-csp.md)
- [WiredNetwork CSP](mdm/wirednetwork-csp.md)
- [RootCACertificates CSP](mdm/rootcacertificates-csp.md)
The WinDC stack on the device processes configuration requests and maintains the desired state, which is key to RA. The efficiency, accuracy, and enforcement of configuration requests are critical for effective RA. Resource access integrates seamlessly with WinDC, providing an extended method for managing devices through the cloud with enhanced scalability and efficiency.
- **Efficiency**: Batch-based processing minimizes server resource usage and reduces latency.
- **Accuracy**: WinDC client stack understands the device's configuration surface area, enabling effective handling of continuous updates. It ensures precise execution of configuration changes communicated by the cloud service.
- **Policy Enforcement**: Apply and maintain organizational policies across devices consistently and at scale, ensuring compliance and uniform configuration. This aspect allows organizations to maintain the desired security posture across devices.
## Resource access guidelines
These guidelines provide best practices and examples for developers and testers to implement resource access (RA) configurations in a secure, efficient, and consistent manner. They aim to enhance network security and optimize resource access for end users while adhering to policies and compliance requirements.
- **Configuration Integrity**: To support uninterrupted and secure resource access, ensure consistent configurations across devices and users.
- **State Validation**: Monitor the state of configurations to verify the correct application of resource access settings.
- **Profile Management**: Effectively manage user profiles by adding, updating, and deleting as needed, to control access to resources and maintain security.
- **Log and Audit**: Utilize logs and audit trails for operations and changes to aid in troubleshooting and compliance.
- **Drift Detection and Remediation**: To maintain compliance with RA policies, continuously monitor drift (changes in configuration or behavior) and take corrective action.
- **Security and Privacy**: To protect user data and resources, implement strong security and privacy measures in configurations.
By following these guidelines and understanding the syntax of the [DeclaredConfiguration CSP](mdm/declaredconfiguration-csp.md), you can effectively implement and manage RA configurations while maintaining security and compliance.
## WinDC document
The value of the `Document` leaf node in the [DeclaredConfiguration CSP](mdm/declaredconfiguration-csp.md) is an XML document that describes the request. Here's a sample WinDC document with the configuration data specified for resource access.
```xml
<DeclaredConfiguration context="user" schema="1.0" id="DCA000B5-397D-40A1-AABF-40B25078A7F9" osdefinedscenario="MSFTVPN" checksum="A0">
<CSP name="./Vendor/MSFT/VPNv2">
<URI path="Test_SonicWall/TrafficFilterList/0/Protocol" type="int">2</URI>
<URI path="Test_SonicWall/TrafficFilterList/0/Direction" type="chr">outbound</URI>
</CSP>
</DeclaredConfiguration>
```
Only supported values for `osdefinedscenario` can be used. Unsupported values result in an error message similar to `Invalid scenario name`.
| osdefinedscenario | Recommended using with |
|------------------------------|-------------------------------|
| MSFTWiredNetwork | WiredNetwork |
| MSFTResource | ActiveSync |
| MSFTVPN | VPN and VPNv2 |
| MSFTWifi | Wifi |
| MSFTInventory | Certificate inventory |
| MSFTClientCertificateInstall | SCEP, PFX, Bulk Template Data |
These `osdefinedscenario` values require the following tags and attributes.
- The `<CSP>` XML tag describes the CSP being targeted.
This tag has the following attributes:
| Attribute | Description |
|--|--|
| `name` | Specifies the targeted CSP OMA-URI. |
- The `<URI>` XML tag specifies the CSP setting node along with the desired value.
This tag has the following attributes:
| Attribute | Description |
|-----------|-------------------|
| `path` | Setting path |
| `type` | Setting data type |
> [!NOTE]
> The target of the scenario settings must match the WinDC context. The CSP **scope** defined in `<LocURI>` and WinDC **context** must both be either `Device` or `User`.
>
> :::image type="content" source="images/declared-configuration-ra-syntax.png" alt-text="WinDC resource access syntax":::
### osdefinedscenario examples
- Partial `MSFTWifi` example for Wifi:
```xml
<DeclaredConfiguration context="Device" schema="1.0" id="10249228-e719-58bf-b459-060de45240f1" osdefinedscenario="MSFTWifi" checksum="11111111">
<CSP name="./Vendor/MSFT/WiFi">
```
- Partial `MSFTResource` example for ActiveSync:
```xml
<DeclaredConfiguration context="User" schema="1.0" id="33333333-1861-4131-96e8-44444444" osdefinedscenario="MSFTResource" checksum="5555">
<CSP name="./Vendor/MSFT/ActiveSync">
```
## SyncML examples
The standard OMA-DM SyncML syntax is used to specify the DeclaredConfiguration CSP operations such as **Replace**, **Add**, and **Delete**. The payload of the SyncML's `<Data>` element must be XML-encoded. For this XML encoding, there are various online encoders that you can use. To avoid encoding the payload, you can use [CDATA Section](https://www.w3.org/TR/REC-xml/#sec-cdata-sect) as shown in the following SyncML examples.
### Configure a VPNv2 profile for resource access
This example demonstrates how to use the [VPNv2 CSP](mdm/vpnv2-csp.md) to configure a VPN profile named **Test_SonicWall** on the device in the **User** scope.
```xml
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./User/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Documents/DCA000B5-397D-40A1-AABF-40B25078A7F9/Document</LocURI>
</Target>
<Data><![CDATA[<?xml version="1.0" encoding="utf-8"?>
<DeclaredConfiguration context="user" schema="1.0" id="DCA000B5-397D-40A1-AABF-40B25078A7F9" osdefinedscenario="MSFTVPN" checksum="A0">
<CSP name="./Vendor/MSFT/VPNv2">
<URI path="Test_SonicWall/TrafficFilterList/0/Protocol" type="int">2</URI>
<URI path="Test_SonicWall/TrafficFilterList/0/Direction" type="chr">outbound</URI>
<URI path="Test_SonicWall/TrafficFilterList/1/Protocol" type="int">6</URI>
<URI path="Test_SonicWall/TrafficFilterList/1/LocalPortRanges" type="chr">43-54</URI>
<URI path="Test_SonicWall/TrafficFilterList/1/RemotePortRanges" type="chr">243-456</URI>
<URI path="Test_SonicWall/TrafficFilterList/1/Direction" type="chr">outbound</URI>
<URI path="Test_SonicWall/EdpModeId" type="chr">wip.contoso.com</URI>
<URI path="Test_SonicWall/RememberCredentials" type="bool">true</URI>
<URI path="Test_SonicWall/AlwaysOn" type="bool">true</URI>
<URI path="Test_SonicWall/Proxy/AutoConfigUrl" type="chr">https://auto.proxy.com</URI>
<URI path="Test_SonicWall/DeviceCompliance/Enabled" type="bool">true</URI>
<URI path="Test_SonicWall/DeviceCompliance/Sso/Enabled" type="bool">false</URI>
<URI path="Test_SonicWall/PluginProfile/ServerUrlList" type="chr">23.54.3.6;server1,vpn.contoso.com;server2</URI>
<URI path="Test_SonicWall/PluginProfile/CustomConfiguration" type="chr">&lt;custom&gt;&lt;/custom&gt;</URI>
<URI path="Test_SonicWall/PluginProfile/PluginPackageFamilyName" type="chr">SonicWALL.MobileConnect_e5kpm93dbe93j</URI>
</CSP>
</DeclaredConfiguration>
]]></Data>
</Item>
</Replace>
<Final />
</SyncBody>
</SyncML>
```
<!--
> [!NOTE]
>
> - Format of the `<LocURI>` and `<DeclaredConfiguration>` follow the [DeclaredConfiguration CSP](mdm/declaredconfiguration-csp.md) syntax.
> - The `id` of `<DeclaredConfiguration>` should be a unique string.
> - `<Format>` of `<Meta>` should be `chr` and `<Type>` should be `text/plain`.
-->
### Updating a VPNv2 profile for resource access
This example demonstrates how to use the same WinDC **Document ID**, but with a new checksum("A3"). It installs a new VPNv2 profile named `Test_SonicwallNew`, and deletes the old profile.
```xml
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./User/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Documents/DCA000B5-397D-40A1-AABF-40B25078A7F9/Document</LocURI>
</Target>
<Data><![CDATA[<?xml version="1.0" encoding="utf-8"?>
<DeclaredConfiguration context="user" schema="1.0" id="DCA000B5-397D-40A1-AABF-40B25078A7F9" osdefinedscenario="MSFTVPN" checksum="A3">
<CSP name="./Vendor/MSFT/VPNv2">
<URI path="Test_SonicWallNew/TrafficFilterList/0/Protocol" type="int">2</URI>
<URI path="Test_SonicWallNew/TrafficFilterList/0/Direction" type="chr">outbound</URI>
<URI path="Test_SonicWallNew/EdpModeId" type="chr">wip.contoso.com</URI>
<URI path="Test_SonicWallNew/RememberCredentials" type="bool">true</URI>
<URI path="Test_SonicWallNew/AlwaysOn" type="bool">false</URI>
<URI path="Test_SonicWallNew/Proxy/AutoConfigUrl" type="chr">https://auto.proxy.com</URI>
<URI path="Test_SonicWallNew/DeviceCompliance/Enabled" type="bool">true</URI>
<URI path="Test_SonicWallNew/DeviceCompliance/Sso/Enabled" type="bool">false</URI>
<URI path="Test_SonicWallNew/PluginProfile/ServerUrlList" type="chr">23.54.3.8;server1,vpn2.contoso.com;server2</URI>
<URI path="Test_SonicWallNew/PluginProfile/PluginPackageFamilyName" type="chr">SonicWALL.MobileConnect_e5kpm93dbe93j</URI>
</CSP>
</DeclaredConfiguration>
]]></Data>
</Item>
</Replace>
<Final />
</SyncBody>
</SyncML>
```
### Getting the VPNv2 profile
This example demonstrates how to use `<Get>` to retrieve the results of the WinDC request.
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Get>
<CmdID>1</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./User/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Results/DCA000B5-397D-40A1-AABF-40B25078A7F9/Document</LocURI>
</Target>
</Item>
</Get>
<Final />
</SyncBody>
</SyncML>
```
**Response**:
```xml
<SyncML xmlns:msft="http://schemas.microsoft.com/MobileDevice/MDM">
<SyncHdr />
<SyncBody>
<Status>
<CmdID>1</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>0</CmdRef>
<Cmd>SyncHdr</Cmd>
<Data>200</Data>
</Status>
<Status>
<CmdID>2</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>2</CmdRef>
<Cmd>Get</Cmd>
<Data>200</Data>
</Status>
<Results>
<CmdID>3</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>2</CmdRef>
<Item>
<Source>
<LocURI>./User/Vendor/MSFT/DeclaredConfiguration/Host/BulkTemplate/Results/DCA000B5-397D-40A1-AABF-40B25078A7F9/Document</LocURI>
</Source>
<Data>&lt;DeclaredConfigurationResult context="user" schema="1.0" id="DCA000B5-397D-40A1-AABF-40B25078A7F9" osdefinedscenario="MSFTVPN" checksum="A3" result_checksum="9D2ED497C12D2FCEE1C45158D1F7ED8E2DACE210A0B8197A305417882991C978" result_timestamp="2024-08-06T13:54:38Z" operation="Set" state="60"&gt;&lt;CSP name="./Vendor/MSFT/VPNv2" state="60"&gt;&lt;URI path="Test_SonicWallNew/TrafficFilterList/0/Protocol" status="200" state="60" type="int" /&gt;&lt;URI path="Test_SonicWallNew/TrafficFilterList/0/Direction" status="200" state="60" type="chr" /&gt;&lt;URI path="Test_SonicWallNew/EdpModeId" status="200" state="60" type="chr" /&gt;&lt;URI path="Test_SonicWallNew/RememberCredentials" status="200" state="60" type="bool" /&gt;&lt;URI path="Test_SonicWallNew/AlwaysOn" status="200" state="60" type="bool" /&gt;&lt;URI path="Test_SonicWallNew/Proxy/AutoConfigUrl" status="200" state="60" type="chr" /&gt;&lt;URI path="Test_SonicWallNew/DeviceCompliance/Enabled" status="200" state="60" type="bool" /&gt;&lt;URI path="Test_SonicWallNew/DeviceCompliance/Sso/Enabled" status="200" state="60" type="bool" /&gt;&lt;URI path="Test_SonicWallNew/PluginProfile/ServerUrlList" status="200" state="60" type="chr" /&gt;&lt;URI path="Test_SonicWallNew/PluginProfile/PluginPackageFamilyName" status="200" state="60" type="chr" /&gt;&lt;/CSP&gt;&lt;/DeclaredConfigurationResult&gt;</Data>
</Item>
</Results>
<Final />
</SyncBody>
</SyncML>
```
> [!TIP]
> To understand the state values, see [WinDC states](mdm/declaredconfiguration-csp.md#windc-states).
### Deleting the VPNv2 profile
This example demonstrates how to use `<Delete>` to remove the configuration request to set the VPNv2 profile.
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Delete>
<CmdID>1</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./User/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Documents/DCA000B5-397D-40A1-AABF-40B25078A7F9/Document</LocURI>
</Target>
</Item>
</Delete>
<Final />
</SyncBody>
</SyncML>
```
## Resource ownership
MDM-managed resources, such as a VPN profile, are transferred/migrated to WinDC management when a WinDC document is sent to the device for the same resource. This resource stays under WinDC management until the WinDC document is [deleted](mdm/declaredconfiguration-csp.md#delete-a-windc-document) or [abandoned](mdm/declaredconfiguration-csp.md#abandon-a-windc-document). Otherwise, when MDM tries to manage the same resource via the legacy MDM channel using SyncML, it fails with error 0x86000031.
`MDM ConfigurationManager: Command failure status. Configuraton Source ID: (29c383c5-6e2d-43bf-a741-c63cb7516bb4), Enrollment Type: (MDMDeviceWithAAD), CSP Name: (ActiveSync), Command Type: (Add: from Replace or Add), CSP URI: (./User/Vendor/MSFT/ActiveSync/Accounts/{3b8b9d4d-a24e-4c6d-a460-034d0bfb9316}), Result: (Unknown Win32 Error code: 0x86000031).`
## Bulk template data
The Bulk template data scenario extends beyond the regular [ClientCertificateInstall CSP](mdm/clientcertificateinstall-csp.md). It uses a special bulk template document type. This section covers the structure, specification, and results of using the bulk template data.
### Template document
A PFXImport template document contains the structure necessary for importing certificates in bulk. The document should define the necessary fields, and the format required for the bulk import.
- The document type must be `BulkTemplate`.
- The URI path is different than the regular URIs by using the `@#pfxThumbprint#` syntax, it declares that it's a dynamic node. [Instance data](#template-data) for dynamic nodes is sent later using `BulkVariables`. Each dynamic node might contain dynamic subnodes, such as the `@#pfxBlob#` and `#@pfxPassword#` nodes in this example.
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/BulkTemplate/Documents/47e88660-1861-4131-96e8-f32e85011e55/Document</LocURI>
</Target>
<Data><![CDATA[<?xml version="1.0" encoding="utf-8"?>
<DeclaredConfiguration context="Device" schema="1.0" id="47e88660-1861-4131-96e8-f32e85011e55" osdefinedscenario="MSFTResource" checksum="FF356C2C71F6A41F9AB4A601AD00C8B5BC7531576233010B13A221A9FE1BE7A0">
<ReflectedProperties>
<Property name="foo" type="chr">foovalue</Property>
<Property name="bar" type="chr">barvalue</Property>
</ReflectedProperties>
<CSP name="./Vendor/MSFT/ClientCertificateInstall">
<URI path="PFXCertInstall/@#pfxThumbprint#/KeyLocation" type="Int">2</URI>
<URI path="PFXCertInstall/@#pfxThumbprint#/PFXCertBlob" type="chr">@#pfxBlob#</URI>
<URI path="PFXCertInstall/@#pfxThumbprint#/PFXCertPassword" type="chr">@#pfxPassword#</URI>
<URI path="PFXCertInstall/@#pfxThumbprint#/PFXKeyExportable" type="bool">True</URI>
<URI path="PFXCertInstall/@#pfxThumbprint#/PfxCertPasswordEncryptionType" type="int">0</URI>
<URI path="PFXCertInstall/@#pfxThumbprint#/PfxCertPasswordEncryptionStore" type="chr">SomeValue</URI>
<URI path="PFXCertInstall/@#pfxThumbprint#/ContainerName" type="chr"></URI>
</CSP>
</DeclaredConfiguration>
]]></Data>
</Item>
</Replace>
<Final />
</SyncBody>
</SyncML>
```
### Template data
The bulk template data specifies the certificates to be imported in a base64 encoded format using the `BulkVariables` URI under the `BulkTemplate`. The template data document can contain multiple instances. Each instance must specify all the subinstance data.
In this example, there are two instances. Each instance defines values for **pfxThumbprint**, a **pfxBlob, and a **pfxPassword**.
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Replace>
<CmdID>3</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/BulkTemplate/Documents/47e88660-1861-4131-96e8-f32e85011e55/BulkVariables/Value</LocURI>
</Target>
<Data><![CDATA[
<InstanceBlob schema="1.0">
<Instance>
<InstanceData variable="pfxThumbprint">813A171D7341E1DA90D4A01878DD5328D3519006</InstanceData>
<InstanceData variable="pfxBlob">pfxbase64BlobValue1</InstanceData>
<InstanceData variable="pfxPassword">Password1</InstanceData>
</Instance>
<Instance>
<InstanceData variable="pfxThumbprint">813A171D7341E1DA90D4A01878DD5328D3519007</InstanceData>
<InstanceData variable="pfxBlob">pfxbase64BlobValue2</InstanceData>
<InstanceData variable="pfxPassword">Password2</InstanceData>
</Instance>
</InstanceBlob>
]]></Data>
</Item>
</Replace>
<Final />
</SyncBody>
</SyncML>
```
### Template results
When the bulk template data document is successfully processed, the specified certificates are imported into the defined stores with the provided passwords and key locations.
- Successful Import: The certificates are correctly imported into the device's certificate stores.
- Error Handling: Any errors encountered during the import process include relevant status codes or messages for troubleshooting.
**Request**:
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Get>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/BulkTemplate/Results/47e88660-1861-4131-96e8-f32e85011e55/Document</LocURI>
</Target>
</Item>
</Get>
<Final />
</SyncBody>
</SyncML>
```
**Response**:
```xml
<SyncML xmlns:msft="http://schemas.microsoft.com/MobileDevice/MDM">
<SyncHdr />
<SyncBody>
<Status>
<CmdID>1</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>0</CmdRef>
<Cmd>SyncHdr</Cmd>
<Data>200</Data>
</Status>
<Status>
<CmdID>2</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>2</CmdRef>
<Cmd>Get</Cmd>
<Data>200</Data>
</Status>
<Results>
<CmdID>3</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>2</CmdRef>
<Item>
<Source>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/BulkTemplate/Results/47e88660-1861-4131-96e8-f32e85011e55/Document</LocURI>
</Source>
<Data>&lt;DeclaredConfigurationResult context="Device" schema="1.0" id="47e88660-1861-4131-96e8-f32e85011e55" osdefinedscenario="MSFTResource" checksum="FF356C2C71F6A41F9AB4A601AD00C8B5BC7531576233010B13A221A9FE1BE7A0" result_checksum="DD8C1C422D50A410C2949BA5F495C2C42CC4B0C7B498D1B43318C503F6CEF491" result_timestamp="2024-08-06T13:26:23Z" operation="Set" state="60"&gt;
&lt;CSP name="./Vendor/MSFT/ClientCertificateInstall" state="60"&gt;
&lt;URI path="PFXCertInstall/813A171D7341E1DA90D4A01878DD5328D3519006/KeyLocation" status="200" state="60" type="int" /&gt;
&lt;URI path="PFXCertInstall/813A171D7341E1DA90D4A01878DD5328D3519006/PFXCertBlob" status="200" state="60" type="chr" /&gt;
&lt;URI path="PFXCertInstall/813A171D7341E1DA90D4A01878DD5328D3519006/PFXCertPassword" status="200" state="60" type="chr" /&gt;
&lt;URI path="PFXCertInstall/813A171D7341E1DA90D4A01878DD5328D3519006/PFXKeyExportable" status="200" state="60" type="bool" /&gt;
&lt;/CSP&gt;&lt;CSP name="./Vendor/MSFT/ClientCertificateInstall" state="60"&gt;
&lt;URI path="PFXCertInstall/CertPFX1/KeyLocation" status="200" state="60" type="int" /&gt;
&lt;URI path="PFXCertInstall/CertPFX1/PFXCertBlob" status="200" state="60" type="chr" /&gt;
&lt;URI path="PFXCertInstall/CertPFX1/PFXCertPassword" status="200" state="60" type="chr" /&gt;
&lt;URI path="PFXCertInstall/CertPFX1/PFXKeyExportable" status="200" state="60" type="bool" /&gt;
&lt;/CSP&gt;
&lt;/DeclaredConfigurationResult&gt;
</Data>
</Item>
</Results>
<Final />
</SyncBody>
</SyncML>
```

159
windows/client-management/declared-configuration.md
View File

@ -1,65 +1,132 @@
---
title: Declared configuration protocol
description: Learn more about using declared configuration protocol for desired state management of Windows devices.
ms.date: 07/08/2024
title: Windows declared configuration protocol
description: Learn more about using Windows declared configuration (WinDC) protocol for desired state management of Windows devices.
ms.date: 09/12/2024
ms.topic: overview
---
# What is the declared configuration protocol
# Windows declared configuration protocol overview
The declared configuration protocol is based on a desired state device configuration model, though it still uses the underlying OMA-DM Syncml protocol. Through a dedicated OMA-DM server, it provides all the settings in a single batch through this protocol. The device's declared configuration client stack can reason over the settings to achieve the desired scenario in the most efficient and reliable manner.
The Windows declared configuration (WinDC) protocol is a desired state device configuration model designed for efficient and reliable management of Windows devices. It uses the OMA-DM SyncML protocol to provide all necessary settings in a single batch through a dedicated OMA-DM server. The WinDC client stack on the device processes these settings to achieve the desired state in the most efficient and reliable manner.
The declared configuration protocol requires that a device has a separate [OMA-DM enrollment](mdm-overview.md), which is dependent on the device being enrolled with the primary OMA-DM server. The desired state model is a different model from the current model where the server is responsible for the device's desire state. This dual enrollment is only allowed if the device is already enrolled into a primary MDM server. This other enrollment separates the desired state management functionality from the primary functionality. The declared configuration enrollment's first desired state management model feature is called [extensibility](declared-configuration-extensibility.md).
WinDC protocol requires that a device has a separate [OMA-DM enrollment](mdm-overview.md), which is dependent on the device being enrolled with the primary OMA-DM server. The desired state model is a different model from the current model where the server is responsible for the device's desire state. This dual enrollment is only allowed if the device is already enrolled into a primary mobile device management (MDM) server. This other enrollment separates the desired state management functionality from the primary functionality.
:::image type="content" source="images/declared-configuration-model.png" alt-text="Diagram illustrating the declared configuration model.":::
WinDC enrollment involves two phases:
With the [Declared Configuration CSP](mdm/declaredconfiguration-csp.md), the OMA-DM server can provide the device with the complete collection of setting names and associated values based on a specified scenario. The declared configuration stack on the device is responsible for handling the configuration request, and maintaining its state including updates to the scenario.
- [Declared configuration discovery](declared-configuration-discovery.md): The initial discovery phase of the WinDC protocol uses a dedicated JSON schema to query enrollment details from the [discovery service endpoint (DS)](/openspecs/windows_protocols/ms-mde2/60deaa44-52df-4a47-a844-f5b42037f7d3#gt_8d76dac8-122a-452b-8c97-b25af916f19b). This phase involves sending HTTP requests with specific headers and a JSON body containing details such as user domain, tenant ID, and OS version. The DS responds with the necessary enrollment service URLs and authentication policies based on the enrollment type (Microsoft Entra joined or registered devices).
- [Declared configuration enrollment](declared-configuration-enrollment.md): The enrollment phase uses the [MS-MDE2 protocol](/openspecs/windows_protocols/ms-mde2/4d7eadd5-3951-4f1c-8159-c39e07cbe692) and new [DMClient CSP](mdm/dmclient-csp.md) policies for dual enrollment. This phase involves setting the `LinkedEnrollment/DiscoveryEndpoint` and triggering the `LinkedEnrollment/Enroll` using SyncML commands. The device can then manage its configuration state by interacting with the OMA-DM server through these policies.
The benefit of the declared configuration desired state model is that it's efficient and accurate, especially since it's the responsibility of the declared configuration client to configure the device. The efficiency of declared configuration is because the client can asynchronously process batches of scenario settings, which free up the server resources to do other work. Thus the declared configuration protocol has low latency. As for configuration quality and accuracy, the declared configuration client stack has detailed knowledge of the configuration surface area of the device. This behavior includes the proper handling of continuous device updates that affect the configuration scenario.
WinDC enrollment offers these desired state management features:
## Declared configuration enrollment
- [Resource access](declared-configuration-resource-access.md): Provides access to necessary resources for configuration.
- [Extensibility](declared-configuration-extensibility.md): Allows for extending the configuration capabilities as needed.
[Mobile Device Enrollment Protocol version 2](/openspecs/windows_protocols/ms-mde2/4d7eadd5-3951-4f1c-8159-c39e07cbe692) describes enrollment including discovery, which covers the primary and declared configuration enrollments. The device uses the following new [DMClient CSP](mdm/dmclient-csp.md) policies for declared configuration dual enrollment:
:::image type="content" source="images/declared-configuration-model.png" alt-text="Diagram illustrating the WinDC model.":::
- [LinkedEnrollment/Enroll](mdm/dmclient-csp.md#deviceproviderprovideridlinkedenrollmentenroll)
- [LinkedEnrollment/Unenroll](mdm/dmclient-csp.md#deviceproviderprovideridlinkedenrollmentunenroll)
- [LinkedEnrollment/EnrollStatus](mdm/dmclient-csp.md#deviceproviderprovideridlinkedenrollmentenrollstatus)
- [LinkedEnrollment/LastError](mdm/dmclient-csp.md#deviceproviderprovideridlinkedenrollmentlasterror)
- [LinkedEnrollment/DiscoveryEndpoint](mdm/dmclient-csp.md#deviceproviderprovideridlinkedenrollmentdiscoveryendpoint)
After a device is enrolled, the OMA-DM server can send a complete collection of setting names and values for a specified scenario using the [DeclaredConfiguration CSP](mdm/declaredconfiguration-csp.md). The WinDC stack on the device is responsible for handling the configuration request, and maintaining its state including updates to the scenario.
The following SyncML example sets **LinkedEnrolment/DiscoveryEndpoint** and triggers **LinkedEnrollment/Enroll**:
The benefit of the WinDC desired state model is that it's efficient and accurate, especially since it's the responsibility of the WinDC client stack to configure the device. The efficiency of WinDC is because the client can asynchronously process batches of scenario settings, which free up the server resources to do other work. Thus the WinDC protocol has low latency. As for configuration quality and accuracy, the WinDC client stack has detailed knowledge of the configuration surface area of the device. This behavior includes the proper handling of continuous device updates that affect the configuration scenario.
```xml
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
## Supported platforms
WinDC enrollment for [Microsoft Entra joined devices](/entra/identity/devices/concept-directory-join) is supported for all versions of Windows 10/11.
WinDC enrollment for [Microsoft Entra registered devices](/entra/identity/devices/concept-device-registration) is supported for Windows 10/11 with the following updates:
- Windows 11, version 24H2 with [KB5040529](https://support.microsoft.com/help/5040529) (OS Build 26100.1301)
- Windows 11, version 23H2 with [KB5040527](https://support.microsoft.com/help/5040527) (OS Build 22631.3958)
- Windows 11, version 22H2 with [KB5040527](https://support.microsoft.com/help/5040527) (OS Build 22621.3958)
- Windows 10, version 22H2 with [KB5040525](https://support.microsoft.com/help/5040525) (OS Build 19045.4717)
## Refresh interval
The WinDC refresh schedule is created whenever there's a WinDC document present on the device and there's currently no schedule task for refresh. The task runs every 4 hours by default and can be configured. Each time the WinDC refresh task runs, it checks for all drifts from desired state by comparing the current system configuration versus the server intention in the WinDC documents. If there are any drifts, WinDC engine tries to reapply the WinDC documents to fix it. In case where a WinDC document can't be reapplied due to instance data missing, the WinDC document is marked in drifted state and a new sync session is triggered to notify there's a drift.
To identify, adjust or remove the refresh schedule, use the **RefreshInterval** URI:
- Identify current schedule:
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Get>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/ManagementServiceConfiguration/RefreshInterval</LocURI>
</Target>
</Item>
</Get>
<Final />
</SyncBody>
</SyncML>
```
- Adjust current schedule:
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/DMClient/Provider/MS%20DM%20SERVER/LinkedEnrollment/DiscoveryEndpoint</LocURI>
</Target>
<Data>https://discovery.dm.microsoft.com/EnrollmentConfiguration?api-version=1.0</Data>
</Item>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>int</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/ManagementServiceConfiguration/RefreshInterval</LocURI>
</Target>
<Data>30</Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
<Final />
</SyncBody>
</SyncML>
```
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Exec>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/DMClient/Provider/MS%20DM%20SERVER/LinkedEnrollment/Enroll</LocURI>
</Target>
</Item>
</Exec>
<Final/>
</SyncBody>
</SyncML>
```
- Delete the current schedule and use system default:
## Related content
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Delete>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/ManagementServiceConfiguration/RefreshInterval</LocURI>
</Target>
</Item>
</Delete>
<Final />
</SyncBody>
</SyncML>
```
- [Declared Configuration extensibility](declared-configuration-extensibility.md)
## Troubleshooting
If the processing of declared configuration document fails, the errors are logged to Windows event logs:
- Admin events: `Application and Service Logs\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider\Admin`.
- Operational events: `Application and Service Logs\Microsoft\Windows\DeviceManagement-Enterprise-Diagnostics-Provider\Operational`.
### Common errors
- If the `<LocURI>` uses **Device** scope, while DeclaredConfiguration document specifies **User** context, Admin event log shows an error message similar to:
`MDM ConfigurationManager: Command failure status. Configuration Source ID: (DAD70CC2-365B-450D-A8AB-2EB23F4300CC), Enrollment Name: (MicrosoftManagementPlatformCloud), Provider Name: (DeclaredConfiguration), Command Type: (SetValue: from Replace), CSP URI: (./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Documents/DCA000B5-397D-40A1-AABF-40B25078A7F9/Document), Result: (The system cannot find the file specified.)`
- If the Document ID doesn't match between the `<LocURI>` and inside DeclaredConfiguration document, Admin event log shows an error message similar to:
`MDM Declared Configuration: End document parsing from CSP: Document Id: (DCA000B5-397D-40A1-AABF-40B25078A7F91), Scenario: (MSFTVPN), Version: (A0), Enrollment Id: (DAD70CC2-365B-450D-A8AB-2EB23F4300CC), Current User: (S-1-5-21-3436249567-4017981746-3373817415-1001), Schema: (1.0), Download URL: (), Scope: (0x1), Enroll Type: (0x1A), File size: (0xDE2), CSP Count: (0x1), URI Count: (0xF), Action Requested: (0x0), Model: (0x1), Result:(0x8000FFFF) Catastrophic failure.`
- Any typo in the OMA-URI results in a failure. In this example, `TrafficFilterList` is specified instead of `TrafficFilterLists`, and Admin event log shows an error message similar to:
`MDM ConfigurationManager: Command failure status. Configuraton Source ID: (DAD70CC2-365B-450D-A8AB-2EB23F4300CC), Enrollment Type: (MicrosoftManagementPlatformCloud), CSP Name: (vpnv2), Command Type: (Add: from Replace or Add), CSP URI: (./user/vendor/msft/vpnv2/Test_SonicWall/TrafficFilterLists), Result: (Unknown Win32 Error code: 0x86000002).`
There's also another warning message in operational channel:
`MDM Declared Configuration: Function (DeclaredConfigurationExtension_PolicyCSPConfigureGivenCurrentDoc) operation (ErrorAtDocLevel: one or more CSPs failed) failed with (Unknown Win32 Error code: 0x82d00007)`

6
windows/client-management/enterprise-app-management.md
View File

@ -15,7 +15,6 @@ By using Windows MDM to manage app lifecycles, administrators can deploy and man
Windows offers the ability for management servers to:
- Install apps directly from the Microsoft Store for Business
- Deploy offline Store apps and licenses
- Deploy line-of-business (LOB) apps (non-Store apps)
- Inventory all apps for a user (Store and non-Store apps)
@ -28,7 +27,7 @@ Windows offers the ability for management servers to:
Windows lets you inventory all apps deployed to a user, and inventory all apps for all users of a Windows device. The [EnterpriseModernAppManagement](mdm/enterprisemodernappmanagement-csp.md) configuration service provider (CSP) inventories packaged apps and doesn't include traditional Win32 apps installed via MSI or executables. When the apps are inventoried, they're separated based on the following app classifications:
- **Store**: Apps that have been acquired from the Microsoft Store, either directly or delivered with the enterprise from the Store for Business.
- **Store**: Apps that have been acquired from the Microsoft Store.
- **nonStore**: Apps that weren't acquired from the Microsoft Store.
- **System**: Apps that are part of the operating system and can't be uninstalled. This classification is read-only and can only be inventoried.
@ -198,6 +197,9 @@ To deploy an app to a user directly from the Microsoft Store, the management ser
If you purchased an app from the Store for Business and the app is specified for an online license, then the app and license must be acquired directly from the Microsoft Store.
> [!NOTE]
> The Microsoft Store for Business and Microsoft Store for Education are retired. For more information, see [Microsoft Store for Business and Education retiring March 31, 2023](/lifecycle/announcements/microsoft-store-for-business-education-retiring).
Here are the requirements for this scenario:
- The app is assigned to a user Microsoft Entra identity in the Store for Business. You can assign directly in the Store for Business or through a management server.

BIN
windows/client-management/images/declared-configuration-ra-syntax.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 54 KiB

264
windows/client-management/manage-windows-copilot.md
View File

@ -1,9 +1,9 @@
---
title: Manage Copilot in Windows
description: Learn how to manage Copilot in Windows for commercial environments using MDM and group policy. Learn about the chat providers available to Copilot in Windows.
ms.topic: how-to
title: Updated Windows and Microsoft Copilot experience
description: Learn about changes to the Copilot in Windows experience for commercial environments and how to configure it for your organization.
ms.topic: overview
ms.subservice: windows-copilot
ms.date: 06/13/2024
ms.date: 09/18/2024
ms.author: mstewart
author: mestew
ms.collection:
@ -13,226 +13,66 @@ appliesto:
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 11, version 22H2 or later</a>
---
# Manage Copilot in Windows
<!--8445848-->
# Updated Windows and Microsoft Copilot experience
<!--8445848, 9294806-->
>**Looking for consumer information?** See [Welcome to Copilot in Windows](https://support.microsoft.com/windows/welcome-to-copilot-in-windows-675708af-8c16-4675-afeb-85a5a476ccb0).
>**Looking for consumer information?** See [Welcome to Copilot in Windows](https://support.microsoft.com/topic/675708af-8c16-4675-afeb-85a5a476ccb0).
> [!Note]
> - This article and the [TurnOffWindowsCopilot](mdm/policy-csp-windowsai.md#turnoffwindowscopilot) policy isn't for the [new Copilot experience](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/evolving-copilot-in-windows-for-your-workforce/ba-p/4141999) that's in some [Windows Insider builds](https://blogs.windows.com/windows-insider/2024/05/22/releasing-windows-11-version-24h2-to-the-release-preview-channel/) and that will be gradually rolling out to Windows 11 and Windows 10 devices. <!--9048085-->
## Enhanced data protection with enterprise data protection
Copilot in Windows provides centralized generative AI assistance to your users right from the Windows desktop. Copilot in Windows appears as a side bar docked on the Windows desktop and is designed to help users get things done in Windows. Copilot in Windows can perform common tasks in Windows like changing Windows settings, which makes it different from the browser-based [Copilot in Edge](/copilot/edge). However, both user experiences, Copilot in Windows and Copilot in Edge, can share the same underlying chat provider platform. It's important for organizations to properly configure the chat provider platform that Copilot in Windows uses, since it's possible for users to copy and paste sensitive information into the chat.
The Copilot experience on Windows is changing to enhance data security, privacy, compliance, and simplify the user experience, for users signed in with a Microsoft Entra work or school account. [Microsoft Copilot will offer enterprise data protection](https://techcommunity.microsoft.com/t5/copilot-for-microsoft-365/updates-to-microsoft-copilot-to-bring-enterprise-data-protection/ba-p/4217152) at no additional cost and redirect users to a new simplified interface designed for work and education. [Enterprise data protection (EDP)](/copilot/microsoft-365/enterprise-data-protection) refers to controls and commitments, under the Data Protection Addendum and Product Terms, that apply to customer data for users of Copilot for Microsoft 365 and Microsoft Copilot. This means that security, privacy, compliance controls and commitments available for Copilot for Microsoft 365 will extend to Microsoft Copilot prompts and responses. Prompts and responses are protected by the same terms and commitments that are widely trusted by our customers - not only for Copilot for Microsoft 365, but also for emails in Exchange and files in SharePoint. This is an improvement on top of the previous commercial data protection (CDP) promise. This update is rolling out now. For more information, see the [Microsoft Copilot updates and enterprise data protection FAQ](/copilot/edpfaq).
> [!IMPORTANT]
> To streamline the user experience, updates to the Copilot entry points in Windows are being made for users. **Copilot in Windows (preview) will be removed from Windows**. The experience will slightly vary depending on whether your organization has already opted into using Copilot in Windows (preview) or not.
## Copilot in Windows (preview) isn't enabled
If your organization hasn't enabled Copilot in Windows (preview), your existing preferences are respected. Neither the Microsoft Copilot app nor the Microsoft 365 app are pinned to the taskbar. To prepare for the eventual removal of the [Copilot in Windows policy](/windows/client-management/mdm/policy-csp-windowsai#turnoffwindowscopilot), admins should [set Microsoft Copilot pinning options](/copilot/microsoft-365/pin-copilot) in the Microsoft 365 admin center.
> [!NOTE]
> Although we won't be pinning any app to the taskbar by default, IT has the capability to use policies to enforce their preferred app pinning.
## Copilot in Windows (preview) is enabled
If you had previously activated Copilot in Windows (in preview) for your workforce, we want to thank you for your enthusiasm. To provide the best Copilot experience for your employees moving forward, and support greater efficiency and productivity, we won't automatically pin the Microsoft 365 app to the taskbar in Windows. Rather, we'll ensure that you have control over how you enable the Copilot experience within your organization. Our focus remains on empowering IT to seamlessly manage AI experiences and adopt those experiences at a pace that suits your organizational needs.
If you have already activated Copilot in Windows (preview) - and want your users to have uninterrupted access to Copilot on the taskbar after the update - use the [configuration options](/windows/configuration/taskbar/?pivots=windows-11) to pin the Microsoft 365 app to the taskbar as Copilot in Windows (preview) icon will be removed from the taskbar.
## Users signing in to new PCs with Microsoft Entra accounts
For users signing in to new PCs with work or school accounts, the following experience occurs:
- The Microsoft 365 app is pinned to the taskbar - this is the app comes preinstalled with Windows and includes convenient access to Office apps such as Word, PowerPoint, etc.
- Users that have the Microsoft 365 Copilot license will have Microsoft Copilot pinned by default inside the Microsoft 365 app.
- Within the Microsoft 365 app, the Microsoft Copilot icon is situated next to the home button.
- Microsoft Copilot (`web` grounding chat) isn't the same as Microsoft 365 Copilot (`web` and `work` scope), which is a separate add-on license.
- Microsoft Copilot is available at no additional cost to customers with a Microsoft Entra account. Microsoft Copilot is the entry point for Copilot at work. While the Copilot chat experience helps users ground their conversations in web data, Microsoft 365 Copilot allows users to incorporate both web and work data they have access to into their conversations by switching between work and web modes in Business Chat.
- For users with the Microsoft 365 Copilot license, they can toggle between the web grounding-based chat capabilities of Microsoft Copilot and the work scoped chat capabilities of Microsoft 365 Copilot.
- Customers that don't have a license for Microsoft 365 Copilot are asked if they want to pin Microsoft Copilot to ensure they have easy access to Copilot. To set the default behavior, admins should [set Microsoft Copilot pinning options](/copilot/microsoft-365/pin-copilot) in the Microsoft 365 admin center.
- If admins elect not to pin Copilot and indicate that users may be asked, users will be asked to pin it themselves in the Microsoft 365 app, Outlook, and Teams.
- If admins elect not to pin Microsoft Copilot and indicate that users may not be asked, Microsoft Copilot won't be available via the Microsoft 365 app, Outlook, or Teams. Users will have access to Microsoft Copilot from <www.microsoft.com/copilot> unless that URL is blocked by the IT admin.
- If the admins make no selection, users will be asked to pin Microsoft Copilot by themselves for easy access.
## Configure Copilot in Windows for commercial environments
## When will this happen?
At a high level, managing and configuring Copilot in Windows for your organization involves the following steps:
The update to Microsoft Copilot to offer enterprise data protection is rolling out now.
> [!Note]
> - Copilot in Windows is currently available as a preview. We will continue to experiment with new ideas and methods using your feedback.
> - Copilot in Windows (in preview) is available in select global markets and will be rolled out to additional markets over time. [Learn more](https://www.microsoft.com/windows/copilot-ai-features#faq). <!--8737645-->
The shift to the Microsoft 365 app as the entry point for Microsoft Copilot is coming soon. Changes will be rolled out to managed PCs starting with the optional nonsecurity preview release on September 24, 2024, and following with the monthly security update release on October 8 for all supported versions of Windows 11. These changes will be applied to Windows 10 PCs the month after. This update is replacing the current Copilot in Windows experience.
1. Understand the [available chat provider platforms for Copilot in Windows](#chat-provider-platforms-for-copilot-in-windows)
1. [Configure the chat provider platform](#configure-the-chat-provider-platform-that-copilot-in-windows-uses) used by Copilot in Windows
1. Ensure the [Copilot in Windows user experience](#ensure-the-copilot-in-windows-user-experience-is-enabled) is enabled
1. Verify [other settings that might affect Copilot in Windows](#other-settings-that-might-affect-copilot-in-windows-and-its-underlying-chat-provider) and its underlying chat provider
> [!IMPORTANT]
> Want to get started? You can enable the Microsoft Copilot experience for your users now by using the [TurnOffWindowsCopilot](/windows/client-management/mdm/policy-csp-windowsai#turnoffwindowscopilot) policy and pin the Microsoft 365 app using the existing policies for taskbar pinning.
## Policy information
Admins should configure the [pinning options](/copilot/microsoft-365/pin-copilot) to enable access to Microsoft Copilot within the Microsoft 365 app in the Microsoft 365 admin center.
The following policy to manage Copilot in Windows (preview) will be removed in the future:
Organizations that aren't ready to use Copilot in Windows can disable it until they're ready with the **Turn off Windows Copilot** policy. This policy setting allows you to turn off Copilot in Windows. If you enable this policy setting, users can't use Copilot in Windows and the icon doesn't appear on the taskbar either. If you disable or don't configure this policy setting, users can use Copilot in Windows when it's available to them.
| &nbsp; | Setting |
|---|---|
| **CSP** | ./User/Vendor/MSFT/Policy/Config/WindowsAI/[TurnOffWindowsCopilot](mdm/policy-csp-windowsai.md#turnoffwindowscopilot) |
| **Group policy** | User Configuration > Administrative Templates > Windows Components > Windows Copilot > **Turn off Windows Copilot** |
## Chat provider platforms for Copilot in Windows
Copilot in Windows can use either Microsoft Copilot, Copilot with commercial data protection, or Copilot with Graph-grounded chat as its chat provider platform. The chat provider platform is the underlying service that Copilot in Windows uses to communicate with the user. The chat provider platform is important because it's possible for users to copy and paste sensitive information into the chat. Each chat provider platform has different privacy and security protections.
### Copilot
Copilot is a consumer experience and has a daily limit on the number of chat queries per user when not signed in with a Microsoft account. It doesn't offer the same data protection as Copilot with commercial data protection.
- [Copilot in Windows: Your data and privacy](https://support.microsoft.com/windows/3e265e82-fc76-4d0a-afc0-4a0de528b73a)
- The privacy statement for using Copilot follows the [Microsoft privacy statement](https://privacy.microsoft.com/privacystatement) including the product specific guidance in the Microsoft privacy statement for **Bing** under the **Search, Microsoft Edge, and artificial intelligence** section.
> [!Note]
> Copilot doesn't have access to Microsoft 365 Apps data, such as email, calendar, or files using Microsoft Graph, unlike [Microsoft Copilot with Graph-grounded chat](#microsoft-copilot-with-graph-grounded-chat).
### Copilot with commercial data protection
[Copilot with commercial data protection](/copilot/overview) is intended for commercial use scenarios and offers commercial data protection. The following privacy and security protections apply for Copilot with commercial data protection:
- User and organizational data is protected, chat data isn't saved, and your data isn't used to train the underlying large language models (LLMs). Because of this protection, chat history, 3rd-party plugins, and the Bing app for iOS or Android aren't currently supported. Copilot with commercial data protection is accessible from mobile browsers, including Edge mobile on iOS and Android. Review the Copilot with commercial data protection [privacy statement](/copilot/privacy-and-protections).
- Copilot with commercial data protection is available, at no additional cost, for the following licenses:
- Microsoft 365 E3 or E5
- Microsoft 365 F3 <!--8681080, 8681034-->
- Microsoft 365 A1, A3, or A5 <!--8681034-->
- Copilot with commercial data protection is limited to faculty and higher education students over 18 years of age
- Office 365 A1, A3, or A5 <!--8681034-->
- Copilot with commercial data protection is limited to faculty and higher education students over 18 years of age
- Microsoft 365 Business Standard
- Microsoft 365 Business Premium
> [!Note]
> Copilot with commercial data protection doesn't have access to Microsoft 365 Apps data, such as email, calendar, or files using Microsoft Graph, unlike [Microsoft Copilot with Graph-grounded chat](#microsoft-copilot-with-graph-grounded-chat).
### Microsoft Copilot with Graph-grounded chat
<!---8639813-->
Copilot with Graph-grounded chat enables you to use your work content and context in Copilot for Windows. With Graph-grounded chat, you can draft content and get answers to questions, all securely grounded in your Microsoft Graph data such as user documents, emails, calendar, chats, meetings, and contacts. When you use the **Work** toggle in Copilot in Windows to query Graph-grounded chat, the following high-level privacy and security protections apply:
- Prompts, responses, and data accessed through Microsoft Graph aren't used to train foundational LLMs.
- It only surfaces organizational data to which individual users have at least view permissions.
- The information contained within your prompts, the data retrieved, and the generated responses remain within your tenant's service boundary. For more information about privacy and security for Graph-grounded chat, see [Data, Privacy, and Security for Microsoft Copilot for Microsoft 365](/microsoft-365-copilot/microsoft-365-copilot-privacy)
- Copilot with Graph-grounded chat is part of Copilot for Microsoft 365. Copilot for Microsoft 365 is an add-on plan. For more information about prerequisites and license requirements, see [Microsoft Copilot for Microsoft 365 requirements](/microsoft-365-copilot/microsoft-365-copilot-requirements#license-requirements).
## Configure the chat provider platform that Copilot in Windows uses
Configuring the correct chat provider platform for Copilot in Windows is important because it's possible for users to copy and paste sensitive information into the chat. Each chat provider platform has different privacy and security protections. Once you select the chat provider platform that you want to use for Copilot in Windows, ensure it's configured for your organization's users. The following sections describe how to configure the chat provider platform that Copilot in Windows uses.
### Microsoft Copilot as the chat provider platform
Copilot is used as the default chat provider platform for Copilot in Windows when any of the following conditions occur:
- Commercial data protection isn't configured for the user.
- Commercial data protection is [turned off](/copilot/manage).
- The user isn't assigned a license that includes Copilot with commercial data protection.
- The user isn't signed in with a Microsoft Entra account that's licensed for Copilot with commercial data protection.
### Copilot with commercial data protection as the chat provider platform (recommended for commercial environments)
To verify that Copilot with commercial data protection is enabled for the user as the chat provider platform for Copilot in Windows, use the following instructions:
1. Sign into the [Microsoft 365 admin center](https://admin.microsoft.com/).
1. In the admin center, select **Users** > **Active users** and verify that users are assigned a license that includes **Copilot**. Copilot with commercial data protection is included and enabled by default for users that are assigned one of the following licenses:
- Microsoft 365 E3 or E5
- Microsoft 365 F3 <!--8681080, 8681034-->
- Microsoft 365 A1, A3, or A5
- Copilot with commercial data protection is limited to faculty and higher education students over 18 years of age <!--8681034-->
- Office 365 A1, A3, or A5 <!--8681034-->
- Copilot with commercial data protection is limited to faculty and higher education students over 18 years of age <!--8681034-->
- Microsoft 365 Business Standard
- Microsoft 365 Business Premium
1. To verify that commercial data protection is enabled for the user, select the user's **Display name** to open the flyout menu.
1. In the flyout, select the **Licenses & apps** tab, then expand the **Apps** list.
1. Verify that **Copilot** is enabled for the user.
1. If you prefer to view a user's licenses from the [Azure portal](https://portal.azure.com), you'll find it under **Microsoft Entra ID** > **Users**. Select the user's name, then **Licenses**. Select a license that includes **Copilot**, and verify that it's listed as **On**. If you previously disabled Copilot with commercial data protection (formerly Bing Chat Enterprise), see [Manage Copilot](/copilot/manage) for verifying that commercial data protection is enabled for your users.
1. Copilot with commercial data protection is used as the chat provider platform for users when the following conditions are met:
- Users have an eligible license, commercial data protection in Copilot is enabled, and the [Copilot in Windows user experience is enabled](#enable-the-copilot-in-windows-user-experience-for-windows-11-version-22h2-clients).
- Users are signed in with their Microsoft Entra ID (work accounts)
- Users can sign into Windows with their Microsoft Entra ID
- For Active Directory users on Windows 11, a Microsoft Entra ID in the Web Account Manager (WAM) authentication broker can be used. Entra IDs in Microsoft Edge profiles and Microsoft 365 Apps would both be in WAM. <!--8470699-->
The following sample PowerShell script connects to Microsoft Graph and lists which users that have Copilot with commercial data protection enabled and disabled:
```powershell
# Install Microsoft Graph module
if (-not (Get-Module Microsoft.Graph.Users)) {
Install-Module Microsoft.Graph.Users
}
# Connect to Microsoft Graph
Connect-MgGraph -Scopes 'User.Read.All'
# Get all users
$users = Get-MgUser -All -ConsistencyLevel eventual -Property Id, DisplayName, Mail, UserPrincipalName, AssignedPlans
# Users with Copilot with commercial data protection enabled
$users | Where-Object { $_.AssignedPlans -and $_.AssignedPlans.Service -eq "Bing" -and $_.AssignedPlans.CapabilityStatus -eq "Enabled" } | Format-Table
# Users without Copilot with commercial data protection enabled
$users | Where-Object { -not $_.AssignedPlans -or ($_.AssignedPlans.Service -eq "Bing" -and $_.AssignedPlans.CapabilityStatus -ne "Enabled") } | Format-Table
```
When Copilot with commercial data protection is the chat provider platform, the user experience clearly states that **Your personal and company data are protected in this chat**. There's also a shield symbol labeled **Protected** at the top of the Copilot in Windows sidebar and the provider is listed under the Copilot logo when the sidebar is first opened. The following image shows the message that's displayed in this scenario:
:::image type="content" source="images/copilot-commercial-data-protection-chat-provider.png" alt-text="Screenshot of the Copilot in Windows user experience when Copilot with commercial data protection is the chat provider." lightbox="images/copilot-commercial-data-protection-chat-provider.png":::
### Copilot with Graph-grounded chat as the chat provider platform
<!---8639813-->
When users are assigned [Microsoft Copilot for Microsoft 365](/microsoft-365-copilot/microsoft-365-copilot-setup) licenses, they're automatically presented with a **Work** toggle in Copilot for Windows. When **Work** is selected, Copilot with Graph-grounded chat is the chat provider platform used by Copilot in Windows. When using Graph-grounded chat, user prompts can securely access Microsoft Graph content, such as emails, chats, and documents.
:::image type="content" source="images/work-toggle-graph-grounded-chat.png" alt-text="Screenshot of the Copilot in Windows user experience when the work toggle is selected and the chart provider is Copilot with Graph-grounded chat." lightbox="images/work-toggle-graph-grounded-chat.png":::
## Ensure the Copilot in Windows user experience is enabled
Once you've configured the chat provider platform that Copilot in Windows uses, you need to ensure that the Copilot in Windows user experience is enabled. Ensuring the Copilot in Windows user experience is enabled varies by the Windows version.
### Enable the Copilot in Windows user experience for Windows 11, version 22H2 clients
Copilot in Windows isn't technically enabled by default for managed Windows 11, version 22H2 devices because it's behind a [temporary enterprise control](/windows/whats-new/temporary-enterprise-feature-control). For the purposes of temporary enterprise control, a system is considered managed if it's configured to get updates from Windows Update for Business or [Windows Server Update Services (WSUS)](/windows-server/administration/windows-server-update-services/get-started/windows-server-update-services-wsus). Clients that get updates from Microsoft Configuration Manager, Microsoft Intune, and Windows Autopatch are considered managed since their updates ultimately come from WSUS or Windows Updates for Business.
To enable Copilot in Windows for managed Windows 11, version 22H2 devices, you need to enable features under temporary enterprise control for these devices. Since enabling features behind [temporary enterprise control](/windows/whats-new/temporary-enterprise-feature-control) can be impactful, you should test this change before deploying it broadly. To enable Copilot in Windows for managed Windows 11, version 22H2 devices, use the following instructions:
1. Verify that the user accounts have the correct chat provider platform configured for Copilot in Windows. For more information, see the [Configure the chat provider platform that Copilot in Windows uses](#configure-the-chat-provider-platform-that-copilot-in-windows-uses) section.
1. Apply a policy to enable features under temporary enterprise control for managed clients. The following polices apply to Windows 11, version 22H2 with [KB5022845](https://support.microsoft.com/topic/february-14-2023-kb5022845-os-build-22621-1265-90a807f4-d2e8-486e-8a43-d09e66319f38) and later:
- **Group Policy:** Computer Configuration\Administrative Templates\Windows Components\Windows Update\Manage end user experience\\**Enable features introduced via servicing that are off by default**
- **CSP**: ./Device/Vendor/MSFT/Policy/Config/Update/[AllowTemporaryEnterpriseFeatureControl](/windows/client-management/mdm/policy-csp-update?toc=/windows/deployment/toc.json&bc=/windows/deployment/breadcrumb/toc.json#allowtemporaryenterprisefeaturecontrol)
- In the Intune [settings catalog](/mem/intune/configuration/settings-catalog), this setting is named **Allow Temporary Enterprise Feature Control** under the **Windows Update for Business** category.
> [!Important]
> For the purposes of temporary enterprise control, a system is considered managed if it's configured to get updates from Windows Update for Business or [Windows Server Update Services (WSUS)](/windows-server/administration/windows-server-update-services/get-started/windows-server-update-services-wsus). Clients that get updates from Microsoft Configuration Manager, Microsoft Intune, and Windows Autopatch are considered managed since their updates ultimately come from WSUS or Windows Updates for Business.
1. Copilot in Windows will be initially deployed to devices using a controlled feature rollout (CFR). Depending on how soon you start deploying Copilot in Windows, you might also need to [enable optional updates](/windows/deployment/update/waas-configure-wufb#enable-optional-updates) with one of the following policies:
- **Group Policy:** Computer Configuration\Administrative Templates\Windows Components\Windows Update\Windows Update for Business\\**Allow updates to Windows optional features**
- **CSP**: ./Device/Vendor/MSFT/Policy/Config/Update/[AllowOptionalUpdates](/windows/client-management/mdm/policy-csp-update?toc=/windows/deployment/toc.json&bc=/windows/deployment/breadcrumb/toc.json#allowoptionalupdates)
- In the Intune [settings catalog](/mem/intune/configuration/settings-catalog), this setting is named **Allow optional updates** under the **Windows Update for Business** category.
The optional updates policy applies to Windows 11, version 22H2 with [KB5029351](https://support.microsoft.com/help/5029351) and later. When setting policy for [optional updates](/windows/deployment/update/waas-configure-wufb#enable-optional-updates), ensure you select one of the following options that includes CFRs:
- Automatically receive optional updates (including CFRs)
- This selection places devices into an early CFR phase
- Users can select which optional updates to receive
1. Windows 11, version 22H2 devices display Copilot in Windows when the CFR is enabled for the device. CFRs are enabled for devices in phases, sometimes called waves.
### Enable the Copilot in Windows user experience for Windows 11, version 23H2 clients
Once a managed device installs the version 23H2 update, the [temporary enterprise control](/windows/whats-new/temporary-enterprise-feature-control) for Copilot in Windows is removed. This means that Copilot in Windows is enabled by default for these devices.
While the user experience for Copilot in Windows is enabled by default, you still need to verify that the correct chat provider platform configured for Copilot in Windows. While every effort is made to ensure that Copilot with commercial data protection is the default chat provider for commercial organizations, it's still possible that Copilot might still be used if the configuration is incorrect, or if other settings are affecting Copilot in Windows. For more information, see:
- [Configure the chat provider platform that Copilot in Windows uses](#configure-the-chat-provider-platform-that-copilot-in-windows-uses)
- [Other settings that might affect Copilot in Windows and its underlying chat provider](#other-settings-that-might-affect-copilot-in-windows-and-its-underlying-chat-provider)
Organizations that aren't ready to use Copilot in Windows can disable it until they're ready by using the following policy:
- **CSP**: ./User/Vendor/MSFT/Policy/Config/WindowsAI/[TurnOffWindowsCopilot](mdm/policy-csp-windowsai.md#turnoffwindowscopilot)
- **Group Policy**: User Configuration\Administrative Templates\Windows Components\Windows Copilot\\**Turn off Windows Copilot**
## Other settings that might affect Copilot in Windows and its underlying chat provider
Copilot in Windows and [Copilot in Edge](/copilot/edge), can share the same underlying chat provider platform. This also means that some settings that affect Copilot, Copilot with commercial data protection, and Copilot in Edge can also affect Copilot in Windows. The following common settings might affect Copilot in Windows and its underlying chat provider:
### Bing settings
- If [SafeSearch](https://support.microsoft.com/topic/946059ed-992b-46a0-944a-28e8fb8f1814) is enabled for Bing, it can block chat providers for Copilot in Windows. The following network changes block the chat providers for Copilot in Windows and Edge:
- Mapping `www.bing.com` to `strict.bing.com`
- Mapping `edgeservices.bing.com` to `strict.bing.com`
- Blocking `bing.com`
- If Copilot with commercial data protection is turned on for your organization, users can access it through Edge mobile when signed in with their work account. If you would like to remove the Bing Chat button from the Edge mobile interface, you can use an [Intune Mobile Application Management (MAM) policy for Microsoft Edge](/mem/intune/apps/manage-microsoft-edge) to remove it:
| Key | Value |
|:---------------------------------------------|:---------------------------------------------------------------------------|
| com.microsoft.intune.mam.managedbrowser.Chat | **true** (default) shows the interface </br> **false** hides the interface |
### Microsoft Edge policies
- If [HubsSidebarEnabled](/deployedge/microsoft-edge-policies#hubssidebarenabled) is set to `disabled`, it blocks Copilot in Edge from being displayed.
- If [DiscoverPageContextEnabled](/deployedge/microsoft-edge-policies#discoverpagecontextenabled) is set to `disabled`, it blocks Copilot from reading the current webpage context. The chat providers need access to the current webpage context for providing page summarizations and sending user selected strings from the webpage into the chat provider.
### Search settings
- Setting [ConfigureSearchOnTaskbarMode](/windows/client-management/mdm/policy-csp-search#configuresearchontaskbarmode) to `Hide` might interfere with the Copilot in Windows user experience.
- Setting [AllowSearchHighlights](/windows/client-management/mdm/policy-csp-search#allowsearchhighlights) to `disabled` might interfere with the Copilot in Windows and the Copilot in Edge user experiences.
### Account settings
- The [AllowMicrosoftAccountConnection](/windows/client-management/mdm/policy-csp-accounts#allowmicrosoftaccountconnection) setting might allow users to use their personal Microsoft account with Copilot in Windows and Copilot in Edge.
- The [RestrictToEnterpriseDeviceAuthenticationOnly](/windows/client-management/mdm/policy-csp-accounts#restricttoenterprisedeviceauthenticationonly) setting might prevent access to chat providers since it blocks user authentication.
## Microsoft's commitment to responsible AI
Microsoft has been on a responsible AI journey since 2017, when we defined our principles and approach to ensuring this technology is used in a way that is driven by ethical principles that put people first. For more about our responsible AI journey, the ethical principles that guide us, and the tooling and capabilities we've created to assure that we develop AI technology responsibly, see [Responsible AI](https://www.microsoft.com/ai/responsible-ai).

329
windows/client-management/mdm/declaredconfiguration-csp.md
View File

@ -1,7 +1,7 @@
---
title: DeclaredConfiguration CSP
description: Learn more about the DeclaredConfiguration CSP.
ms.date: 01/18/2024
ms.date: 09/12/2024
---
<!-- Auto-Generated CSP Document -->
@ -15,13 +15,13 @@ ms.date: 01/18/2024
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
The primary MDM model is one where the MDM server is solely responsible for orchestration and continuous maintenance of the state of the device for configuration scenarios. This behavior results in intensive network traffic and high network latency due to the synchronous configuration model based on the OMA-DM Syncml standard. It's also error-prone given that the server needs deep knowledge of the client.
The declared configuration device management model requires the server to deliver all the setting values to the device for the scenario configuration. The server sends them asynchronously in batches through the client declared configuration CSP.
The Windows declared configuration (WinDC) device management model requires the server to deliver all the setting values to the device for the scenario configuration. The server sends them asynchronously in batches through the DeclaredConfiguration CSP.
- During the client-initiated OMA-DM session, the declared configuration server sends a configuration or an inventory declared configuration document to the client through the [Declared Configuration CSP URI](#declared-configuration-oma-uri). If the device verifies the syntax of the document is correct, the client stack pushes the request to its orchestrator to process the request asynchronously. The client stack then exits, and returns control back to the declared configuration service. This behavior allows the device to asynchronously process the request.
- During the client-initiated OMA-DM session, the WinDC server sends a configuration or an inventory WinDC document to the client through the [DeclaredConfiguration CSP URI](#declaredconfiguration-oma-uri). If the device verifies the syntax of the document is correct, the client stack pushes the request to its orchestrator to process the request asynchronously. The client stack then exits, and returns control back to the WinDC service. This behavior allows the device to asynchronously process the request.
- On the client, if there are any requests in process or completed, it sends a [generic alert](#declared-configuration-generic-alert) to the server. This alert summarizes each document's status, state, and progress. Every client HTTPS request to the declared configuration OMA-DM server includes this summary.
- On the client, if there are any requests in process or completed, it sends a [generic alert](#windc-generic-alert) to the server. This alert summarizes each document's status, state, and progress. Every client HTTPS request to the WinDC OMA-DM server includes this summary.
- The declared configuration server uses the generic alert to determine which requests are completed successfully or with errors. The server can then synchronously retrieve the declared configuration document process results through the [Declared Configuration CSP URI](#declared-configuration-oma-uri).
- The WinDC server uses the generic alert to determine which requests are completed successfully or with errors. The server can then synchronously retrieve the WinDC document process results through the [DeclaredConfiguration CSP URI](#declaredconfiguration-oma-uri).
<!-- DeclaredConfiguration-Editable-End -->
<!-- DeclaredConfiguration-Tree-Begin -->
@ -730,107 +730,51 @@ The Document node's value is an XML based document containing a collection of se
<!-- DeclaredConfiguration-CspMoreInfo-Begin -->
<!-- Add any additional information about this CSP here. Anything outside this section will get overwritten. -->
## Declared configuration OMA URI
## DeclaredConfiguration OMA URI
A declared configuration request is sent using an OMA-URI similar to `./Device/Vendor/MSFT/DeclaredConfiguration/Host/[Complete|Inventory]/Documents/{DocID}/Document`.
A WinDC request is sent using an OMA-URI similar to `./Device/Vendor/MSFT/DeclaredConfiguration/Host/[Complete|Inventory]/Documents/{DocID}/Document`.
- The URI is prefixed with a targeted scope. The target of the scenario settings can only be device wide for extensibility. The scope should be `Device`.
- The URI is prefixed with a targeted scope (`User` or `Device`).
- `{DocID}` is a unique identifier for the desired state of the configuration scenario. Every document must have an ID, which must be a GUID.
- The request can be a **Configuration**, **Inventory**, or **Complete** request.
- The request can be a **Inventory**, or **Complete** request.
The following URI is an example of a **Complete** request: `./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Documents/27FEA311-68B9-4320-9FC4-296F6FDFAFE2/Document`
## DeclaredConfiguration document XML
The value of the leaf node `Document` is an XML document that describes the request. The actual processing of the request pivots around the `osdefinedscenario` tag:
- `MSFTExtensibilityMIProviderConfig`: Used to configure MI provider settings.
- `MSFTExtensibilityMIProviderInventory`: Used to retrieve MI provider setting values.
The DeclaredConfiguration CSP synchronously validates the batch of settings described by the `<DeclaredConfiguration>` element, which represents the declared configuration document. It checks for correct syntax based on the declared configuration XML schema. If there's a syntax error, the CSP returns an error immediately back to the server as part of the current OMA-DM session. If the syntax check passes, then the request is passed on to a Windows service. The Windows service asynchronously attempts the desired state configuration of the specified scenario. This process frees up the server to do other work thus the low latency of this declared configuration protocol. The Windows client service, the orchestrator, is responsible for driving the configuration of the device based on the server supplied desire state. The service also maintains this state throughout its lifetime, until the server removes or modifies it.
The following example uses the built-in, native MI provider `MSFT_FileDirectoryConfiguration` with the OS-defined scenario `MSFTExtensibilityMIProviderConfig`:
## WinDC document
```xml
<DeclaredConfiguration schema="1.0" context="Device" id="27FEA311-68B9-4320-9FC4-296F6FDFAFE2" checksum="99925209110918B67FE962460137AA3440AFF4DB6ABBE15C8F499682457B9999" osdefinedscenario="MSFTExtensibilityMIProviderConfig">
<DSC namespace="root/Microsoft/Windows/DesiredStateConfiguration" className="MSFT_FileDirectoryConfiguration">
<Key name="DestinationPath">c:\data\test\bin\ut_extensibility.tmp</Key>
<Value name="Contents">TestFileContentBlah</Value>
</DSC>
<DeclaredConfiguration
schema="1.0"
context="Device"
id="27FEA311-68B9-4320-9FC4-296F6FDFAFE2"
checksum="99925209110918B67FE962460137AA3440AFF4DB6ABBE15C8F499682457B9999"
osdefinedscenario="MSFTExtensibilityMIProviderConfig">
... {Configuration Data} ...
</DeclaredConfiguration>
```
The standard OMA-DM SyncML syntax is used to specify the DeclaredConfiguration CSP operations such as **Replace**, **Set**, and **Delete**. The payload of the SyncML's `<Data>` element must be XML-encoded. For this XML encoding, there are various online encoders that you can use. To avoid encoding the payload, you can use [CDATA Section](https://www.w3.org/TR/REC-xml/#sec-cdata-sect) as shown in the following example:
The `<DeclaredConfiguration>` XML tag specifies the details of the WinDC document to process. The document could be part of a configuration request or an inventory request. The DeclaredConfiguration CSP has two URIs to allow the specification of a [configuration](#hostcomplete) or an [inventory](#hostinventory) request.
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Replace>
<CmdID>14</CmdID>
<Item>
<Target>
<LocURI> ./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Documents/99988660-9080-3433-96e8-f32e85011999/Document</LocURI>
</Target>
<Data>
<![CDATA[<DeclaredConfiguration schema="1.0" context="Device" id="27FEA311-68B9-4320-9FC4-296F6FDFAFE2" checksum="99925209110918B67FE962460137AA3440AFF4DB6ABBE15C8F499682457B9999" osdefinedscenario="MSFTExtensibilityMIProviderConfig">
<DSC namespace="root/Microsoft/Windows/DesiredStateConfiguration" className="MSFT_FileDirectoryConfiguration">
<Key name="DestinationPath">c:\data\test\bin\ut_extensibility.tmp</Key>
<Value name="Contents">TestFileContentBlah</Value>
</DSC>
</DeclaredConfiguration>]]>
</Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
```
This tag has the following attributes:
### DeclaredConfiguration XML document tags
| Attribute | Description |
|---------------------|----------------------------------------------------------------------------------------|
| `schema` | The schema version of the xml. Currently `1.0`. |
| `context` | States whether the document is targeting the device or user. |
| `id` | The unique identifier of the document set by the server. This value should be a GUID. |
| `checksum` | This value is the server-supplied version of the document. |
| `osdefinedscenario` | The named scenario that the client should configure with the given configuration data. |
Both `MSFTExtensibilityMIProviderConfig` and `MSFTExtensibilityMIProviderInventory` are OS-defined scenarios that require the same tags and attributes.
The DeclaredConfiguration CSP synchronously validates the batch of settings described by the `<DeclaredConfiguration>` element, which represents the WinDC document. It checks for correct syntax based on the WinDC XML schema. If there's a syntax error, the CSP returns an error immediately back to the server as part of the current OMA-DM session. If the syntax check passes, then the request is passed on to a Windows service. The Windows service asynchronously attempts the desired state configuration of the specified scenario. This process frees up the server to do other work thus the low latency of the WinDC protocol. The Windows client service, the orchestrator, is responsible for driving the configuration of the device based on the server supplied desire state. The service also maintains this state throughout its lifetime, until the server removes or modifies it.
- The `<DeclaredConfiguration>` XML tag specifies the details of the declared configuration document to process. The document could be part of a configuration request or an inventory request. The DeclaredConfiguration CSP has two URIs to allow the specification of a configuration or an inventory request.
The actual processing of the request pivots around the `osdefinedscenario` tag and the configuration data specified within the document. For more information, see:
This tag has the following attributes:
- [WinDC document for resource access](../declared-configuration-resource-access.md#windc-document)
- [WinDC document for extensibility](../declared-configuration-extensibility.md#windc-document)
| Attribute | Description |
|--|--|
| `schema` | The schema version of the xml. Currently `1.0`. |
| `context` | States that this document is targeting the device. The value should be `Device`. |
| `id` | The unique identifier of the document set by the server. This value should be a GUID. |
| `checksum` | This value is the server-supplied version of the document. |
| `osdefinedscenario` | The named scenario that the client should configure with the given configuration data. For extensibility, the scenario is either `MSFTExtensibilityMIProviderConfig` or `MSFTExtensibilityMIProviderInventory`. |
## WinDC generic alert
- The `<DSC>` XML tag describes the targeted WMI provider expressed by a namespace and class name along with the values either to be applied to the device or queried by the MI provider.
This tag has the following attributes:
| Attribute | Description |
|--|--|
| `namespace` | Specifies the targeted MI provider namespace. |
| `classname` | The targeted MI provider. |
- The `<Key>` XML tag describes the required parameter name and value. It only needs a value for configuration. The name is an attribute and the value is `<Key>` content.
This tag has the following attributes:
| Attribute | Description |
|--|--|
| `name` | Specifies the name of an MI provider parameter. |
- The `<Value>` XML tag describes the optional parameter name and value. It only needs a value for configuration. The name is an attribute and the value is `<Value>` content.
This tag has the following attributes:
| Attribute | Description |
|--|--|
| `name` | Specifies the name of an MI provider parameter. |
## Declared configuration generic alert
On every client response to the server's request, the client constructs a declared configuration alert. This alert summarizes the state of each of the documents that the Windows service has processed. The following XML is an example alert:
On every client response to the server's request, the client constructs a WinDC alert. This alert summarizes the state of each of the documents that the Windows service has processed. The following XML is an example alert:
```xml
<Alert>
@ -853,9 +797,13 @@ On every client response to the server's request, the client constructs a declar
</Alert>
```
In this example, there's one declared configuration document listed in the alert summary. The alert summary lists every document that the client stack is processing, either a configuration or inventory request. It describes the context of the document that specifies the scope of how the document is applied. The **context** value should be `Device`.
In this example, there's one WinDC document listed in the alert summary. The alert summary lists every document that the client stack is processing, either a configuration or inventory request. It describes the context of the document that specifies the scope of how the document is applied. The **context** value should be `Device`.
The **state** attribute has a value of `60`, which indicates that the document was processed successfully. The following class defines the other state values:
The **state** attribute has a value of `60`, which indicates that the document was processed successfully.
## WinDC states
The following class defines the state values:
```csharp
enum class DCCSPURIState :unsigned long
@ -889,150 +837,83 @@ enum class DCCSPURIState :unsigned long
## SyncML examples
- Retrieve the results of a configuration or inventory request:
- [SyncML examples for resource access](../declared-configuration-resource-access.md#syncml-examples)
- [SyncML examples for extensibility](../declared-configuration-extensibility.md#syncml-examples)
```xml
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Get>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>chr</Format>
<Type>text/plain</Type>
</Meta>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Results/27FEA311-68B9-4320-9FC4-296F6FDFAFE2/Document</LocURI>
</Target>
</Item>
</Get>
<Final />
</SyncBody>
</SyncML>
```
### Abandon a WinDC document
```xml
<Status>
<CmdID>2</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>2</CmdRef>
<Cmd>Get</Cmd>
<Data>200</Data>
</Status>
<Results>
<CmdID>3</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>2</CmdRef>
<Item>
<Source>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Results/27FEA311-68B9-4320-9FC4-296F6FDFAFE2/Document</LocURI>
</Source>
<Data>
<DeclaredConfigurationResult context="Device" schema="1.0" id="99988660-9080-3433-96e8-f32e85011999" osdefinedscenario="MSFTPolicies" checksum="99925209110918B67FE962460137AA3440AFF4DB6ABBE15C8F499682457B9999" result_checksum="EE4F1636201B0D39F71654427E420E625B9459EED17ACCEEE1AC9B358F4283FD" operation="Set" state="60">
<DSC namespace="root/Microsoft/Windows/DesiredStateConfiguration" className="MSFT_FileDirectoryConfiguration" status="200" state="60">
<Key name="DestinationPath" />
<Value name="Contents" />
</DSC>
</DeclaredConfigurationResult>
</Data>
</Item>
</Results>
```
Abandoning a resource occurs when certain resources are no longer targeted to a user or group. Instead of deleting the resource on the device, the server can choose to abandon the WinDC document. An abandoned resource stays on the device but stops refreshing the WinDC document that handles drift control. Also the [resource ownership](../declared-configuration-resource-access.md#resource-ownership) is transferred to MDM, which means the same resource can be modified via legacy MDM channel again.
- Replace a configuration or inventory request
This example demonstrates how to abandon a WinDC document, by setting the **Abandoned** property to **1**.
```xml
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Replace>
<CmdID>14</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/Inventory/Documents/27FEA311-68B9-4320-9FC4-296F6FDFAFE2/Document</LocURI>
</Target>
<Data>
<![CDATA[<DeclaredConfiguration schema="1.0" context="Device" id="27FEA311-68B9-4320-9FC4-296F6FDFAFE2" checksum="99995209110918B67FE962460137AA3440AFF4DB6ABBE15C8F49968245799999" osdefinedscenario="MSFTExtensibilityMIProviderInventory">
<DSC namespace="root/Microsoft/Windows/DesiredStateConfiguration" className="MSFT_FileDirectoryConfiguration">
<Key name="DestinationPath">c:/temp/foobar.tmp</Key>
<Value name="Contents"></Value>
</DSC>
</DeclaredConfiguration>]]>
</Data>
</Item>
</Replace>
<Final />
</SyncBody>
</SyncML>
```
```xml
<Status>
<CmdID>2</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>2</CmdRef>
<Cmd>Get</Cmd>
<Data>200</Data>
</Status><Results>
<CmdID>3</CmdID>
<MsgRef>1</MsgRef>
<CmdRef>2</CmdRef>
<Item>
<Source>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/Inventory/Results/99998660-9080-3433-96e8-f32e85019999/Document</LocURI>
</Source>
<Data>
<DeclaredConfigurationResult context="Device" schema="1.0" id="27FEA311-68B9-4320-9FC4-296F6FDFAFE2" osdefinedscenario="MSFTExtensibilityMIProviderInventory" checksum="99995209110918B67FE962460137AA3440AFF4DB6ABBE15C8F49968245799999" result_checksum="A27B0D234CBC2FAC1292F1E8FBDF6A90690F3988DEDC9D716829856C9ACE0E20" operation="Get" state="80">
<DSC namespace="root/Microsoft/Windows/DesiredStateConfiguration" className="MSFT_FileDirectoryConfiguration" status="200" state="80">
<Key name="DestinationPath">c:/temp/foobar.tmp</Key>
<Value name="Contents">TestFileContent</Value>
</DSC>
</DeclaredConfigurationResult>
</Data>
</Item>
</Results>
```
- Abandon a configuration or inventory request. This process results in the client tracking the document but not reapplying it. The alert has the `Abandoned` property set to `1`, which indicates that the document is no longer managed by the declared configuration server.
```xml
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Meta>
```xml
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Replace>
<CmdID>2</CmdID>
<Item>
<Meta>
<Format>int</Format>
<Type>text/plain</Type>
</Meta>
<Target>
</Meta>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Documents/27FEA311-68B9-4320-9FC4-296F6FDFAFE2/Properties/Abandoned</LocURI>
</Target>
<Data>1</Data>
</Target>
<Data>1</Data>
</Item>
</Replace>
<Final/>
</SyncBody>
</SyncML>
```
### Unabandon a WinDC document
Unabandoning the document causes the document to be applied right away, transferring the [resource ownership](../declared-configuration-resource-access.md#resource-ownership) back to WinDC management and blocking legacy MDM channel from managing the channels again.
This example demonstrates how to unabandon a WinDC document, by setting the **Abandoned** property to **0**.
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Replace>
<CmdID>10</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Documents/DCA000B5-397D-40A1-AABF-40B25078A7F9/Properties/Abandoned</LocURI>
</Target>
<Meta>
<Format xmlns="syncml:metinf">int</Format>
</Meta>
<Data>0</Data>
</Item>
</Replace>
<Final />
</SyncBody>
</SyncML>
```
### Delete a WinDC document
The SyncML deletion of the document only removes the document but any settings persist on the device. This example demonstrates how to delete a document.
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Delete>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Documents/27FEA311-68B9-4320-9FC4-296F6FDFAFE2/Document</LocURI>
</Target>
</Item>
</Replace>
</Delete>
<Final/>
</SyncBody>
</SyncML>
```
- Deletion of configuration or inventory request. The SyncML deletion of the document only removes the document but any extensibility settings persist on the device (tattoo).
```xml
<?xml version="1.0" encoding="utf-8"?>
<SyncML xmlns="SYNCML:SYNCML1.1">
<SyncBody>
<Delete>
<CmdID>2</CmdID>
<Item>
<Target>
<LocURI>./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Documents/27FEA311-68B9-4320-9FC4-296F6FDFAFE2/Document</LocURI>
</Target>
</Item>
</Delete>
<Final/>
</SyncBody>
</SyncML>
```
</SyncML>
```
<!-- DeclaredConfiguration-CspMoreInfo-End -->
<!-- DeclaredConfiguration-End -->

16
windows/client-management/mdm/enterprisemodernappmanagement-csp.md
View File

@ -1,7 +1,7 @@
---
title: EnterpriseModernAppManagement CSP
description: Learn more about the EnterpriseModernAppManagement CSP.
ms.date: 04/10/2024
ms.date: 09/11/2024
---
<!-- Auto-Generated CSP Document -->
@ -381,7 +381,7 @@ This is a required node. The following list shows the supported deployment optio
- ForceUpdateToAnyVersion
- DeferRegistration="1". If the app is in use at the time of installation. This option stages the files for an app update and completes the registration of the app update after the app closes. Available in the latest insider flight of 20H1.
- StageOnly="1". Stages the files for an app installation or update without installing the app. Available in 1803.
- LicenseUri="\\server\license.lic". Deploys an offline license from the Microsoft Store for Business. Available in 1607.
- LicenseUri="\\server\license.lic". Deploys an offline license. Available in 1607.
- ValidateDependencies="1". This option is used at provisioning/staging time. If it's set to 1, deployment will perform the same dependency validation during staging that we would normally do at registration time, failing and rejecting the provision request if the dependencies aren't present. Available in the latest insider flight of 20H1.
- ExcludeAppFromLayoutModification="1". Sets that the app will be provisioned on all devices and will be able to retain the apps provisioned without pinning them to start layout. Available in 1809.
<!-- Device-AppInstallation-{PackageFamilyName}-HostedInstall-Editable-End -->
@ -821,7 +821,7 @@ This is a required node.
<!-- Device-AppLicenses-StoreLicenses-{LicenseID}-LicenseCategory-Description-Begin -->
<!-- Description-Source-DDF -->
Category of license that's used to classify various license sources. Valid value: Unknown - unknown license category. Retail - license sold through retail channels, typically from the Microsoft Store. Enterprise - license sold through the enterprise sales channel, typically from the Store for Business. OEM - license issued to an OEM. Developer - developer license, typically installed during the app development or side-loading scenarios.
Category of license that's used to classify various license sources. Valid value: Unknown - unknown license category. Retail - license sold through retail channels, typically from the Microsoft Store. Enterprise - license sold through the enterprise sales channel. OEM - license issued to an OEM. Developer - developer license, typically installed during the app development or side-loading scenarios.
<!-- Device-AppLicenses-StoreLicenses-{LicenseID}-LicenseCategory-Description-End -->
<!-- Device-AppLicenses-StoreLicenses-{LicenseID}-LicenseCategory-Editable-Begin -->
@ -904,6 +904,8 @@ Identifier for the entity that requested the license, such as the client who acq
<!-- Device-AppLicenses-StoreLicenses-{LicenseID}-RequesterID-Editable-Begin -->
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
> [!NOTE]
> The Microsoft Store for Business and Microsoft Store for Education are retired. For more information, see [Microsoft Store for Business and Education retiring March 31, 2023](/lifecycle/announcements/microsoft-store-for-business-education-retiring).
<!-- Device-AppLicenses-StoreLicenses-{LicenseID}-RequesterID-Editable-End -->
<!-- Device-AppLicenses-StoreLicenses-{LicenseID}-RequesterID-DFProperties-Begin -->
@ -992,6 +994,8 @@ This is a required node. Query parameters:
- Source - specifies the app classification that aligns to the existing inventory nodes. You can use a specific filter or if no filter is specified then all sources will be returned. If no value is specified, all classifications are returned. Valid values are:
- AppStore - This classification is for apps that were acquired from Microsoft Store. These were apps directly installed from Microsoft Store or enterprise apps from Microsoft Store for Business.
> [!NOTE]
> The Microsoft Store for Business and Microsoft Store for Education are retired. For more information, see [Microsoft Store for Business and Education retiring March 31, 2023](/lifecycle/announcements/microsoft-store-for-business-education-retiring).
- nonStore - This classification is for apps that weren't acquired from the Microsoft Store.
- System - Apps that are part of the OS. You can't uninstall these apps. This classification is read-only and can only be inventoried.
@ -5464,7 +5468,7 @@ This is a required node. The following list shows the supported deployment optio
- ForceUpdateToAnyVersion
- DeferRegistration="1". If the app is in use at the time of installation. This option stages the files for an app update and completes the registration of the app update after the app closes. Available in the latest insider flight of 20H1.
- StageOnly="1". Stages the files for an app installation or update without installing the app. Available in 1803.
- LicenseUri="\\server\license.lic". Deploys an offline license from the Microsoft Store for Business. Available in 1607.
- LicenseUri="\\server\license.lic". Deploys an offline license. Available in 1607.
- ValidateDependencies="1". This option is used at provisioning/staging time. If it's set to 1, deployment will perform the same dependency validation during staging that we would normally do at registration time, failing and rejecting the provision request if the dependencies aren't present. Available in the latest insider flight of 20H1.
- ExcludeAppFromLayoutModification="1". Sets that the app will be provisioned on all devices and will be able to retain the apps provisioned without pinning them to start layout. Available in 1809.
<!-- User-AppInstallation-{PackageFamilyName}-HostedInstall-Editable-End -->
@ -5903,7 +5907,7 @@ This is a required node.
<!-- User-AppLicenses-StoreLicenses-{LicenseID}-LicenseCategory-Description-Begin -->
<!-- Description-Source-DDF -->
Category of license that's used to classify various license sources. Valid value: Unknown - unknown license category. Retail - license sold through retail channels, typically from the Microsoft Store. Enterprise - license sold through the enterprise sales channel, typically from the Store for Business. OEM - license issued to an OEM. Developer - developer license, typically installed during the app development or side-loading scenarios.
Category of license that's used to classify various license sources. Valid value: Unknown - unknown license category. Retail - license sold through retail channels, typically from the Microsoft Store. Enterprise - license sold through the enterprise sales channel. OEM - license issued to an OEM. Developer - developer license, typically installed during the app development or side-loading scenarios.
<!-- User-AppLicenses-StoreLicenses-{LicenseID}-LicenseCategory-Description-End -->
<!-- User-AppLicenses-StoreLicenses-{LicenseID}-LicenseCategory-Editable-Begin -->
@ -5986,6 +5990,8 @@ Identifier for the entity that requested the license, such as the client who acq
<!-- User-AppLicenses-StoreLicenses-{LicenseID}-RequesterID-Editable-Begin -->
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
> [!NOTE]
> The Microsoft Store for Business and Microsoft Store for Education are retired. For more information, see [Microsoft Store for Business and Education retiring March 31, 2023](/lifecycle/announcements/microsoft-store-for-business-education-retiring).
<!-- User-AppLicenses-StoreLicenses-{LicenseID}-RequesterID-Editable-End -->
<!-- User-AppLicenses-StoreLicenses-{LicenseID}-RequesterID-DFProperties-Begin -->

2
windows/client-management/mdm/enterprisemodernappmanagement-ddf.md
View File

@ -1,7 +1,7 @@
---
title: EnterpriseModernAppManagement DDF file
description: View the XML file containing the device description framework (DDF) for the EnterpriseModernAppManagement configuration service provider.
ms.date: 06/28/2024
ms.date: 09/11/2024
---
<!-- Auto-Generated CSP Document -->

4
windows/client-management/mdm/policies-in-preview.md
View File

@ -1,7 +1,7 @@
---
title: Configuration service provider preview policies
description: Learn more about configuration service provider (CSP) policies that are available for Windows Insider Preview.
ms.date: 08/07/2024
ms.date: 09/11/2024
---
<!-- Auto-Generated CSP Document -->
@ -164,7 +164,7 @@ This article lists the policies that are applicable for Windows Insider Preview
- [SystemCryptography_ForceStrongKeyProtection](policy-csp-localpoliciessecurityoptions.md#systemcryptography_forcestrongkeyprotection)
- [SystemObjects_RequireCaseInsensitivityForNonWindowsSubsystems](policy-csp-localpoliciessecurityoptions.md#systemobjects_requirecaseinsensitivityfornonwindowssubsystems)
- [SystemObjects_StrengthenDefaultPermissionsOfInternalSystemObjects](policy-csp-localpoliciessecurityoptions.md#systemobjects_strengthendefaultpermissionsofinternalsystemobjects)
- [UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators](policy-csp-localpoliciessecurityoptions.md#useraccountcontrol_behavioroftheelevationpromptforenhancedadministrators)
- [UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection](policy-csp-localpoliciessecurityoptions.md#useraccountcontrol_behavioroftheelevationpromptforadministratorprotection)
- [UserAccountControl_TypeOfAdminApprovalMode](policy-csp-localpoliciessecurityoptions.md#useraccountcontrol_typeofadminapprovalmode)
## MixedReality

7
windows/client-management/mdm/policy-csp-applicationdefaults.md
View File

@ -1,7 +1,7 @@
---
title: ApplicationDefaults Policy CSP
description: Learn more about the ApplicationDefaults Area in Policy CSP.
ms.date: 01/18/2024
ms.date: 09/11/2024
---
<!-- Auto-Generated CSP Document -->
@ -31,13 +31,12 @@ ms.date: 01/18/2024
<!-- DefaultAssociationsConfiguration-Description-Begin -->
<!-- Description-Source-DDF-Forced -->
This policy allows an administrator to set default file type and protocol associations. When set, default associations will be applied on sign-in to the PC. The association file can be created using the DISM tool (dism /online /export-defaultappassociations:appassoc.xml). The file can be further edited by adding attributes to control how often associations are applied by the policy. The file then needs to be base64 encoded before being added to SyncML. If policy is enabled and the client machine is Microsoft Entra joined, the associations assigned in SyncML will be processed and default associations will be applied.
> [!NOTE]
> For this policy, MDM policy take precedence over group policies even when [MDMWinsOverGP](policy-csp-controlpolicyconflict.md#mdmwinsovergp) policy is not set.
<!-- DefaultAssociationsConfiguration-Description-End -->
<!-- DefaultAssociationsConfiguration-Editable-Begin -->
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
> [!NOTE]
> For this policy, MDM policy take precedence over group policies even when [MDMWinsOverGP](policy-csp-controlpolicyconflict.md#mdmwinsovergp) policy is not set.
<!-- DefaultAssociationsConfiguration-Editable-End -->
<!-- DefaultAssociationsConfiguration-DFProperties-Begin -->

4
windows/client-management/mdm/policy-csp-browser.md
View File

@ -1,7 +1,7 @@
---
title: Browser Policy CSP
description: Learn more about the Browser Area in Policy CSP.
ms.date: 04/10/2024
ms.date: 09/11/2024
---
<!-- Auto-Generated CSP Document -->
@ -3364,9 +3364,7 @@ You can define a list of extensions in Microsoft Edge that users cannot turn off
Related Documents:
- [Find a package family name (PFN) for per-app VPN](/mem/configmgr/protect/deploy-use/find-a-pfn-for-per-app-vpn)
- [How to manage volume purchased apps from the Microsoft Store for Business with Microsoft Intune](/mem/intune/apps/windows-store-for-business)
- [Assign apps to groups with Microsoft Intune](/mem/intune/apps/apps-deploy)
- [Manage apps from the Microsoft Store for Business and Education with Configuration Manager](/mem/configmgr/apps/deploy-use/manage-apps-from-the-windows-store-for-business)
- [Add a Windows line-of-business app to Microsoft Intune](/mem/intune/apps/lob-apps-windows)
<!-- PreventTurningOffRequiredExtensions-Editable-End -->

315
windows/client-management/mdm/policy-csp-localpoliciessecurityoptions.md
View File

@ -1,7 +1,7 @@
---
title: LocalPoliciesSecurityOptions Policy CSP
description: Learn more about the LocalPoliciesSecurityOptions Area in Policy CSP.
ms.date: 01/31/2024
ms.date: 09/11/2024
---
<!-- Auto-Generated CSP Document -->
@ -96,7 +96,7 @@ This policy setting prevents users from adding new Microsoft accounts on this co
This security setting determines whether the local Administrator account is enabled or disabled.
> [!NOTE]
> If you try to reenable the Administrator account after it has been disabled, and if the current Administrator password doesn't meet the password requirements, you can't reenable the account. In this case, an alternative member of the Administrators group must reset the password on the Administrator account. For information about how to reset a password, see To reset a password. Disabling the Administrator account can become a maintenance issue under certain circumstances. Under Safe Mode boot, the disabled Administrator account will only be enabled if the machine is non-domain joined and there are no other local active administrator accounts. If the computer is domain joined the disabled administrator won't be enabled. Default: Disabled.
> If you try to reenable the Administrator account after it has been disabled, and if the current Administrator password doesn't meet the password requirements, you can't reenable the account. In this case, an alternative member of the Administrators group must reset the password on the Administrator account. For information about how to reset a password, see To reset a password. Disabling the Administrator account can become a maintenance issue under certain circumstances. Under Safe Mode boot, the disabled Administrator account will only be enabled if the machine is non-domain joined and there are no other local active administrator accounts. If the computer is domain joined the disabled administrator won't be enabled.
<!-- Accounts_EnableAdministratorAccountStatus-Description-End -->
<!-- Accounts_EnableAdministratorAccountStatus-Editable-Begin -->
@ -154,10 +154,7 @@ This security setting determines whether the local Administrator account is enab
<!-- Accounts_EnableGuestAccountStatus-Description-Begin -->
<!-- Description-Source-DDF -->
This security setting determines if the Guest account is enabled or disabled. Default: Disabled.
> [!NOTE]
> If the Guest account is disabled and the security option Network Access: Sharing and Security Model for local accounts is set to Guest Only, network logons, such as those performed by the Microsoft Network Server (SMB Service), will fail.
This security setting determines if the Guest account is enabled or disabled. Note: If the Guest account is disabled and the security option Network Access: Sharing and Security Model for local accounts is set to Guest Only, network logons, such as those performed by the Microsoft Network Server (SMB Service), will fail.
<!-- Accounts_EnableGuestAccountStatus-Description-End -->
<!-- Accounts_EnableGuestAccountStatus-Editable-Begin -->
@ -215,10 +212,7 @@ This security setting determines if the Guest account is enabled or disabled. De
<!-- Accounts_LimitLocalAccountUseOfBlankPasswordsToConsoleLogonOnly-Description-Begin -->
<!-- Description-Source-DDF -->
Accounts: Limit local account use of blank passwords to console logon only This security setting determines whether local accounts that aren't password protected can be used to log on from locations other than the physical computer console. If enabled, local accounts that aren't password protected will only be able to log on at the computer's keyboard. Default: Enabled.
> [!WARNING]
> Computers that aren't in physically secure locations should always enforce strong password policies for all local user accounts. Otherwise, anyone with physical access to the computer can log on by using a user account that doesn't have a password. This is especially important for portable computers. If you apply this security policy to the Everyone group, no one will be able to log on through Remote Desktop Services.
Accounts: Limit local account use of blank passwords to console logon only This security setting determines whether local accounts that aren't password protected can be used to log on from locations other than the physical computer console. If enabled, local accounts that aren't password protected will only be able to log on at the computer's keyboard. Warning: Computers that aren't in physically secure locations should always enforce strong password policies for all local user accounts. Otherwise, anyone with physical access to the computer can log on by using a user account that doesn't have a password. This is especially important for portable computers. If you apply this security policy to the Everyone group, no one will be able to log on through Remote Desktop Services.
> [!NOTE]
> This setting doesn't affect logons that use domain accounts. It's possible for applications that use remote interactive logons to bypass this setting.
@ -380,7 +374,7 @@ Accounts: Rename guest account This security setting determines whether a differ
Audit: Audit the use of Backup and Restore privilege This security setting determines whether to audit the use of all user privileges, including Backup and Restore, when the Audit privilege use policy is in effect. Enabling this option when the Audit privilege use policy is also enabled generates an audit event for every file that's backed up or restored. If you disable this policy, then use of the Backup or Restore privilege isn't audited even when Audit privilege use is enabled.
> [!NOTE]
> On Windows versions prior to Windows Vista configuring this security setting, changes won't take effect until you restart Windows. Enabling this setting can cause a LOT of events, sometimes hundreds per second, during a backup operation. Default: Disabled.
> On Windows versions prior to Windows Vista configuring this security setting, changes won't take effect until you restart Windows. Enabling this setting can cause a LOT of events, sometimes hundreds per second, during a backup operation.
<!-- Audit_AuditTheUseOfBackupAndRestoreprivilege-Description-End -->
<!-- Audit_AuditTheUseOfBackupAndRestoreprivilege-Editable-Begin -->
@ -465,7 +459,7 @@ Audit: Force audit policy subcategory settings (Windows Vista or later) to overr
Audit: Shut down system immediately if unable to log security audits This security setting determines whether the system shuts down if it's unable to log security events. If this security setting is enabled, it causes the system to stop if a security audit can't be logged for any reason. Typically, an event fails to be logged when the security audit log is full and the retention method that's specified for the security log is either Do Not Overwrite Events or Overwrite Events by Days. If the security log is full and an existing entry can't be overwritten, and this security option is enabled, the following Stop error appears: STOP: C0000244 {Audit Failed} An attempt to generate a security audit failed. To recover, an administrator must log on, archive the log (optional), clear the log, and reset this option as desired. Until this security setting is reset, no users, other than a member of the Administrators group will be able to log on to the system, even if the security log isn't full.
> [!NOTE]
> On Windows versions prior to Windows Vista configuring this security setting, changes won't take effect until you restart Windows. Default: Disabled.
> On Windows versions prior to Windows Vista configuring this security setting, changes won't take effect until you restart Windows.
<!-- Audit_ShutdownSystemImmediatelyIfUnableToLogSecurityAudits-Description-End -->
<!-- Audit_ShutdownSystemImmediatelyIfUnableToLogSecurityAudits-Editable-Begin -->
@ -555,7 +549,11 @@ Devices: Allowed to format and eject removable media This security setting deter
<!-- Devices_AllowUndockWithoutHavingToLogon-Description-Begin -->
<!-- Description-Source-DDF -->
Devices: Allow undock without having to log on This security setting determines whether a portable computer can be undocked without having to log on. If this policy is enabled, logon isn't required and an external hardware eject button can be used to undock the computer. If disabled, a user must log on and have the Remove computer from docking station privilege to undock the computer. Default: Enabled.
Devices: Allow undock without having to log on This security setting determines whether a portable computer can be undocked without having to log on.
- If this policy is enabled, logon isn't required and an external hardware eject button can be used to undock the computer.
- If disabled, a user must log on and have the Remove computer from docking station privilege to undock the computer.
> [!CAUTION]
> Disabling this policy may tempt users to try and physically remove the laptop from its docking station using methods other than the external hardware eject button. Since this may cause damage to the hardware, this setting, in general, should only be disabled on laptop configurations that are physically securable.
@ -678,7 +676,11 @@ Devices: Prevent users from installing printer drivers when connecting to shared
<!-- Devices_RestrictCDROMAccessToLocallyLoggedOnUserOnly-Description-Begin -->
<!-- Description-Source-DDF -->
Devices: Restrict CD-ROM access to locally logged-on user only This security setting determines whether a CD-ROM is accessible to both local and remote users simultaneously. If this policy is enabled, it allows only the interactively logged-on user to access removable CD-ROM media. If this policy is enabled and no one is logged-on interactively, the CD-ROM can be accessed over the network. Default: This policy isn't defined and CD-ROM access isn't restricted to the locally logged-on user.
Devices: Restrict CD-ROM access to locally logged-on user only This security setting determines whether a CD-ROM is accessible to both local and remote users simultaneously.
- If this policy is enabled, it allows only the interactively logged-on user to access removable CD-ROM media.
- If this policy is enabled and no one is logged-on interactively, the CD-ROM can be accessed over the network. Default: This policy isn't defined and CD-ROM access isn't restricted to the locally logged-on user.
<!-- Devices_RestrictCDROMAccessToLocallyLoggedOnUserOnly-Description-End -->
<!-- Devices_RestrictCDROMAccessToLocallyLoggedOnUserOnly-Editable-Begin -->
@ -727,7 +729,11 @@ Devices: Restrict CD-ROM access to locally logged-on user only This security set
<!-- Devices_RestrictFloppyAccessToLocallyLoggedOnUserOnly-Description-Begin -->
<!-- Description-Source-DDF -->
Devices: Restrict floppy access to locally logged-on user only This security setting determines whether removable floppy media are accessible to both local and remote users simultaneously. If this policy is enabled, it allows only the interactively logged-on user to access removable floppy media. If this policy is enabled and no one is logged-on interactively, the floppy can be accessed over the network. Default: This policy isn't defined and floppy disk drive access isn't restricted to the locally logged-on user.
Devices: Restrict floppy access to locally logged-on user only This security setting determines whether removable floppy media are accessible to both local and remote users simultaneously.
- If this policy is enabled, it allows only the interactively logged-on user to access removable floppy media.
- If this policy is enabled and no one is logged-on interactively, the floppy can be accessed over the network. Default: This policy isn't defined and floppy disk drive access isn't restricted to the locally logged-on user.
<!-- Devices_RestrictFloppyAccessToLocallyLoggedOnUserOnly-Description-End -->
<!-- Devices_RestrictFloppyAccessToLocallyLoggedOnUserOnly-Editable-Begin -->
@ -776,10 +782,11 @@ Devices: Restrict floppy access to locally logged-on user only This security set
<!-- DomainMember_DigitallyEncryptOrSignSecureChannelDataAlways-Description-Begin -->
<!-- Description-Source-DDF -->
Domain member: Digitally encrypt or sign secure channel data (always) This security setting determines whether all secure channel traffic initiated by the domain member must be signed or encrypted. When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM pass through authentication, LSA SID/name Lookup etc. This setting determines whether or not all secure channel traffic initiated by the domain member meets minimum security requirements. Specifically it determines whether all secure channel traffic initiated by the domain member must be signed or encrypted. If this policy is enabled, then the secure channel won't be established unless either signing or encryption of all secure channel traffic is negotiated. If this policy is disabled, then encryption and signing of all secure channel traffic is negotiated with the Domain Controller in which case the level of signing and encryption depends on the version of the Domain Controller and the settings of the following two policies: Domain member: Digitally encrypt secure channel data (when possible) Domain member: Digitally sign secure channel data (when possible) Default: Enabled.
Domain member: Digitally encrypt or sign secure channel data (always) This security setting determines whether all secure channel traffic initiated by the domain member must be signed or encrypted. When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM pass through authentication, LSA SID/name Lookup etc. This setting determines whether or not all secure channel traffic initiated by the domain member meets minimum security requirements. Specifically it determines whether all secure channel traffic initiated by the domain member must be signed or encrypted.
> [!NOTE]
> If this policy is enabled, the policy Domain member: Digitally sign secure channel data (when possible) is assumed to be enabled regardless of its current setting. This ensures that the domain member attempts to negotiate at least signing of the secure channel traffic. Logon information transmitted over the secure channel is always encrypted regardless of whether encryption of ALL other secure channel traffic is negotiated or not.
- If this policy is enabled, then the secure channel won't be established unless either signing or encryption of all secure channel traffic is negotiated.
- If this policy is disabled, then encryption and signing of all secure channel traffic is negotiated with the Domain Controller in which case the level of signing and encryption depends on the version of the Domain Controller and the settings of the following two policies: Domain member: Digitally encrypt secure channel data (when possible) Domain member: Digitally sign secure channel data (when possible) Notes: If this policy is enabled, the policy Domain member: Digitally sign secure channel data (when possible) is assumed to be enabled regardless of its current setting. This ensures that the domain member attempts to negotiate at least signing of the secure channel traffic. Logon information transmitted over the secure channel is always encrypted regardless of whether encryption of ALL other secure channel traffic is negotiated or not.
<!-- DomainMember_DigitallyEncryptOrSignSecureChannelDataAlways-Description-End -->
<!-- DomainMember_DigitallyEncryptOrSignSecureChannelDataAlways-Editable-Begin -->
@ -829,10 +836,7 @@ Domain member: Digitally encrypt or sign secure channel data (always) This secur
<!-- DomainMember_DigitallyEncryptSecureChannelDataWhenPossible-Description-Begin -->
<!-- Description-Source-DDF -->
Domain member: Digitally encrypt secure channel data (when possible) This security setting determines whether a domain member attempts to negotiate encryption for all secure channel traffic that it initiates. When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM pass-through authentication, LSA SID/name Lookup etc. This setting determines whether or not the domain member attempts to negotiate encryption for all secure channel traffic that it initiates. If enabled, the domain member will request encryption of all secure channel traffic. If the domain controller supports encryption of all secure channel traffic, then all secure channel traffic will be encrypted. Otherwise only logon information transmitted over the secure channel will be encrypted. If this setting is disabled, then the domain member won't attempt to negotiate secure channel encryption. Default: Enabled.
> [!IMPORTANT]
> There is no known reason for disabling this setting. Besides unnecessarily reducing the potential confidentiality level of the secure channel, disabling this setting may unnecessarily reduce secure channel throughput, because concurrent API calls that use the secure channel are only possible when the secure channel is signed or encrypted.
Domain member: Digitally encrypt secure channel data (when possible) This security setting determines whether a domain member attempts to negotiate encryption for all secure channel traffic that it initiates. When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM pass-through authentication, LSA SID/name Lookup etc. This setting determines whether or not the domain member attempts to negotiate encryption for all secure channel traffic that it initiates. If enabled, the domain member will request encryption of all secure channel traffic. If the domain controller supports encryption of all secure channel traffic, then all secure channel traffic will be encrypted. Otherwise only logon information transmitted over the secure channel will be encrypted. If this setting is disabled, then the domain member won't attempt to negotiate secure channel encryption. Important There is no known reason for disabling this setting. Besides unnecessarily reducing the potential confidentiality level of the secure channel, disabling this setting may unnecessarily reduce secure channel throughput, because concurrent API calls that use the secure channel are only possible when the secure channel is signed or encrypted.
> [!NOTE]
> Domain controllers are also domain members and establish secure channels with other domain controllers in the same domain as well as domain controllers in trusted domains.
@ -885,7 +889,7 @@ Domain member: Digitally encrypt secure channel data (when possible) This securi
<!-- DomainMember_DigitallySignSecureChannelDataWhenPossible-Description-Begin -->
<!-- Description-Source-DDF -->
Domain member: Digitally sign secure channel data (when possible) This security setting determines whether a domain member attempts to negotiate signing for all secure channel traffic that it initiates. When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM pass through authentication, LSA SID/name Lookup etc. This setting determines whether or not the domain member attempts to negotiate signing for all secure channel traffic that it initiates. If enabled, the domain member will request signing of all secure channel traffic. If the Domain Controller supports signing of all secure channel traffic, then all secure channel traffic will be signed which ensures that it can't be tampered with in transit. Default: Enabled.
Domain member: Digitally sign secure channel data (when possible) This security setting determines whether a domain member attempts to negotiate signing for all secure channel traffic that it initiates. When a computer joins a domain, a computer account is created. After that, when the system starts, it uses the computer account password to create a secure channel with a domain controller for its domain. This secure channel is used to perform operations such as NTLM pass through authentication, LSA SID/name Lookup etc. This setting determines whether or not the domain member attempts to negotiate signing for all secure channel traffic that it initiates. If enabled, the domain member will request signing of all secure channel traffic. If the Domain Controller supports signing of all secure channel traffic, then all secure channel traffic will be signed which ensures that it can't be tampered with in transit.
<!-- DomainMember_DigitallySignSecureChannelDataWhenPossible-Description-End -->
<!-- DomainMember_DigitallySignSecureChannelDataWhenPossible-Editable-Begin -->
@ -939,10 +943,7 @@ Domain member: Disable machine account password changes Determines whether a dom
- If this setting is enabled, the domain member doesn't attempt to change its computer account password.
- If this setting is disabled, the domain member attempts to change its computer account password as specified by the setting for Domain Member: Maximum age for machine account password, which by default is every 30 days. Default: Disabled.
> [!NOTE]
> This security setting shouldn't be enabled. Computer account passwords are used to establish secure channel communications between members and domain controllers and, within the domain, between the domain controllers themselves. Once it's established, the secure channel is used to transmit sensitive information that's necessary for making authentication and authorization decisions. This setting shouldn't be used in an attempt to support dual-boot scenarios that use the same computer account. If you want to dual-boot two installations that are joined to the same domain, give the two installations different computer names.
- If this setting is disabled, the domain member attempts to change its computer account password as specified by the setting for Domain Member: Maximum age for machine account password, which by default is every 30 days. Notes This security setting shouldn't be enabled. Computer account passwords are used to establish secure channel communications between members and domain controllers and, within the domain, between the domain controllers themselves. Once it's established, the secure channel is used to transmit sensitive information that's necessary for making authentication and authorization decisions. This setting shouldn't be used in an attempt to support dual-boot scenarios that use the same computer account. If you want to dual-boot two installations that are joined to the same domain, give the two installations different computer names.
<!-- DomainMember_DisableMachineAccountPasswordChanges-Description-End -->
<!-- DomainMember_DisableMachineAccountPasswordChanges-Editable-Begin -->
@ -1049,10 +1050,7 @@ Domain member: Require strong (Windows 2000 or later) session key This security
- If this setting is enabled, then the secure channel won't be established unless 128-bit encryption can be performed.
- If this setting is disabled, then the key strength is negotiated with the domain controller. Default: Enabled.
> [!IMPORTANT]
> In order to take advantage of this policy on member workstations and servers, all domain controllers that constitute the member's domain must be running Windows 2000 or later. In order to take advantage of this policy on domain controllers, all domain controllers in the same domain as well as all trusted domains must run Windows 2000 or later.
- If this setting is disabled, then the key strength is negotiated with the domain controller. Important In order to take advantage of this policy on member workstations and servers, all domain controllers that constitute the member's domain must be running Windows 2000 or later. In order to take advantage of this policy on domain controllers, all domain controllers in the same domain as well as all trusted domains must run Windows 2000 or later.
<!-- DomainMember_RequireStrongSessionKey-Description-End -->
<!-- DomainMember_RequireStrongSessionKey-Editable-Begin -->
@ -1162,7 +1160,11 @@ Interactive Logon:Display user information when the session is locked User displ
<!-- InteractiveLogon_DoNotDisplayLastSignedIn-Description-Begin -->
<!-- Description-Source-DDF -->
Interactive logon: Don't display last signed-in This security setting determines whether the Windows sign-in screen will show the username of the last person who signed in on this PC. If this policy is enabled, the username won't be shown. If this policy is disabled, the username will be shown. Default: Disabled.
Interactive logon: Don't display last signed-in This security setting determines whether the Windows sign-in screen will show the username of the last person who signed in on this PC.
- If this policy is enabled, the username won't be shown.
- If this policy is disabled, the username will be shown.
<!-- InteractiveLogon_DoNotDisplayLastSignedIn-Description-End -->
<!-- InteractiveLogon_DoNotDisplayLastSignedIn-Editable-Begin -->
@ -1220,7 +1222,11 @@ Interactive logon: Don't display last signed-in This security setting determines
<!-- InteractiveLogon_DoNotDisplayUsernameAtSignIn-Description-Begin -->
<!-- Description-Source-DDF -->
Interactive logon: Don't display username at sign-in This security setting determines whether the username of the person signing in to this PC appears at Windows sign-in, after credentials are entered, and before the PC desktop is shown. If this policy is enabled, the username won't be shown. If this policy is disabled, the username will be shown. Default: Disabled.
Interactive logon: Don't display username at sign-in This security setting determines whether the username of the person signing in to this PC appears at Windows sign-in, after credentials are entered, and before the PC desktop is shown.
- If this policy is enabled, the username won't be shown.
- If this policy is disabled, the username will be shown.
<!-- InteractiveLogon_DoNotDisplayUsernameAtSignIn-Description-End -->
<!-- InteractiveLogon_DoNotDisplayUsernameAtSignIn-Editable-Begin -->
@ -1278,7 +1284,11 @@ Interactive logon: Don't display username at sign-in This security setting deter
<!-- InteractiveLogon_DoNotRequireCTRLALTDEL-Description-Begin -->
<!-- Description-Source-DDF -->
Interactive logon: Don't require CTRL+ALT+DEL This security setting determines whether pressing CTRL+ALT+DEL is required before a user can log on. If this policy is enabled on a computer, a user isn't required to press CTRL+ALT+DEL to log on. Not having to press CTRL+ALT+DEL leaves users susceptible to attacks that attempt to intercept the users' passwords. Requiring CTRL+ALT+DEL before users log on ensures that users are communicating by means of a trusted path when entering their passwords. If this policy is disabled, any user is required to press CTRL+ALT+DEL before logging on to Windows. Default on domain-computers: Enabled: At least Windows 8/Disabled: Windows 7 or earlier. Default on stand-alone computers: Enabled.
Interactive logon: Don't require CTRL+ALT+DEL This security setting determines whether pressing CTRL+ALT+DEL is required before a user can log on.
- If this policy is enabled on a computer, a user isn't required to press CTRL+ALT+DEL to log on. Not having to press CTRL+ALT+DEL leaves users susceptible to attacks that attempt to intercept the users' passwords. Requiring CTRL+ALT+DEL before users log on ensures that users are communicating by means of a trusted path when entering their passwords.
- If this policy is disabled, any user is required to press CTRL+ALT+DEL before logging on to Windows. Default on domain-computers: Enabled: At least Windows 8/Disabled: Windows 7 or earlier. Default on stand-alone computers: Enabled.
<!-- InteractiveLogon_DoNotRequireCTRLALTDEL-Description-End -->
<!-- InteractiveLogon_DoNotRequireCTRLALTDEL-Editable-Begin -->
@ -1684,10 +1694,7 @@ Microsoft network client: Digitally sign communications (always) This security s
- If this setting is enabled, the Microsoft network client won't communicate with a Microsoft network server unless that server agrees to perform SMB packet signing.
- If this policy is disabled, SMB packet signing is negotiated between the client and server. Default: Disabled.
> [!IMPORTANT]
> For this policy to take effect on computers running Windows 2000, client-side packet signing must also be enabled. To enable client-side SMB packet signing, set Microsoft network client: Digitally sign communications (if server agrees).
- If this policy is disabled, SMB packet signing is negotiated between the client and server. Important For this policy to take effect on computers running Windows 2000, client-side packet signing must also be enabled. To enable client-side SMB packet signing, set Microsoft network client: Digitally sign communications (if server agrees).
> [!NOTE]
> All Windows operating systems support both a client-side SMB component and a server-side SMB component. On Windows 2000 and later operating systems, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings: Microsoft network client: Digitally sign communications (always) - Controls whether or not the client-side SMB component requires packet signing. Microsoft network client: Digitally sign communications (if server agrees) - Controls whether or not the client-side SMB component has packet signing enabled. Microsoft network server: Digitally sign communications (always) - Controls whether or not the server-side SMB component requires packet signing. Microsoft network server: Digitally sign communications (if client agrees) - Controls whether or not the server-side SMB component has packet signing enabled. SMB packet signing can significantly degrade SMB performance, depending on dialect version, OS version, file sizes, processor offloading capabilities, and application IO behaviors. For more information, reference:< https://go.microsoft.com/fwlink/?LinkID=787136>.
@ -1752,10 +1759,7 @@ Microsoft network client: Digitally sign communications (if server agrees) This
- If this setting is enabled, the Microsoft network client will ask the server to perform SMB packet signing upon session setup. If packet signing has been enabled on the server, packet signing will be negotiated.
- If this policy is disabled, the SMB client will never negotiate SMB packet signing. Default: Enabled.
> [!NOTE]
> All Windows operating systems support both a client-side SMB component and a server-side SMB component. On Windows 2000 and later, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings: Microsoft network client: Digitally sign communications (always) - Controls whether or not the client-side SMB component requires packet signing. Microsoft network client: Digitally sign communications (if server agrees) - Controls whether or not the client-side SMB component has packet signing enabled. Microsoft network server: Digitally sign communications (always) - Controls whether or not the server-side SMB component requires packet signing. Microsoft network server: Digitally sign communications (if client agrees) - Controls whether or not the server-side SMB component has packet signing enabled. If both client-side and server-side SMB signing is enabled and the client establishes an SMB 1.0 connection to the server, SMB signing will be attempted. SMB packet signing can significantly degrade SMB performance, depending on dialect version, OS version, file sizes, processor offloading capabilities, and application IO behaviors. This setting only applies to SMB 1.0 connections. For more information, reference:< https://go.microsoft.com/fwlink/?LinkID=787136>.
- If this policy is disabled, the SMB client will never negotiate SMB packet signing. Notes All Windows operating systems support both a client-side SMB component and a server-side SMB component. On Windows 2000 and later, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings: Microsoft network client: Digitally sign communications (always) - Controls whether or not the client-side SMB component requires packet signing. Microsoft network client: Digitally sign communications (if server agrees) - Controls whether or not the client-side SMB component has packet signing enabled. Microsoft network server: Digitally sign communications (always) - Controls whether or not the server-side SMB component requires packet signing. Microsoft network server: Digitally sign communications (if client agrees) - Controls whether or not the server-side SMB component has packet signing enabled. If both client-side and server-side SMB signing is enabled and the client establishes an SMB 1.0 connection to the server, SMB signing will be attempted. SMB packet signing can significantly degrade SMB performance, depending on dialect version, OS version, file sizes, processor offloading capabilities, and application IO behaviors. This setting only applies to SMB 1.0 connections. For more information, reference:< https://go.microsoft.com/fwlink/?LinkID=787136>.
<!-- MicrosoftNetworkClient_DigitallySignCommunicationsIfServerAgrees-Description-End -->
<!-- MicrosoftNetworkClient_DigitallySignCommunicationsIfServerAgrees-Editable-Begin -->
@ -1813,7 +1817,7 @@ Microsoft network client: Digitally sign communications (if server agrees) This
<!-- MicrosoftNetworkClient_SendUnencryptedPasswordToThirdPartySMBServers-Description-Begin -->
<!-- Description-Source-DDF -->
Microsoft network client: Send unencrypted password to connect to third-party SMB servers If this security setting is enabled, the Server Message Block (SMB) redirector is allowed to send plaintext passwords to non-Microsoft SMB servers that don't support password encryption during authentication. Sending unencrypted passwords is a security risk. Default: Disabled.
Microsoft network client: Send unencrypted password to connect to third-party SMB servers If this security setting is enabled, the Server Message Block (SMB) redirector is allowed to send plaintext passwords to non-Microsoft SMB servers that don't support password encryption during authentication. Sending unencrypted passwords is a security risk.
<!-- MicrosoftNetworkClient_SendUnencryptedPasswordToThirdPartySMBServers-Description-End -->
<!-- MicrosoftNetworkClient_SendUnencryptedPasswordToThirdPartySMBServers-Editable-Begin -->
@ -1993,7 +1997,7 @@ Microsoft network server: Digitally sign communications (if client agrees) This
- If this setting is enabled, the Microsoft network server will negotiate SMB packet signing as requested by the client. That is, if packet signing has been enabled on the client, packet signing will be negotiated.
- If this policy is disabled, the SMB client will never negotiate SMB packet signing. Default: Enabled on domain controllers only.
- If this policy is disabled, the SMB client will never negotiate SMB packet signing. on domain controllers only.
> [!IMPORTANT]
> For Windows 2000 servers to negotiate signing with Windows NT 4.0 clients, the following registry value must be set to 1 on the server running Windows 2000: HKLM\System\CurrentControlSet\Services\lanmanserver\parameters\enableW9xsecuritysignature Notes All Windows operating systems support both a client-side SMB component and a server-side SMB component. For Windows 2000 and above, enabling or requiring packet signing for client and server-side SMB components is controlled by the following four policy settings: Microsoft network client: Digitally sign communications (always) - Controls whether or not the client-side SMB component requires packet signing. Microsoft network client: Digitally sign communications (if server agrees) - Controls whether or not the client-side SMB component has packet signing enabled. Microsoft network server: Digitally sign communications (always) - Controls whether or not the server-side SMB component requires packet signing. Microsoft network server: Digitally sign communications (if client agrees) - Controls whether or not the server-side SMB component has packet signing enabled. If both client-side and server-side SMB signing is enabled and the client establishes an SMB 1.0 connection to the server, SMB signing will be attempted. SMB packet signing can significantly degrade SMB performance, depending on dialect version, OS version, file sizes, processor offloading capabilities, and application IO behaviors. This setting only applies to SMB 1.0 connections. For more information, reference:< https://go.microsoft.com/fwlink/?LinkID=787136>.
@ -2054,7 +2058,9 @@ Microsoft network server: Digitally sign communications (if client agrees) This
<!-- MicrosoftNetworkServer_DisconnectClientsWhenLogonHoursExpire-Description-Begin -->
<!-- Description-Source-DDF -->
Microsoft network server: Disconnect clients when logon hours expire This security setting determines whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. This setting affects the Server Message Block (SMB) component. When this policy is enabled, it causes client sessions with the SMB Service to be forcibly disconnected when the client's logon hours expire. If this policy is disabled, an established client session is allowed to be maintained after the client's logon hours have expired. Default on Windows Vista and above: Enabled. Default on Windows XP: Disabled.
Microsoft network server: Disconnect clients when logon hours expire This security setting determines whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. This setting affects the Server Message Block (SMB) component. When this policy is enabled, it causes client sessions with the SMB Service to be forcibly disconnected when the client's logon hours expire.
- If this policy is disabled, an established client session is allowed to be maintained after the client's logon hours have expired. Default on Windows Vista and above: Enabled. Default on Windows XP: Disabled.
<!-- MicrosoftNetworkServer_DisconnectClientsWhenLogonHoursExpire-Description-End -->
<!-- MicrosoftNetworkServer_DisconnectClientsWhenLogonHoursExpire-Editable-Begin -->
@ -2259,7 +2265,7 @@ Network access: Don't allow anonymous enumeration of SAM accounts This security
<!-- NetworkAccess_DoNotAllowAnonymousEnumerationOfSamAccountsAndShares-Description-Begin -->
<!-- Description-Source-DDF -->
Network access: Don't allow anonymous enumeration of SAM accounts and shares This security setting determines whether anonymous enumeration of SAM accounts and shares is allowed. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that doesn't maintain a reciprocal trust. If you don't want to allow anonymous enumeration of SAM accounts and shares, then enable this policy. Default: Disabled.
Network access: Don't allow anonymous enumeration of SAM accounts and shares This security setting determines whether anonymous enumeration of SAM accounts and shares is allowed. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that doesn't maintain a reciprocal trust. If you don't want to allow anonymous enumeration of SAM accounts and shares, then enable this policy.
<!-- NetworkAccess_DoNotAllowAnonymousEnumerationOfSamAccountsAndShares-Description-End -->
<!-- NetworkAccess_DoNotAllowAnonymousEnumerationOfSamAccountsAndShares-Editable-Begin -->
@ -2324,7 +2330,7 @@ Network access: Don't allow storage of passwords and credentials for network aut
- If you disable or don't configure this policy setting, Credential Manager will store passwords and credentials on this computer for later use for domain authentication.
> [!NOTE]
> When configuring this security setting, changes won't take effect until you restart Windows. Default: Disabled.
> When configuring this security setting, changes won't take effect until you restart Windows.
<!-- NetworkAccess_DoNotAllowStorageOfPasswordsAndCredentialsForNetworkAuthentication-Description-End -->
<!-- NetworkAccess_DoNotAllowStorageOfPasswordsAndCredentialsForNetworkAuthentication-Editable-Begin -->
@ -2365,7 +2371,9 @@ Network access: Don't allow storage of passwords and credentials for network aut
<!-- NetworkAccess_LetEveryonePermissionsApplyToAnonymousUsers-Description-Begin -->
<!-- Description-Source-DDF -->
Network access: Let Everyone permissions apply to anonymous users This security setting determines what additional permissions are granted for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that doesn't maintain a reciprocal trust. By Default, the Everyone security identifier (SID) is removed from the token created for anonymous connections. Therefore, permissions granted to the Everyone group don't apply to anonymous users. If this option is set, anonymous users can only access those resources for which the anonymous user has been explicitly given permission. If this policy is enabled, the Everyone SID is added to the token that's created for anonymous connections. In this case, anonymous users are able to access any resource for which the Everyone group has been given permissions. Default: Disabled.
Network access: Let Everyone permissions apply to anonymous users This security setting determines what additional permissions are granted for anonymous connections to the computer. Windows allows anonymous users to perform certain activities, such as enumerating the names of domain accounts and network shares. This is convenient, for example, when an administrator wants to grant access to users in a trusted domain that doesn't maintain a reciprocal trust. By Default, the Everyone security identifier (SID) is removed from the token created for anonymous connections. Therefore, permissions granted to the Everyone group don't apply to anonymous users. If this option is set, anonymous users can only access those resources for which the anonymous user has been explicitly given permission.
- If this policy is enabled, the Everyone SID is added to the token that's created for anonymous connections. In this case, anonymous users are able to access any resource for which the Everyone group has been given permissions.
<!-- NetworkAccess_LetEveryonePermissionsApplyToAnonymousUsers-Description-End -->
<!-- NetworkAccess_LetEveryonePermissionsApplyToAnonymousUsers-Editable-Begin -->
@ -2541,7 +2549,7 @@ Network access: Remotely accessible registry paths and subpaths This security se
<!-- NetworkAccess_RestrictAnonymousAccessToNamedPipesAndShares-Description-Begin -->
<!-- Description-Source-DDF -->
Network access: Restrict anonymous access to Named Pipes and Shares When enabled, this security setting restricts anonymous access to shares and pipes to the settings for: Network access: Named pipes that can be accessed anonymously Network access: Shares that can be accessed anonymously Default: Enabled.
Network access: Restrict anonymous access to Named Pipes and Shares When enabled, this security setting restricts anonymous access to shares and pipes to the settings for: Network access: Named pipes that can be accessed anonymously Network access: Shares that can be accessed anonymously
<!-- NetworkAccess_RestrictAnonymousAccessToNamedPipesAndShares-Description-End -->
<!-- NetworkAccess_RestrictAnonymousAccessToNamedPipesAndShares-Editable-Begin -->
@ -2961,10 +2969,9 @@ Network security: Don't store LAN Manager hash value on next password change Thi
<!-- NetworkSecurity_ForceLogoffWhenLogonHoursExpire-Description-Begin -->
<!-- Description-Source-DDF -->
Network security: Force logoff when logon hours expire This security setting determines whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. This setting affects the Server Message Block (SMB) component. When this policy is enabled, it causes client sessions with the SMB server to be forcibly disconnected when the client's logon hours expire. If this policy is disabled, an established client session is allowed to be maintained after the client's logon hours have expired. Default: Enabled.
Network security: Force logoff when logon hours expire This security setting determines whether to disconnect users who are connected to the local computer outside their user account's valid logon hours. This setting affects the Server Message Block (SMB) component. When this policy is enabled, it causes client sessions with the SMB server to be forcibly disconnected when the client's logon hours expire.
> [!NOTE]
> This security setting behaves as an account policy. For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain Policy, and it's enforced by the domain controllers that make up the domain. A domain controller always pulls the account policy from the Default Domain Policy Group Policy object (GPO), even if there is a different account policy applied to the organizational unit that contains the domain controller. By default, workstations and servers that are joined to a domain (for example, member computers) also receive the same account policy for their local accounts. However, local account policies for member computers can be different from the domain account policy by defining an account policy for the organizational unit that contains the member computers. Kerberos settings aren't applied to member computers.
- If this policy is disabled, an established client session is allowed to be maintained after the client's logon hours have expired. Note: This security setting behaves as an account policy. For domain accounts, there can be only one account policy. The account policy must be defined in the Default Domain Policy, and it's enforced by the domain controllers that make up the domain. A domain controller always pulls the account policy from the Default Domain Policy Group Policy object (GPO), even if there is a different account policy applied to the organizational unit that contains the domain controller. By default, workstations and servers that are joined to a domain (for example, member computers) also receive the same account policy for their local accounts. However, local account policies for member computers can be different from the domain account policy by defining an account policy for the organizational unit that contains the member computers. Kerberos settings aren't applied to member computers.
<!-- NetworkSecurity_ForceLogoffWhenLogonHoursExpire-Description-End -->
<!-- NetworkSecurity_ForceLogoffWhenLogonHoursExpire-Editable-Begin -->
@ -3642,7 +3649,7 @@ Shutdown: Allow system to be shut down without having to log on This security se
<!-- Shutdown_ClearVirtualMemoryPageFile-Description-Begin -->
<!-- Description-Source-DDF -->
Shutdown: Clear virtual memory pagefile This security setting determines whether the virtual memory pagefile is cleared when the system is shut down. Virtual memory support uses a system pagefile to swap pages of memory to disk when they aren't used. On a running system, this pagefile is opened exclusively by the operating system, and it's well protected. However, systems that are configured to allow booting to other operating systems might have to make sure that the system pagefile is wiped clean when this system shuts down. This ensures that sensitive information from process memory that might go into the pagefile isn't available to an unauthorized user who manages to directly access the pagefile. When this policy is enabled, it causes the system pagefile to be cleared upon clean shutdown. If you enable this security option, the hibernation file (hiberfil.sys) is also zeroed out when hibernation is disabled. Default: Disabled.
Shutdown: Clear virtual memory pagefile This security setting determines whether the virtual memory pagefile is cleared when the system is shut down. Virtual memory support uses a system pagefile to swap pages of memory to disk when they aren't used. On a running system, this pagefile is opened exclusively by the operating system, and it's well protected. However, systems that are configured to allow booting to other operating systems might have to make sure that the system pagefile is wiped clean when this system shuts down. This ensures that sensitive information from process memory that might go into the pagefile isn't available to an unauthorized user who manages to directly access the pagefile. When this policy is enabled, it causes the system pagefile to be cleared upon clean shutdown. If you enable this security option, the hibernation file (hiberfil.sys) is also zeroed out when hibernation is disabled.
<!-- Shutdown_ClearVirtualMemoryPageFile-Description-End -->
<!-- Shutdown_ClearVirtualMemoryPageFile-Editable-Begin -->
@ -3741,7 +3748,7 @@ System Cryptography: Force strong key protection for user keys stored on the com
<!-- SystemObjects_RequireCaseInsensitivityForNonWindowsSubsystems-Description-Begin -->
<!-- Description-Source-DDF -->
System objects: Require case insensitivity for non-Windows subsystems This security setting determines whether case insensitivity is enforced for all subsystems. The Win32 subsystem is case insensitive. However, the kernel supports case sensitivity for other subsystems, such as POSIX. If this setting is enabled, case insensitivity is enforced for all directory objects, symbolic links, and IO objects, including file objects. Disabling this setting doesn't allow the Win32 subsystem to become case sensitive. Default: Enabled.
System objects: Require case insensitivity for non-Windows subsystems This security setting determines whether case insensitivity is enforced for all subsystems. The Win32 subsystem is case insensitive. However, the kernel supports case sensitivity for other subsystems, such as POSIX. If this setting is enabled, case insensitivity is enforced for all directory objects, symbolic links, and IO objects, including file objects. Disabling this setting doesn't allow the Win32 subsystem to become case sensitive.
<!-- SystemObjects_RequireCaseInsensitivityForNonWindowsSubsystems-Description-End -->
<!-- SystemObjects_RequireCaseInsensitivityForNonWindowsSubsystems-Editable-Begin -->
@ -3791,7 +3798,9 @@ System objects: Require case insensitivity for non-Windows subsystems This secur
<!-- SystemObjects_StrengthenDefaultPermissionsOfInternalSystemObjects-Description-Begin -->
<!-- Description-Source-DDF -->
System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links) This security setting determines the strength of the default discretionary access control list (DACL) for objects. Active Directory maintains a global list of shared system resources, such as DOS device names, mutexes, and semaphores. In this way, objects can be located and shared among processes. Each type of object is created with a default DACL that specifies who can access the objects and what permissions are granted. If this policy is enabled, the default DACL is stronger, allowing users who aren't administrators to read shared objects but not allowing these users to modify shared objects that they didn't create. Default: Enabled.
System objects: Strengthen default permissions of internal system objects (e.g., Symbolic Links) This security setting determines the strength of the default discretionary access control list (DACL) for objects. Active Directory maintains a global list of shared system resources, such as DOS device names, mutexes, and semaphores. In this way, objects can be located and shared among processes. Each type of object is created with a default DACL that specifies who can access the objects and what permissions are granted.
- If this policy is enabled, the default DACL is stronger, allowing users who aren't administrators to read shared objects but not allowing these users to modify shared objects that they didn't create.
<!-- SystemObjects_StrengthenDefaultPermissionsOfInternalSystemObjects-Description-End -->
<!-- SystemObjects_StrengthenDefaultPermissionsOfInternalSystemObjects-Editable-Begin -->
@ -3832,7 +3841,11 @@ System objects: Strengthen default permissions of internal system objects (e.g.,
<!-- UserAccountControl_AllowUIAccessApplicationsToPromptForElevation-Description-Begin -->
<!-- Description-Source-DDF -->
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop. This policy setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts used by a standard user. - Enabled: UIA programs, including Windows Remote Assistance, automatically disable the secure desktop for elevation prompts. If you don't disable the "User Account Control: Switch to the secure desktop when prompting for elevation" policy setting, the prompts appear on the interactive user's desktop instead of the secure desktop. - Disabled: (Default) The secure desktop can be disabled only by the user of the interactive desktop or by disabling the "User Account Control: Switch to the secure desktop when prompting for elevation" policy setting.
User Account Control: Allow UIAccess applications to prompt for elevation without using the secure desktop. This policy setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts used by a standard user.
- Enabled: UIA programs, including Windows Remote Assistance, automatically disable the secure desktop for elevation prompts. If you don't disable the "User Account Control: Switch to the secure desktop when prompting for elevation" policy setting, the prompts appear on the interactive user's desktop instead of the secure desktop.
- Disabled: (Default) The secure desktop can be disabled only by the user of the interactive desktop or by disabling the "User Account Control: Switch to the secure desktop when prompting for elevation" policy setting.
<!-- UserAccountControl_AllowUIAccessApplicationsToPromptForElevation-Description-End -->
<!-- UserAccountControl_AllowUIAccessApplicationsToPromptForElevation-Editable-Begin -->
@ -3873,6 +3886,70 @@ User Account Control: Allow UIAccess applications to prompt for elevation withou
<!-- UserAccountControl_AllowUIAccessApplicationsToPromptForElevation-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-Begin -->
## UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-Applicability-Begin -->
| Scope | Editions | Applicable OS |
|:--|:--|:--|
| ✅ Device <br> ❌ User | ✅ Pro <br> ✅ Enterprise <br> ✅ Education <br> ✅ Windows SE <br> ✅ IoT Enterprise / IoT Enterprise LTSC | ✅ Windows Insider Preview |
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-Applicability-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-OmaUri-Begin -->
```Device
./Device/Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions/UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection
```
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-OmaUri-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-Description-Begin -->
<!-- Description-Source-DDF -->
User Account Control: Behavior of the elevation prompt for administrators running with Administrator protection. This policy setting controls the behavior of the elevation prompt for administrators. The options are:
- Prompt for credentials on the secure desktop: When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a privileged credentials. If the user enters valid credentials, the operation continues with the user's highest available privilege.
- Prompt for consent on the secure desktop: When an operation requires elevation of privilege, the user is prompted on the secure desktop to select either Allow changes or Don't allow. If the user selects Allow changes, the operation continues with the user's highest available privilege.
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-Description-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-Editable-Begin -->
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
> [!NOTE]
> When Administrator protection is enabled, this policy overrides [UserAccountControl_BehaviorOfTheElevationPromptForAdministrators](#useraccountcontrol_behavioroftheelevationpromptforadministrators) policy.
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-Editable-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-DFProperties-Begin -->
**Description framework properties**:
| Property name | Property value |
|:--|:--|
| Format | `int` |
| Access Type | Add, Delete, Get, Replace |
| Default Value | 1 |
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-DFProperties-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-AllowedValues-Begin -->
**Allowed values**:
| Value | Description |
|:--|:--|
| 1 (Default) | Prompt for credentials on the secure desktop. |
| 2 | Prompt for consent on the secure desktop. |
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-AllowedValues-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-GpMapping-Begin -->
**Group policy mapping**:
| Name | Value |
|:--|:--|
| Name | User Account Control: Behavior of the elevation prompt for administrators running with Administrator protection |
| Path | Windows Settings > Security Settings > Local Policies > Security Options |
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-GpMapping-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-Examples-Begin -->
<!-- Add any examples for this policy here. Examples outside this section will get overwritten. -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-Examples-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministrators-Begin -->
## UserAccountControl_BehaviorOfTheElevationPromptForAdministrators
@ -3890,14 +3967,28 @@ User Account Control: Allow UIAccess applications to prompt for elevation withou
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministrators-Description-Begin -->
<!-- Description-Source-DDF -->
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode This policy setting controls the behavior of the elevation prompt for administrators. The options are: - Elevate without prompting: Allows privileged accounts to perform an operation that requires elevation without requiring consent or credentials.
User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode This policy setting controls the behavior of the elevation prompt for administrators. The options are:
> [!NOTE]
> Use this option only in the most constrained environments. - Prompt for credentials on the secure desktop: When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a privileged user name and password. If the user enters valid credentials, the operation continues with the user's highest available privilege. - Prompt for consent on the secure desktop: When an operation requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege. - Prompt for credentials: When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege. - Prompt for consent: When an operation requires elevation of privilege, the user is prompted to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege. - Prompt for consent for non-Windows binaries: (Default) When an operation for a non-Microsoft application requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege.
- Elevate without prompting: Allows privileged accounts to perform an operation that requires elevation without requiring consent or credentials.
>[!NOTE]
> Use this option only in the most constrained environments.
- Prompt for credentials on the secure desktop: When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a privileged user name and password. If the user enters valid credentials, the operation continues with the user's highest available privilege.
- Prompt for consent on the secure desktop: When an operation requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege.
- Prompt for credentials: When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
- Prompt for consent: When an operation requires elevation of privilege, the user is prompted to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege.
- Prompt for consent for non-Windows binaries: (Default) When an operation for a non-Microsoft application requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege.
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministrators-Description-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministrators-Editable-Begin -->
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
> [!NOTE]
> When Administrator protection is enabled, this policy behavior is overridden by [UserAccountControl_BehaviorOfTheElevationPromptForAdministratorProtection](#useraccountcontrol_behavioroftheelevationpromptforadministratorprotection) policy.
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministrators-Editable-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministrators-DFProperties-Begin -->
@ -3938,64 +4029,6 @@ User Account Control: Behavior of the elevation prompt for administrators in Adm
<!-- UserAccountControl_BehaviorOfTheElevationPromptForAdministrators-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-Begin -->
## UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-Applicability-Begin -->
| Scope | Editions | Applicable OS |
|:--|:--|:--|
| ✅ Device <br> ❌ User | ✅ Pro <br> ✅ Enterprise <br> ✅ Education <br> ✅ Windows SE <br> ✅ IoT Enterprise / IoT Enterprise LTSC | ✅ Windows Insider Preview |
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-Applicability-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-OmaUri-Begin -->
```Device
./Device/Vendor/MSFT/Policy/Config/LocalPoliciesSecurityOptions/UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators
```
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-OmaUri-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-Description-Begin -->
<!-- Description-Source-DDF -->
User Account Control: Behavior of the elevation prompt for administrators running with enhanced privilege protection. This policy setting controls the behavior of the elevation prompt for administrators. The options are: - Prompt for credentials on the secure desktop: When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a privileged user name and password. If the user enters valid credentials, the operation continues with the user's highest available privilege. - Prompt for consent on the secure desktop: When an operation requires elevation of privilege, the user is prompted on the secure desktop to select either Permit or Deny. If the user selects Permit, the operation continues with the user's highest available privilege.
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-Description-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-Editable-Begin -->
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-Editable-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-DFProperties-Begin -->
**Description framework properties**:
| Property name | Property value |
|:--|:--|
| Format | `int` |
| Access Type | Add, Delete, Get, Replace |
| Default Value | 2 |
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-DFProperties-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-AllowedValues-Begin -->
**Allowed values**:
| Value | Description |
|:--|:--|
| 1 | Prompt for credentials on the secure desktop. |
| 2 (Default) | Prompt for consent on the secure desktop. |
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-AllowedValues-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-GpMapping-Begin -->
**Group policy mapping**:
| Name | Value |
|:--|:--|
| Name | User Account Control: Behavior of the elevation prompt for administrators running with enhanced privilege protection |
| Path | Windows Settings > Security Settings > Local Policies > Security Options |
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-GpMapping-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-Examples-Begin -->
<!-- Add any examples for this policy here. Examples outside this section will get overwritten. -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-Examples-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForEnhancedAdministrators-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForStandardUsers-Begin -->
## UserAccountControl_BehaviorOfTheElevationPromptForStandardUsers
@ -4013,7 +4046,13 @@ User Account Control: Behavior of the elevation prompt for administrators runnin
<!-- UserAccountControl_BehaviorOfTheElevationPromptForStandardUsers-Description-Begin -->
<!-- Description-Source-DDF -->
User Account Control: Behavior of the elevation prompt for standard users This policy setting controls the behavior of the elevation prompt for standard users. The options are: - Prompt for credentials: (Default) When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege. - Automatically deny elevation requests: When an operation requires elevation of privilege, a configurable access denied error message is displayed. An enterprise that's running desktops as standard user may choose this setting to reduce help desk calls. - Prompt for credentials on the secure desktop: When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a different user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
User Account Control: Behavior of the elevation prompt for standard users This policy setting controls the behavior of the elevation prompt for standard users. The options are:
- Prompt for credentials: (Default) When an operation requires elevation of privilege, the user is prompted to enter an administrative user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
- Automatically deny elevation requests: When an operation requires elevation of privilege, a configurable access denied error message is displayed. An enterprise that's running desktops as standard user may choose this setting to reduce help desk calls.
- Prompt for credentials on the secure desktop: When an operation requires elevation of privilege, the user is prompted on the secure desktop to enter a different user name and password. If the user enters valid credentials, the operation continues with the applicable privilege.
<!-- UserAccountControl_BehaviorOfTheElevationPromptForStandardUsers-Description-End -->
<!-- UserAccountControl_BehaviorOfTheElevationPromptForStandardUsers-Editable-Begin -->
@ -4130,7 +4169,11 @@ User Account Control: Detect application installations and prompt for elevation
<!-- UserAccountControl_OnlyElevateExecutableFilesThatAreSignedAndValidated-Description-Begin -->
<!-- Description-Source-DDF -->
User Account Control: Only elevate executable files that are signed and validated This policy setting enforces public key infrastructure (PKI) signature checks for any interactive applications that request elevation of privilege. Enterprise administrators can control which applications are allowed to run by adding certificates to the Trusted Publishers certificate store on local computers. The options are: - Enabled: Enforces the PKI certification path validation for a given executable file before it's permitted to run. - Disabled: (Default) Does not enforce PKI certification path validation before a given executable file is permitted to run.
User Account Control: Only elevate executable files that are signed and validated This policy setting enforces public key infrastructure (PKI) signature checks for any interactive applications that request elevation of privilege. Enterprise administrators can control which applications are allowed to run by adding certificates to the Trusted Publishers certificate store on local computers. The options are:
- Enabled: Enforces the PKI certification path validation for a given executable file before it's permitted to run.
- Disabled: (Default) Does not enforce PKI certification path validation before a given executable file is permitted to run.
<!-- UserAccountControl_OnlyElevateExecutableFilesThatAreSignedAndValidated-Description-End -->
<!-- UserAccountControl_OnlyElevateExecutableFilesThatAreSignedAndValidated-Editable-Begin -->
@ -4188,7 +4231,11 @@ User Account Control: Only elevate executable files that are signed and validate
<!-- UserAccountControl_OnlyElevateUIAccessApplicationsThatAreInstalledInSecureLocations-Description-Begin -->
<!-- Description-Source-DDF -->
User Account Control: Only elevate UIAccess applications that are installed in secure locations This policy setting controls whether applications that request to run with a User Interface Accessibility (UIAccess) integrity level must reside in a secure location in the file system. Secure locations are limited to the following: - ..\Program Files\, including subfolders - ..\Windows\system32\ - ..\Program Files (x86)\, including subfolders for 64-bit versions of Windows Note: Windows enforces a public key infrastructure (PKI) signature check on any interactive application that requests to run with a UIAccess integrity level regardless of the state of this security setting. The options are: - Enabled: (Default) If an application resides in a secure location in the file system, it runs only with UIAccess integrity. - Disabled: An application runs with UIAccess integrity even if it doesn't reside in a secure location in the file system.
User Account Control: Only elevate UIAccess applications that are installed in secure locations This policy setting controls whether applications that request to run with a User Interface Accessibility (UIAccess) integrity level must reside in a secure location in the file system. Secure locations are limited to the following: - ..\Program Files\, including subfolders - ..\Windows\system32\ - ..\Program Files (x86)\, including subfolders for 64-bit versions of Windows Note: Windows enforces a public key infrastructure (PKI) signature check on any interactive application that requests to run with a UIAccess integrity level regardless of the state of this security setting. The options are:
- Enabled: (Default) If an application resides in a secure location in the file system, it runs only with UIAccess integrity.
- Disabled: An application runs with UIAccess integrity even if it doesn't reside in a secure location in the file system.
<!-- UserAccountControl_OnlyElevateUIAccessApplicationsThatAreInstalledInSecureLocations-Description-End -->
<!-- UserAccountControl_OnlyElevateUIAccessApplicationsThatAreInstalledInSecureLocations-Editable-Begin -->
@ -4246,7 +4293,11 @@ User Account Control: Only elevate UIAccess applications that are installed in s
<!-- UserAccountControl_RunAllAdministratorsInAdminApprovalMode-Description-Begin -->
<!-- Description-Source-DDF -->
User Account Control: Turn on Admin Approval Mode This policy setting controls the behavior of all User Account Control (UAC) policy settings for the computer. If you change this policy setting, you must restart your computer. The options are: - Enabled: (Default) Admin Approval Mode is enabled. This policy must be enabled and related UAC policy settings must also be set appropriately to allow the built-in Administrator account and all other users who are members of the Administrators group to run in Admin Approval Mode. - Disabled: Admin Approval Mode and all related UAC policy settings are disabled.
User Account Control: Turn on Admin Approval Mode This policy setting controls the behavior of all User Account Control (UAC) policy settings for the computer. If you change this policy setting, you must restart your computer. The options are:
- Enabled: (Default) Admin Approval Mode is enabled. This policy must be enabled and related UAC policy settings must also be set appropriately to allow the built-in Administrator account and all other users who are members of the Administrators group to run in Admin Approval Mode.
- Disabled: Admin Approval Mode and all related UAC policy settings are disabled.
> [!NOTE]
> If this policy setting is disabled, the Security Center notifies you that the overall security of the operating system has been reduced.
@ -4307,7 +4358,11 @@ User Account Control: Turn on Admin Approval Mode This policy setting controls t
<!-- UserAccountControl_SwitchToTheSecureDesktopWhenPromptingForElevation-Description-Begin -->
<!-- Description-Source-DDF -->
User Account Control: Switch to the secure desktop when prompting for elevation This policy setting controls whether the elevation request prompt is displayed on the interactive user's desktop or the secure desktop. The options are: - Enabled: (Default) All elevation requests go to the secure desktop regardless of prompt behavior policy settings for administrators and standard users. - Disabled: All elevation requests go to the interactive user's desktop. Prompt behavior policy settings for administrators and standard users are used.
User Account Control: Switch to the secure desktop when prompting for elevation This policy setting controls whether the elevation request prompt is displayed on the interactive user's desktop or the secure desktop. The options are:
- Enabled: (Default) All elevation requests go to the secure desktop regardless of prompt behavior policy settings for administrators and standard users.
- Disabled: All elevation requests go to the interactive user's desktop. Prompt behavior policy settings for administrators and standard users are used.
<!-- UserAccountControl_SwitchToTheSecureDesktopWhenPromptingForElevation-Description-End -->
<!-- UserAccountControl_SwitchToTheSecureDesktopWhenPromptingForElevation-Editable-Begin -->
@ -4365,7 +4420,7 @@ User Account Control: Switch to the secure desktop when prompting for elevation
<!-- UserAccountControl_TypeOfAdminApprovalMode-Description-Begin -->
<!-- Description-Source-DDF -->
User Account Control: Configure type of Admin Approval Mode. This policy setting controls whether enhanced privilege protection is applied to admin approval mode elevations. If you change this policy setting, you must restart your computer. This policy is only supported on Windows Desktop, not Server. The options are: - Admin Approval Mode is running in legacy mode (default). - Admin Approval Mode is running with enhanced privilege protection.
User Account Control: Configure type of Admin Approval Mode. This policy setting controls whether Administrator protection is applied to admin approval mode elevations. If you change this policy setting, you must restart your computer. This policy is only supported on Windows Desktop, not Server. The options are: - Admin Approval Mode is running in legacy mode (default). - Admin Approval Mode is running with Administrator protection.
<!-- UserAccountControl_TypeOfAdminApprovalMode-Description-End -->
<!-- UserAccountControl_TypeOfAdminApprovalMode-Editable-Begin -->
@ -4388,7 +4443,7 @@ User Account Control: Configure type of Admin Approval Mode. This policy setting
| Value | Description |
|:--|:--|
| 1 (Default) | Legacy Admin Approval Mode. |
| 2 | Admin Approval Mode with enhanced privilege protection. |
| 2 | Admin Approval Mode with Administrator protection. |
<!-- UserAccountControl_TypeOfAdminApprovalMode-AllowedValues-End -->
<!-- UserAccountControl_TypeOfAdminApprovalMode-GpMapping-Begin -->
@ -4423,7 +4478,11 @@ User Account Control: Configure type of Admin Approval Mode. This policy setting
<!-- UserAccountControl_UseAdminApprovalMode-Description-Begin -->
<!-- Description-Source-DDF -->
User Account Control: Use Admin Approval Mode for the built-in Administrator account This policy setting controls the behavior of Admin Approval Mode for the built-in Administrator account. The options are: - Enabled: The built-in Administrator account uses Admin Approval Mode. By default, any operation that requires elevation of privilege will prompt the user to approve the operation. - Disabled: (Default) The built-in Administrator account runs all applications with full administrative privilege.
User Account Control: Use Admin Approval Mode for the built-in Administrator account This policy setting controls the behavior of Admin Approval Mode for the built-in Administrator account. The options are:
- Enabled: The built-in Administrator account uses Admin Approval Mode. By default, any operation that requires elevation of privilege will prompt the user to approve the operation.
- Disabled: (Default) The built-in Administrator account runs all applications with full administrative privilege.
<!-- UserAccountControl_UseAdminApprovalMode-Description-End -->
<!-- UserAccountControl_UseAdminApprovalMode-Editable-Begin -->
@ -4481,7 +4540,11 @@ User Account Control: Use Admin Approval Mode for the built-in Administrator acc
<!-- UserAccountControl_VirtualizeFileAndRegistryWriteFailuresToPerUserLocations-Description-Begin -->
<!-- Description-Source-DDF -->
User Account Control: Virtualize file and registry write failures to per-user locations This policy setting controls whether application write failures are redirected to defined registry and file system locations. This policy setting mitigates applications that run as administrator and write run-time application data to %ProgramFiles%, %Windir%, %Windir%\system32, or HKLM\Software. The options are: - Enabled: (Default) Application write failures are redirected at run time to defined user locations for both the file system and registry. - Disabled: Applications that write data to protected locations fail.
User Account Control: Virtualize file and registry write failures to per-user locations This policy setting controls whether application write failures are redirected to defined registry and file system locations. This policy setting mitigates applications that run as administrator and write run-time application data to %ProgramFiles%, %Windir%, %Windir%\system32, or HKLM\Software. The options are:
- Enabled: (Default) Application write failures are redirected at run time to defined user locations for both the file system and registry.
- Disabled: Applications that write data to protected locations fail.
<!-- UserAccountControl_VirtualizeFileAndRegistryWriteFailuresToPerUserLocations-Description-End -->
<!-- UserAccountControl_VirtualizeFileAndRegistryWriteFailuresToPerUserLocations-Editable-Begin -->

10
windows/client-management/mdm/policy-csp-mixedreality.md
View File

@ -1,7 +1,7 @@
---
title: MixedReality Policy CSP
description: Learn more about the MixedReality Area in Policy CSP.
ms.date: 02/20/2024
ms.date: 09/11/2024
---
<!-- Auto-Generated CSP Document -->
@ -1406,7 +1406,9 @@ This policy setting controls if it's required that the Start icon to be looked a
<!-- SkipCalibrationDuringSetup-Description-Begin -->
<!-- Description-Source-DDF -->
This policy configures whether the device will take the user through the eye tracking calibration process during device setup and first time user setup. If this policy is enabled, the device won't show the eye tracking calibration process during device setup and first time user setup. Note that until the user goes through the calibration process, eye tracking won't work on the device. If an app requires eye tracking and the user hasn't gone through the calibration process, the user will be prompted to do so.
This policy configures whether the device will take the user through the eye tracking calibration process during device setup and first time user setup.
- If this policy is enabled, the device won't show the eye tracking calibration process during device setup and first time user setup. Note that until the user goes through the calibration process, eye tracking won't work on the device. If an app requires eye tracking and the user hasn't gone through the calibration process, the user will be prompted to do so.
<!-- SkipCalibrationDuringSetup-Description-End -->
<!-- SkipCalibrationDuringSetup-Editable-Begin -->
@ -1457,7 +1459,9 @@ This policy configures whether the device will take the user through the eye tra
<!-- SkipTrainingDuringSetup-Description-Begin -->
<!-- Description-Source-DDF -->
This policy configures whether the device will take the user through a training process during device setup and first time user setup. If this policy is enabled, the device won't show the training process during device setup and first time user setup. If the user wishes to go through that training process, the user can launch the Tips app.
This policy configures whether the device will take the user through a training process during device setup and first time user setup.
- If this policy is enabled, the device won't show the training process during device setup and first time user setup. If the user wishes to go through that training process, the user can launch the Tips app.
<!-- SkipTrainingDuringSetup-Description-End -->
<!-- SkipTrainingDuringSetup-Editable-Begin -->

10
windows/client-management/mdm/policy-csp-privacy.md
View File

@ -1,7 +1,7 @@
---
title: Privacy Policy CSP
description: Learn more about the Privacy Area in Policy CSP.
ms.date: 06/28/2024
ms.date: 09/11/2024
---
<!-- Auto-Generated CSP Document -->
@ -155,9 +155,9 @@ Most restrictive value is `0` to not allow cross-device clipboard.
<!-- Description-Source-ADMX -->
This policy specifies whether users on the device have the option to enable online speech recognition services.
If this policy is enabled or not configured, control is deferred to users, and users may choose whether to enable speech services via settings.
- If this policy is enabled or not configured, control is deferred to users, and users may choose whether to enable speech services via settings.
If this policy is disabled, speech services will be disabled, and users can't enable speech services via settings.
- If this policy is disabled, speech services will be disabled, and users can't enable speech services via settings.
<!-- AllowInputPersonalization-Description-End -->
<!-- AllowInputPersonalization-Editable-Begin -->
@ -300,9 +300,9 @@ This policy setting turns off the advertising ID, preventing apps from using the
<!-- Description-Source-ADMX -->
When logging into a new user account for the first time or after an upgrade in some scenarios, that user may be presented with a screen or series of screens that prompts the user to choose privacy settings for their account. Enable this policy to prevent this experience from launching.
If this policy is enabled, the privacy experience won't launch for newly created user accounts or for accounts that would've been prompted to choose their privacy settings after an upgrade.
- If this policy is enabled, the privacy experience won't launch for newly created user accounts or for accounts that would've been prompted to choose their privacy settings after an upgrade.
If this policy is disabled or not configured, then the privacy experience may launch for newly created user accounts or for accounts that should be prompted to choose their privacy settings after an upgrade.
- If this policy is disabled or not configured, then the privacy experience may launch for newly created user accounts or for accounts that should be prompted to choose their privacy settings after an upgrade.
<!-- DisablePrivacyExperience-Description-End -->
<!-- DisablePrivacyExperience-Editable-Begin -->

12
windows/client-management/mdm/policy-csp-system.md
View File

@ -431,7 +431,7 @@ This policy setting determines whether Windows is allowed to download fonts and
- If you enable this policy setting, Windows periodically queries an online font provider to determine whether a new font catalog is available. Windows may also download font data if needed to format or render text.
- If you disable this policy setting, Windows doesn't connect to an online font provider and only enumerates locally-installed fonts.
- If you disable this policy setting, Windows doesn't connect to an online font provider and only enumerates locally installed fonts.
- If you don't configure this policy setting, the default behavior depends on the Windows edition. Changes to this policy take effect on reboot.
<!-- AllowFontProviders-Description-End -->
@ -569,7 +569,7 @@ Specifies whether to allow app access to the Location service. Most restricted v
This policy is deprecated and will only work on Windows 10 version 1809. Setting this policy will have no effect for other supported versions of Windows.
This policy setting configures a Microsoft Entra joined device so that Microsoft is the processor of the Windows diagnostic data collected from the device, subject to the Product Terms at< https://go.microsoft.com/fwlink/?linkid=2185086>.
For customers who enroll into the Microsoft Managed Desktop service, enabling this policy is required to allow Microsoft to process data for operational and analytic needs. See <https://go.microsoft.com/fwlink/?linkid=2184944> for more information.
hen these policies are configured, Windows diagnostic data collected from the device will be subject to Microsoft processor commitments.
When these policies are configured, Windows diagnostic data collected from the device will be subject to Microsoft processor commitments.
This setting has no effect on devices unless they're properly enrolled in Microsoft Managed Desktop. If you disable this policy setting, devices may not appear in Microsoft Managed Desktop.
<!-- AllowMicrosoftManagedDesktopProcessing-Description-End -->
@ -888,7 +888,7 @@ To enable this behavior:
When these policies are configured, Windows diagnostic data collected from the device will be subject to Microsoft processor commitments.
If you disable or don't configure this policy setting, devices enrolled to the Windows Update for Business deployment service won't be able to take advantage of some deployment service features.
If you disable or don't configure this policy setting, devices enrolled to Windows Autopatch won't be able to take advantage of some deployment service features.
<!-- AllowWUfBCloudProcessing-Description-End -->
<!-- AllowWUfBCloudProcessing-Editable-Begin -->
@ -1739,7 +1739,7 @@ This policy setting controls whether Windows records attempts to connect with th
<!-- FeedbackHubAlwaysSaveDiagnosticsLocally-Description-Begin -->
<!-- Description-Source-DDF -->
Diagnostic files created when a feedback is filed in the Feedback Hub app will always be saved locally. If this policy isn't present or set to false, users will be presented with the option to save locally. The default is to not save locally.
Diagnostic files created when feedback is filed in the Feedback Hub app will always be saved locally. If this policy isn't present or set to false, users will be presented with the option to save locally. The default is to not save locally.
<!-- FeedbackHubAlwaysSaveDiagnosticsLocally-Description-End -->
<!-- FeedbackHubAlwaysSaveDiagnosticsLocally-Editable-Begin -->
@ -1761,8 +1761,8 @@ Diagnostic files created when a feedback is filed in the Feedback Hub app will a
| Value | Description |
|:--|:--|
| 0 (Default) | False. The Feedback Hub won't always save a local copy of diagnostics that may be created when a feedback is submitted. The user will have the option to do so. |
| 1 | True. The Feedback Hub should always save a local copy of diagnostics that may be created when a feedback is submitted. |
| 0 (Default) | False. The Feedback Hub won't always save a local copy of diagnostics that may be created when feedback is submitted. The user will have the option to do so. |
| 1 | True. The Feedback Hub should always save a local copy of diagnostics that may be created when feedback is submitted. |
<!-- FeedbackHubAlwaysSaveDiagnosticsLocally-AllowedValues-End -->
<!-- FeedbackHubAlwaysSaveDiagnosticsLocally-Examples-Begin -->

4
windows/client-management/mdm/policy-csp-taskscheduler.md
View File

@ -1,7 +1,7 @@
---
title: TaskScheduler Policy CSP
description: Learn more about the TaskScheduler Area in Policy CSP.
ms.date: 01/18/2024
ms.date: 09/11/2024
---
<!-- Auto-Generated CSP Document -->
@ -30,7 +30,7 @@ ms.date: 01/18/2024
<!-- EnableXboxGameSaveTask-Description-Begin -->
<!-- Description-Source-DDF -->
This setting determines whether the specific task is enabled (1) or disabled (0). Default: Enabled.
This setting determines whether the specific task is enabled (1) or disabled (0).
<!-- EnableXboxGameSaveTask-Description-End -->
<!-- EnableXboxGameSaveTask-Editable-Begin -->

4
windows/client-management/mdm/policy-csp-update.md
View File

@ -1,7 +1,7 @@
---
title: Update Policy CSP
description: Learn more about the Update Area in Policy CSP.
ms.date: 08/06/2024
ms.date: 09/11/2024
---
<!-- Auto-Generated CSP Document -->
@ -4077,7 +4077,7 @@ Allows IT Admins to specify additional upgrade delays for up to 8 months. Suppor
<!-- Description-Source-ADMX -->
Enable this policy to not allow update deferral policies to cause scans against Windows Update.
If this policy is disabled or not configured, then the Windows Update client may initiate automatic scans against Windows Update while update deferral policies are enabled.
- If this policy is disabled or not configured, then the Windows Update client may initiate automatic scans against Windows Update while update deferral policies are enabled.
> [!NOTE]
> This policy applies only when the intranet Microsoft update service this computer is directed to is configured to support client-side targeting. If the "Specify intranet Microsoft update service location" policy is disabled or not configured, this policy has no effect.

22
windows/client-management/mdm/policy-csp-windowsai.md
View File

@ -1,7 +1,7 @@
---
title: WindowsAI Policy CSP
description: Learn more about the WindowsAI Area in Policy CSP.
ms.date: 08/07/2024
ms.date: 09/11/2024
---
<!-- Auto-Generated CSP Document -->
@ -32,7 +32,13 @@ ms.date: 08/07/2024
<!-- DisableAIDataAnalysis-Description-Begin -->
<!-- Description-Source-DDF -->
This policy setting allows you to determine whether end users have the option to allow snapshots to be saved on their PCs. If disabled, end users will have a choice to save snapshots of their screen on their PC and then use Recall to find things they've seen. If the policy is enabled, end users won't be able to save snapshots on their PC. If the policy isn't configured, end users may or may not be able to save snapshots on their PC-depending on other policy configurations.
This policy setting allows you to determine whether end users have the option to allow snapshots to be saved on their PCs.
- If disabled, end users will have a choice to save snapshots of their screen on their PC and then use Recall to find things they've seen.
- If the policy is enabled, end users won't be able to save snapshots on their PC.
- If the policy isn't configured, end users may or may not be able to save snapshots on their PC-depending on other policy configurations.
<!-- DisableAIDataAnalysis-Description-End -->
<!-- DisableAIDataAnalysis-Editable-Begin -->
@ -90,7 +96,11 @@ This policy setting allows you to determine whether end users have the option to
<!-- DisableCocreator-Description-Begin -->
<!-- Description-Source-DDF -->
This policy setting allows you to control whether Cocreator functionality is disabled in the Windows Paint app. If this policy is enabled, Cocreator functionality won't be accessible in the Paint app. If this policy is disabled or not configured, users will be able to access Cocreator functionality.
This policy setting allows you to control whether Cocreator functionality is disabled in the Windows Paint app.
- If this policy is enabled, Cocreator functionality won't be accessible in the Paint app.
- If this policy is disabled or not configured, users will be able to access Cocreator functionality.
<!-- DisableCocreator-Description-End -->
<!-- DisableCocreator-Editable-Begin -->
@ -148,7 +158,11 @@ This policy setting allows you to control whether Cocreator functionality is dis
<!-- DisableImageCreator-Description-Begin -->
<!-- Description-Source-DDF -->
This policy setting allows you to control whether Image Creator functionality is disabled in the Windows Paint app. If this policy is enabled, Image Creator functionality won't be accessible in the Paint app. If this policy is disabled or not configured, users will be able to access Image Creator functionality.
This policy setting allows you to control whether Image Creator functionality is disabled in the Windows Paint app.
- If this policy is enabled, Image Creator functionality won't be accessible in the Paint app.
- If this policy is disabled or not configured, users will be able to access Image Creator functionality.
<!-- DisableImageCreator-Description-End -->
<!-- DisableImageCreator-Editable-Begin -->

20
windows/client-management/mdm/toc.yml
View File

@ -27,7 +27,7 @@ items:
items:
- name: Using PowerShell scripting with the WMI Bridge Provider
href: ../using-powershell-scripting-with-the-wmi-bridge-provider.md
- name: WMI providers supported in Windows 10
- name: WMI providers supported in Windows
href: ../wmi-providers-supported-in-windows.md
- name: Understanding ADMX policies
href: ../understanding-admx-backed-policies.md
@ -43,11 +43,21 @@ items:
href: ../structure-of-oma-dm-provisioning-files.md
- name: Server requirements for OMA DM
href: ../server-requirements-windows-mdm.md
- name: Declared Configuration protocol
href: ../declared-configuration.md
- name: Declared Configuration
items:
- name: Declared Configuration extensibility
- name: Protocol
expanded: true
items:
- name: Overview
href: ../declared-configuration.md
- name: Discovery
href: ../declared-configuration-discovery.md
- name: Enrollment
href: ../declared-configuration-enrollment.md
- name: Extensibility
href: ../declared-configuration-extensibility.md
- name: Resource access
href: ../declared-configuration-resource-access.md
- name: DeclaredConfiguration CSP
href: declaredconfiguration-csp.md
- name: DMClient CSP
@ -377,7 +387,7 @@ items:
href: policy-csp-authentication.md
- name: Autoplay
href: policy-csp-autoplay.md
- name: Bitlocker
- name: BitLocker
href: policy-csp-bitlocker.md
- name: BITS
href: policy-csp-bits.md

2
windows/client-management/toc.yml
View File

@ -48,7 +48,7 @@ items:
href: enterprise-app-management.md
- name: Manage updates
href: device-update-management.md
- name: Manage Copilot in Windows
- name: Updated Windows and Microsoft Copilot experience
href: manage-windows-copilot.md
- name: Manage Recall
href: manage-recall.md

1
windows/configuration/assigned-access/shell-launcher/index.md
View File

@ -127,5 +127,4 @@ Depending on your configuration, you can have a user to automatically sign in to
<!--links-->
[MEM-1]: /mem/intune/configuration/custom-settings-windows-10
[MEM-2]: /mem/intune/fundamentals/licenses#device-only-licenses
[WIN-3]: /windows/client-management/mdm/assignedaccess-csp

6
windows/configuration/shared-pc/set-up-shared-or-guest-pc.md
View File

@ -1,7 +1,7 @@
---
title: Configure a shared or guest Windows device
description: Description of how to configured Shared PC mode, which is a Windows feature that optimizes devices for shared use scenarios.
ms.date: 11/08/2023
ms.date: 09/06/2024
ms.topic: how-to
---
@ -25,9 +25,7 @@ Shared PC can be configured using the following methods:
Follow the instructions below to configure your devices, selecting the option that best suits your needs.
#### [:::image type="icon" source="../images/icons/intune.svg"::: **Intune**](#tab/intune)
#### [:::image type="icon" source="../images/icons/intune.svg"::: **Intune/CSP**](#tab/intune)
To configure devices using Microsoft Intune, [create a **Settings catalog** policy][MEM-2], and use the settings listed under the category **`Shared PC`**:

2
windows/configuration/wcd/wcd-universalappinstall.md
View File

@ -34,7 +34,7 @@ For each app that you add to the package, configure the settings in the followin
| Setting | Value | Description |
|--|--|--|
| ApplicationFile | `.appx` or `.appxbundle` | Set the value to the app file that you want to install on the device. Also enable the [AllowAllTrustedApps setting](wcd-policies.md#applicationmanagement) and add a root certificate or license file. |
| DependencyAppxFiles | Any required frameworks | In Microsoft Store for Business, any dependencies for the app are listed in the **Required frameworks** section of the download page. |
| DependencyAppxFiles | Any required frameworks | Typically, dependencies for the app are listed undere **Required frameworks**. |
| DeploymentOptions | - None</br>-Force application shutdown: If this package, or any package that depends on this package is currently in use, then the processes associated with the package are forcibly shut down. The registration can continue. </br>- Development mode: Don't use. </br>- Install all resources: When you set this option, the app is instructed to skip resource applicability checks.</br>- Force target application shutdown: If this package is currently in use, the processes associated with the package are shut down forcibly so that registration can continue | Select a deployment option. |
| LaunchAppAtLogin | - Don't launch app</br>- Launch app | Set the value for app behavior when a user signs in. |
| OptionalPackageFiles | Additional files required by the package | Browse to, select, and add the optional package files. |

20
windows/deployment/TOC.yml
View File

@ -37,10 +37,6 @@ items:
href: upgrade/windows-upgrade-and-migration-considerations.md
- name: Delivery Optimization for Windows updates
href: do/waas-delivery-optimization.md?context=/windows/deployment/context/context
- name: Windows 10 deployment considerations
href: planning/windows-10-deployment-considerations.md
- name: Windows 10 infrastructure requirements
href: planning/windows-10-infrastructure-requirements.md
- name: Windows compatibility cookbook
href: /windows/compatibility/
- name: Prepare
@ -109,22 +105,6 @@ items:
href: update/waas-wufb-group-policy.md
- name: Deploy updates using CSPs and MDM
href: update/waas-wufb-csp-mdm.md
- name: Windows Update for Business deployment service
items:
- name: Windows Update for Business deployment service overview
href: update/deployment-service-overview.md
- name: Prerequisites for Windows Update for Business deployment service
href: update/deployment-service-prerequisites.md
- name: Deploy updates with the deployment service
items:
- name: Deploy feature updates using Graph Explorer
href: update/deployment-service-feature-updates.md
- name: Deploy expedited updates using Graph Explorer
href: update/deployment-service-expedited-updates.md
- name: Deploy driver and firmware updates using Graph Explorer
href: update/deployment-service-drivers.md
- name: Troubleshoot Windows Update for Business deployment service
href: update/deployment-service-troubleshoot.md
- name: Activate
items:
- name: Windows subscription activation

5
windows/deployment/deploy-enterprise-licenses.md
View File

@ -9,7 +9,7 @@ ms.service: windows-client
ms.subservice: activation
ms.localizationpriority: medium
ms.topic: how-to
ms.date: 03/04/2024
ms.date: 9/03/2024
zone_pivot_groups: windows-versions-11-10
appliesto:
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 11</a>
@ -491,9 +491,12 @@ When a device has been offline for an extended period of time, the Subscription
- [Universal Store Service APIs and Web Application, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f](/troubleshoot/azure/active-directory/verify-first-party-apps-sign-in#application-ids-of-commonly-used-microsoft-applications).
- [Windows Store for Business, AppID 45a330b1-b1ec-4cc1-9161-9f03992aa49f](/troubleshoot/azure/active-directory/verify-first-party-apps-sign-in#application-ids-of-commonly-used-microsoft-applications).
> [!NOTE]
> The Microsoft Store for Business and Microsoft Store for Education are retired. For more information, see [Microsoft Store for Business and Education retiring March 31, 2023](/lifecycle/announcements/microsoft-store-for-business-education-retiring).
Although the app ID is the same in both instances, the name of the cloud app depends on the tenant.
For more information about configuring exclusions in Conditional Access policies, see [Application exclusions](/azure/active-directory/conditional-access/howto-conditional-access-policy-all-users-mfa#application-exclusions).
<!-- 8605089 -->

4
windows/deployment/do/waas-delivery-optimization-faq.yml
View File

@ -17,7 +17,7 @@ metadata:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/en-us/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019, and later</a>
- ✅ <a href=https://learn.microsoft.com/windows/deployment/do/waas-delivery-optimization target=_blank>Delivery Optimization</a>
ms.date: 08/06/2024
ms.date: 09/10/2024
title: Frequently Asked Questions about Delivery Optimization
summary: |
This article answers frequently asked questions about Delivery Optimization.
@ -103,8 +103,6 @@ sections:
- `*.dl.delivery.mp.microsoft.com`
**For the payloads (optional)**:
- `*.windowsupdate.com`
**For group peers across multiple NATs (Teredo)**:

1
windows/deployment/do/waas-delivery-optimization.md
View File

@ -52,7 +52,6 @@ The following table lists the minimum Windows 10 version that supports Delivery
| Windows Update ([feature updates quality updates, language packs, drivers](../update/get-started-updates-channels-tools.md#types-of-updates)) | Windows 10 1511, Windows 11 | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| Windows 10/11 UWP Store apps | Windows 10 1511, Windows 11 | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| Windows 11 Win32 Store apps | Windows 11 | :heavy_check_mark: | |
| Windows 10 Store for Business apps | Windows 10 1511, Windows 11 | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| Windows Defender definition updates | Windows 10 1511, Windows 11 | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| Intune Win32 apps| Windows 10 1709, Windows 11 | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |
| Microsoft 365 Apps and updates | Windows 10 1709, Windows 11 | :heavy_check_mark: | :heavy_check_mark: | :heavy_check_mark: |

BIN
windows/deployment/planning/images/fig4-wsuslist.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 41 KiB

82
windows/deployment/planning/windows-10-deployment-considerations.md
View File

@ -1,82 +0,0 @@
---
title: Windows 10 deployment considerations (Windows 10)
description: There are new deployment options in Windows 10 that help you simplify the deployment process and automate migration of existing settings and applications.
manager: aaroncz
ms.author: frankroj
ms.service: windows-client
ms.localizationpriority: medium
author: frankroj
ms.topic: conceptual
ms.subservice: itpro-deploy
ms.date: 10/28/2022
---
# Windows 10 deployment considerations
**Applies to**
- Windows 10
There are new deployment options in Windows 10 that help you simplify the deployment process and automate migration of existing settings and applications.
For many years, organizations have deployed new versions of Windows using a "wipe and load" deployment process. At a high level, this process captures existing data and settings from the existing device, deploys a new custom-built Windows image to a PC, injects hardware drivers, reinstalls applications, and finally restores the data and settings. With Windows 10, this process is still fully supported, and for some deployment scenarios is still necessary.
Windows 10 also introduces two additional scenarios that organizations should consider:
- **In-place upgrade**, which provides a simple, automated process that uses the Windows setup process to automatically upgrade from an earlier version of Windows. This process automatically migrates existing data, settings, drivers, and applications.
- **Dynamic provisioning**, which enables organizations to configure new Windows 10 devices for organization use without having to deploy a new custom organization image to the device.
Both of these scenarios eliminate the image creation process altogether, which can greatly simplify the deployment process.
So how do you choose? At a high level:
| Consider ... | For these scenarios |
|---|---|
| In-place upgrade | - When you want to keep all (or at least most) existing applications<br/>- When you don't plan to significantly change the device configuration (for example, BIOS to UEFI) or operating system configuration (for example, x86 to x64, language changes, Administrators to non-Administrators, Active Directory domain consolidations)<br/>- To migrate from Windows 10 to a later Windows 10 release |
| Traditional wipe-and-load | - When you upgrade significant numbers of applications along with the new Windows OS<br/>- When you make significant device or operating system configuration changes<br/>- When you "start clean". For example, scenarios where it isn't necessary to preserve existing apps or data (for example, call centers) or when you move from unmanaged to well-managed PCs<br/>- When you migrate from Windows Vista or other previous operating system versions |
| Dynamic provisioning | - For new devices, especially in "choose your own device" scenarios when simple configuration (not reimaging) is all that is required. <br/>- When used in combination with a management tool (for example, an MDM service like Microsoft Intune) that enables self-service installation of user-specific or role-specific apps |
## Migration from previous Windows versions
For existing PCs running Windows 7 or Windows 8.1, in-place upgrade is the recommended method for Windows 10 deployment and should be used whenever possible. Although wipe-and-load (OS refresh) deployments are still fully supported (and necessary in some scenarios, as mentioned previously), in-place upgrade is simpler and faster, and enables a faster Windows 10 deployment overall.
The original Windows 8 release was only supported until January 2016. For devices running Windows 8.0, you can update to Windows 8.1 and then upgrade to Windows 10.
For PCs running operating systems older than Windows 7, you can perform wipe-and-load (OS refresh) deployments when you use compatible hardware.
For organizations with Software Assurance for Windows, both in-place upgrade or wipe-and-load can be used (with in-place upgrade being the preferred method, as previously discussed).
For organizations that didn't take advantage of the free upgrade offer and aren't enrolled in Software Assurance for Windows, Windows 10 upgrade licenses are available for purchase through existing Volume License (VL) agreements.
## Setting up new computers
For new computers acquired with Windows 10 preinstalled, you can use dynamic provisioning scenarios to transform the device from its initial state into a fully configured organization PC. There are two primary dynamic provisioning scenarios you can use:
- **User-driven, from the cloud.** By joining a device into Microsoft Entra ID and leveraging the automatic mobile device management (MDM) provisioning capabilities at the same time, an end user can initiate the provisioning process themselves just by entering the Microsoft Entra account and password (called their "work or school account" within Windows 10). The MDM service can then transform the device into a fully configured organization PC. For more information, see [Microsoft Entra integration with MDM](/windows/client-management/mdm/azure-active-directory-integration-with-mdm).
- **IT admin-driven, using new tools.** Using the new Windows Imaging and Configuration Designer (ICD) tool, IT administrators can create provisioning packages that can be applied to a computer to transform it into a fully configured organization PC. For more information, see [Windows Imaging and Configuration Designer](/windows/configuration/provisioning-packages/provisioning-install-icd).
In either of these scenarios, you can make various configuration changes to the PC:
- Transform the edition (SKU) of Windows 10 that is in use.
- Apply configuration and settings to the device (for example, security settings, device restrictions, policies, Wi-Fi and VPN profiles, certificates, and so on).
- Install apps, language packs, and updates.
- Enroll the device in a management solution (applicable for IT admin-driven scenarios, configuring the device just enough to allow the management tool to take over configuration and ongoing management).
## Stay up to date
For computers using the [General Availability Channel](../update/waas-overview.md#general-availability-channel), you can deploy these upgrades by using various methods:
- Windows Update or Windows Update for Business, for devices where you want to receive updates directly from the Internet.
- Windows Server Update Services (WSUS), for devices configured to pull updates from internal servers after they're approved (deploying like an update).
- Configuration Manager task sequences.
- Configuration Manager software update capabilities (deploying like an update).
These upgrades (which are installed differently than monthly updates) use an in-place upgrade process. Unlike updates, which are relatively small, these upgrades include a full operating system image (around 3 GB for 64-bit operating systems), which requires time (1-2 hours) and disk space (approximately 10 GB) to complete. Ensure that the deployment method you use can support the required network bandwidth and/or disk space requirements.
The upgrade process is also optimized to reduce the overall time and network bandwidth consumed.
## Related articles
[Windows 10 infrastructure requirements](windows-10-infrastructure-requirements.md)

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

@ -1,150 +0,0 @@
### YamlMime:FAQ
metadata:
title: Windows 10 Enterprise FAQ for IT pros (Windows 10)
description: Get answers to common questions around compatibility, installation, and support for Windows 10 Enterprise.
keywords: Windows 10 Enterprise, download, system requirements, drivers, appcompat, manage updates, Windows as a service, servicing channels, deployment tools
ms.service: windows-client
ms.subservice: itpro-deploy
ms.mktglfcycl: plan
ms.localizationpriority: medium
ms.sitesec: library
ms.date: 10/28/2022
ms.reviewer:
author: frankroj
ms.author: frankroj
manager: aaroncz
audience: itpro
ms.topic: faq
title: 'Windows 10 Enterprise: FAQ for IT professionals'
summary: Get answers to common questions around compatibility, installation, and support for Windows 10 Enterprise.
sections:
- name: Download and requirements
questions:
- question: |
Where can I download Windows 10 Enterprise?
answer: |
If you have Windows volume licenses with Software Assurance, or if you have purchased licenses for Windows 10 Enterprise volume licenses, you can download 32-bit and 64-bit versions of Windows 10 Enterprise from the [Volume Licensing Service Center](https://www.microsoft.com/Licensing/servicecenter/default.aspx). If you don't have current Software Assurance for Windows and would like to purchase volume licenses for Windows 10 Enterprise, contact your preferred Microsoft Reseller or see [How to purchase through Volume Licensing](https://www.microsoft.com/Licensing/how-to-buy/how-to-buy.aspx).
- question: |
What are the system requirements?
answer: |
For details, see [Windows 10 Enterprise system requirements](https://www.microsoft.com/windows/Windows-10-specifications#areaheading-uid09f4).
- question: |
What are the hardware requirements for Windows 10?
answer: |
Most computers that are compatible with Windows 8.1 will be compatible with Windows 10. You may need to install updated drivers in Windows 10 for your devices to properly function. For more information, see [Windows 10 specifications](https://www.microsoft.com/windows/windows-10-specifications).
- question: |
Can I evaluate Windows 10 Enterprise?
answer: |
Yes, a 90-day evaluation of Windows 10 Enterprise is available through the [Evaluation Center](https://www.microsoft.com/evalcenter/evaluate-windows-10-enterprise). The evaluation is available in Chinese (Simplified), Chinese (Traditional), English, French, German, Italian, Japanese, Korean, Portuguese (Brazil), and Spanish (Spain, International Sort). We highly recommend that organizations make use of the Windows 10 Enterprise 90-day Evaluation to try out deployment and management scenarios, test compatibility with hardware and applications, and to get hands on experience with Windows 10 Enterprise features.
- name: Drivers and compatibility
questions:
- question: |
Where can I find drivers for my devices for Windows 10 Enterprise?
answer: |
For many devices, drivers will be automatically installed in Windows 10 and there will be no need for further action.
- 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 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](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?
answer: |
Many existing Win32 and Win64 applications already run reliably on Windows 10 without any changes. You can also expect strong compatibility and support for Web apps and devices.
- name: Administration and deployment
questions:
- question: |
Which deployment tools support Windows 10?
answer: |
Updated versions of Microsoft deployment tools, including Microsoft Configuration Manager, MDT, and the Windows Assessment and Deployment Kit (Windows ADK) support Windows 10.
- [Microsoft Configuration Manager](/mem/configmgr) simplifies the deployment and management of Windows 10. If you aren't currently using it, download a free 180-day trial of [Microsoft Configuration Manager (current branch)](https://www.microsoft.com/evalcenter/evaluate-microsoft-endpoint-configuration-manager).
- [MDT](/mem/configmgr/mdt) is a collection of tools, processes, and guidance for automating desktop and server deployment.
- The [Windows ADK](/windows-hardware/get-started/adk-install) has tools that allow you to customize Windows images for large-scale deployment, and test system quality and performance. You can download the latest version of the Windows ADK for Windows 10 from the Hardware Dev Center.
- question: |
Can I upgrade computers from Windows 7 or Windows 8.1 without deploying a new image?
answer: |
Computers running Windows 7 or Windows 8.1 can be upgraded directly to Windows 10 through the in-place upgrade process without a need to reimage the device. For more information, see [Upgrade to Windows 10 with Microsoft Configuration Manager](/previous-versions/windows/it-pro/windows-10/deployment/deploy-windows-cm/upgrade-to-windows-10-with-configuration-manager).
- question: |
Can I upgrade from Windows 7 Enterprise or Windows 8.1 Enterprise to Windows 10 Enterprise for free?
answer: |
If you have Windows 7 Enterprise or Windows 8.1 Enterprise and current Windows 10 Enterprise E3 or E5 subscription, you're entitled to the upgrade to Windows 10 Enterprise through the rights of Software Assurance. You can find your product keys and installation media at the [Volume Licensing Service Center](https://www.microsoft.com/Licensing/servicecenter/default.aspx).
For devices that are licensed under a volume license agreement for Windows that doesn't include Software Assurance, new licenses will be required to upgrade these devices to Windows 10.
- name: Managing updates
questions:
- question: |
What is Windows as a service?
answer: |
The Windows 10 operating system introduces a new way to build, deploy, and service Windows: Windows as a service. Microsoft has reimagined each part of the process, to simplify the lives of IT pros and maintain a consistent Windows 10 experience for its customers. These improvements focus on maximizing customer involvement in Windows development, simplifying the deployment and servicing of Windows client computers, and leveling out the resources needed to deploy and maintain Windows over time. For more information, see [Overview of Windows as a service](../update/waas-overview.md).
- question: |
How is servicing different with Windows as a service?
answer: |
Traditional Windows servicing has included several release types: major revisions (for example, Windows 8.1, Windows 8, and Windows 7 operating systems), service packs, and monthly updates. With Windows 10, there are two release types: feature updates that add new functionality two to three times per year, and quality updates that provide security and reliability fixes at least once a month.
- question: |
What are the servicing channels?
answer: |
To align with the new method of delivering feature updates and quality updates in Windows 10, Microsoft introduced the concept of servicing channels to allow customers to designate how aggressively their individual devices are updated. For example, an organization may have test devices that the IT department can update with new features as soon as possible, and then specialized devices that require a longer feature update cycle to ensure continuity. With that in mind, Microsoft offers two servicing channels for Windows 10: General Availability Channel, and Long-Term Servicing Channel (LTSC). For details about the versions in each servicing channel, see [Windows 10 release information](/windows/release-health/release-information). For more information on each channel, see [servicing channels](../update/waas-overview.md#servicing-channels).
- question: |
What tools can I use to manage Windows as a service updates?
answer: |
There are many available tools:
- Windows Update
- Windows Update for Business
- Windows Server Update Services
- Microsoft Configuration Manager
For more information, see [Servicing Tools](../update/waas-overview.md#servicing-tools).
- name: User experience
questions:
- question: |
Where can I find information about new features and changes in Windows 10 Enterprise?
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://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).
- question: |
How will people in my organization adjust to using Windows 10 Enterprise after upgrading from Windows 7 or Windows 8.1?
answer: |
Windows 10 combines the best aspects of the user experience from Windows 8.1 and Windows 7 to make using Windows simple and straightforward. Users of Windows 7 will find the Start menu in the same location as they always have. In the same place, users of Windows 8.1 will find the live tiles from their Start screen, accessible by the Start button in the same way as they were accessed in Windows 8.1.
- question: |
How does Windows 10 help people work with applications and data across various devices?
answer: |
The desktop experience in Windows 10 has been improved to provide a better experience for people that use a traditional mouse and keyboard. Key changes include:
- Start menu is a launching point for access to apps.
- Universal apps now open in windows instead of full screen.
- [Multitasking is improved with adjustable Snap](https://blogs.windows.com/windows-insider/2015/06/04/arrange-your-windows-in-a-snap/), which allows you to have more than two windows side-by-side on the same screen and to customize how those windows are arranged.
- Tablet Mode to simplify using Windows with a finger or pen by using touch input.
- name: Help and support
questions:
- question: |
Where can I ask a question about Windows 10?
answer: |
Use the following resources for additional information about Windows 10.
- [Microsoft Q&A](/answers/)
- [Microsoft Support Community](https://answers.microsoft.com/)

99
windows/deployment/planning/windows-10-infrastructure-requirements.md
View File

@ -1,99 +0,0 @@
---
title: Windows 10 infrastructure requirements (Windows 10)
description: Review the infrastructure requirements for deployment and management of Windows 10, prior to significant Windows 10 deployments within your organization.
manager: aaroncz
ms.author: frankroj
ms.service: windows-client
ms.localizationpriority: medium
author: frankroj
ms.topic: conceptual
ms.subservice: itpro-deploy
ms.date: 10/28/2022
---
# Windows 10 infrastructure requirements
**Applies to**
- Windows 10
There are specific infrastructure requirements that should be in place for the deployment and management of Windows 10. Fulfill these requirements before any Windows 10-related deployments take place.
## High-level requirements
For initial Windows 10 deployments, and for subsequent Windows 10 upgrades, ensure that sufficient disk space is available for distribution of the Windows 10 installation files (about 3 GB for Windows 10 x64 images, slightly smaller for x86). Also, be sure to take into account the network impact of moving these large images to each PC; you may need to use local server storage.
For persistent VDI environments, carefully consider the I/O impact from upgrading large numbers of PCs in a short period of time. Ensure that upgrades are performed in smaller numbers, or during off-peak time periods. (For pooled VDI environments, a better approach is to replace the base image with a new version.)
## Deployment tools
The latest version of the Windows Assessment and Deployment Toolkit (ADK) is available for download [here](/windows-hardware/get-started/adk-install).
Significant enhancements in the ADK for Windows 10 include new runtime provisioning capabilities, which use the Windows Imaging and Configuration Designer (Windows ICD). There's also updated versions of existing deployment tools (DISM, USMT, Windows PE, and more).
The latest version of the Microsoft Deployment Toolkit (MDT) is available for download [here](/mem/configmgr/mdt/release-notes).
For Configuration Manager, Windows 10 version specific support is offered with [various releases](/mem/configmgr/core/plan-design/configs/support-for-windows-10).
For more information about Microsoft Configuration Manager support for Windows 10, see [Prepare for Zero Touch Installation of Windows 10 with Configuration Manager](/previous-versions/windows/it-pro/windows-10/deployment/deploy-windows-cm/prepare-for-zero-touch-installation-of-windows-10-with-configuration-manager).
## Management tools
In addition to Microsoft Configuration Manager, Windows 10 also uses other tools for management. For Windows Server and Active Directory, existing supported versions are fully supported for Windows 10. New Group Policy templates will be needed to configure new settings available in Windows 10; these templates are available in the Windows 10 media images, and are available as a separate download [here](https://go.microsoft.com/fwlink/p/?LinkId=625081). See [Group Policy settings reference](https://go.microsoft.com/fwlink/p/?LinkId=625082) for a list of the new and modified policy settings. If you're using a central policy store, follow the steps outlined [here](/troubleshoot/windows-server/group-policy/create-central-store-domain-controller) to update the ADMX files stored in that central store.
No new Active Directory schema updates or specific functional levels are currently required for core Windows 10 product functionality, although subsequent upgrades could require these schema updates to support new features.
Microsoft Desktop Optimization Pack (MDOP) has been updated to support Windows 10. The minimum versions required to support Windows 10 are as follows:
| Product | Required version |
|----------------------------------------------------------|--------------------------|
| Advanced Group Policy Management (AGPM) | AGPM 4.0 Service Pack 3 |
| Application Virtualization (App-V) | App-V 5.1 |
| Diagnostics and Recovery Toolkit (DaRT) | DaRT 10 |
| Microsoft BitLocker Administration and Monitoring (MBAM) | MBAM 2.5 SP1 (2.5 is OK) |
| User Experience Virtualization (UE-V) | UE-V 2.1 SP1 |
For more information, see the [MDOP TechCenter](/microsoft-desktop-optimization-pack/).
For devices you manage with mobile device management (MDM) solutions such as Microsoft Intune, existing capabilities (provided initially in Windows 8.1) are fully supported in Windows 10. New Windows 10 MDM settings and capabilities will require updates to the MDM services. For more information, see [Mobile device management](/windows/client-management/mdm/).
Windows Server Update Services (WSUS) requires some more configuration to receive updates for Windows 10. Use the Windows Server Update Services admin tool and follow these instructions:
1. Select the **Options** node, and then select **Products and Classifications**.
2. In the **Products** tree, select the **Windows 10** and **Windows 10 LTSB** products and any other Windows 10-related items that you want. Select **OK**.
3. From the **Synchronizations** node, right-click and choose **Synchronize Now**.
![figure 1.](images/fig4-wsuslist.png)
WSUS product list with Windows 10 choices
Because Windows 10 updates are cumulative in nature, each month's new update will supersede the previous month's update. Consider using "express installation" packages to reduce the size of the payload that needs to be sent to each PC each month. For more information, see [Express installation files](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd939908(v=ws.10)).
> [!NOTE]
> The usage of "express installation" packages will increase the amount of disk storage needed by WSUS, and impacts all operating systems being managed with WSUS.
## Activation
Windows 10 volume license editions of Windows 10 will continue to support all existing activation methods (KMS, MAK, and AD-based activation). An update will be required for existing KMS servers:
| Product | Required update |
|----------------------------------------|---------------------------------------------------------------------------------------------|
| Windows 10 | None |
| Windows Server 2012 R2 and Windows 8.1 | [https://support.microsoft.com/kb/3058168](https://go.microsoft.com/fwlink/p/?LinkId=625087) |
| Windows Server 2012 and Windows 8 | [https://support.microsoft.com/kb/3058168](https://go.microsoft.com/fwlink/p/?LinkId=625087) |
| Windows Server 2008 R2 and Windows 7 | [https://support.microsoft.com/kb/3079821](https://support.microsoft.com/kb/3079821) |
Also see: [Windows Server 2016 Volume Activation Tips](/archive/blogs/askcore/windows-server-2016-volume-activation-tips)
Additionally, new product keys will be needed for all types of volume license activation (KMS, MAK, and AD-based Activation). These keys are available on the Volume Licensing Service Center (VLSC) for customers with rights to the Windows 10 operating system. To find the needed keys:
- Sign into the [Volume Licensing Service Center (VLSC)](https://go.microsoft.com/fwlink/p/?LinkId=625088) at with a Microsoft account that has appropriate rights.
- For KMS keys, select **Licenses** and then select **Relationship Summary**. Select the appropriate active license ID, and then select **Product Keys** near the right side of the page. For KMS running on Windows Server, find the **Windows Srv 2012R2 DataCtr/Std KMS for Windows 10** product key; for KMS running on client operating systems, find the **Windows 10** product key.
- For MAK keys, select **Downloads and Keys**, and then filter the list by using **Windows 10** as a product. Select the **Key** link next to an appropriate list entry (for example, **Windows 10 Enterprise** or **Windows 10 Enterprise LTSB**) to view the available MAK keys. (You can also find keys for KMS running on Windows 10 in this list. These keys won't work on Windows servers running KMS.)
Windows 10 Enterprise and Windows 10 Enterprise LTSC installations use different MAK keys. But you can use the same KMS server or Active Directory-based activation environment for both; the KMS keys obtained from the Volume Licensing Service Center will work with both.
## Related articles
[Windows 10 servicing options](../update/waas-servicing-strategy-windows-10-updates.md)<br>
[Windows 10 deployment considerations](windows-10-deployment-considerations.md)<br>

123
windows/deployment/update/deployment-service-overview.md
View File

@ -1,123 +0,0 @@
---
title: Overview of the deployment service
titleSuffix: Windows Update for Business deployment service
description: Overview of deployment service to control approval, scheduling, and safeguarding of Windows updates with the deployment service.
ms.service: windows-client
ms.subservice: itpro-updates
ms.topic: conceptual
ms.author: mstewart
author: mestew
manager: aaroncz
ms.collection:
- tier1
ms.localizationpriority: medium
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
ms.date: 02/14/2023
---
# Windows Update for Business deployment service
The Windows Update for Business deployment service is a cloud service within the Windows Update for Business product family. It's designed to work with your existing [Windows Update for Business](waas-manage-updates-wufb.md) policies and [Windows Update for Business reports](wufb-reports-overview.md). The deployment service provides control over the approval, scheduling, and safeguarding of updates delivered from Windows Update to managed devices. The service is privacy focused and backed by leading industry compliance certifications.
Windows Update for Business product family has three elements:
- Client policy to govern update experiences and timing, which are available through Group Policy and CSPs
- [Windows Update for Business reports](wufb-reports-overview.md) to monitor update deployment
- Deployment service APIs to approve and schedule specific updates for deployment, which are available through the Microsoft Graph and associated SDKs (including PowerShell)
The deployment service complements existing Windows Update for Business capabilities, including existing device policies and the [Windows Update for Business reports workbook](wufb-reports-workbook.md).
:::image type="content" source="media/7512398-deployment-service-overview.png" alt-text="Diagram displaying the three elements that are parts of the Windows Update for Business family.":::
## How the deployment service works
With most update management solutions, usually update policies are set on the client itself using either registry edits, Group Policy, or an MDM solution that leverages CSPs. This means that the end user experience and deployment settings for updates are ultimately determined by the individual device settings. However, with Windows Update for Business deployment service, the service is the central point of control for update deployment behavior. Because the deployment service is directly integrated with Windows Update, once the admin defines the deployment behavior, Windows Update is already aware of how device should be directed to install updates when the device scans. The deployment service creates a direct communication channel between a management tool (including scripting tools such as Windows PowerShell) and the Windows Update service so that the approval and offering of content can be directly controlled by an admin.
Using the deployment service typically follows a common pattern:
1. An admin uses a management tool to select devices and approve content to be deployed. This tool could be PowerShell, a Microsoft Graph app, or a more complete management solution such as Microsoft Intune.
2. The chosen management tool conveys your approval, scheduling, and device selection information to the deployment service.
3. The deployment service processes the content approval and compares it with previously approved content. Final update applicability is determined and conveyed to Windows Update, which then offers approved content to devices on their next check for updates.
:::image type="content" source="media/wufbds-interaction-small.png" alt-text="Diagram displaying ":::
The deployment service exposes these capabilities through Microsoft [Graph REST APIs](/graph/overview). You can call the APIs directly, through a Graph SDK, or integrate them with a management tool such as [Microsoft Intune](/mem/intune).
## Capabilities of the Windows Update for Business deployment service
The deployment service is designed for IT Pros who are looking for more control than is provided through deferral policies and deployment rings. The service provides the following capabilities for updates:
- **Approval and scheduling**: Approve and schedule deployment of updates to start on a specific date
- *Example*: Deploy the Windows 11 22H2 feature update to specified devices on February 17, 2023.
- **Gradual rollout**: Stage deployments over a period of days or weeks by specifying gradual rollout settings
- *Example*: Deploy the Windows 11 22H2 feature update to 500 devices per day, beginning on February 17, 2023
- **Expedite**: Bypass the configured Windows Update for Business policies to immediately deploy a security update across the organization
- **Safeguard holds**: Automatically holds the deployment for devices that may be impacted by an update issue identified by Microsoft machine-learning algorithms
Certain capabilities are available for specific update classifications:
|Capabilities | [Quality updates](deployment-service-expedited-updates.md) | [Feature updates](deployment-service-feature-updates.md) | [Drivers and firmware](deployment-service-drivers.md)|
|---|---|---|---|
|Approval and scheduling | | Yes | Yes |
|Gradual rollout | | Yes | |
|Expedite | Yes | | |
|Safeguard holds| | Yes | |
## Deployment protections
The deployment service protects deployments through a combination of rollout controls and machine-learning algorithms that monitor deployments and react to issues during the rollout.
### Gradual rollout
The deployment service allows any update to be deployed over a period of days or weeks. Once an update has been scheduled, the deployment service optimizes the deployment based on the scheduling parameters and unique attributes spanning the devices being updated. The service follows these steps:
1. Determine the number of devices to be updated in each deployment wave, based on scheduling parameters.
2. Select devices for each deployment wave so that earlier waves have a diversity of hardware and software, to function as pilot device populations.
3. Start deploying to earlier waves to build coverage of device attributes present in the population.
4. Continue deploying at a uniform rate until all waves are complete and all devices are updated.
This built-in piloting capability complements your existing [deployment ring](waas-quick-start.md) structure and provides another support for reducing and managing risk during an update. This capability is intended to operate within each ring. The deployment service doesn't provide a workflow for creating rings themselves. Continue to use deployment rings as part of the servicing strategy for your organization, but use gradual rollouts to add scheduling convenience and other protections within each ring.
### Safeguard holds against likely and known issues
Microsoft uses [safeguard holds](/windows/deployment/update/safeguard-holds) to protect devices from encountering known quality or compatibility issues by preventing them from installing the update or upgrade. For Windows 11 deployments, the deployment service also extends safeguard holds to protect devices that Microsoft identifies as being at a higher risk of experiencing problems after an update (such as operating system rollbacks, app crashes, or graphics issues). The service temporarily holds the deployment for these devices while Microsoft investigates the likely issue. Safeguard holds apply to deployments by default, but you can opt out. To verify whether a device is affected by a safeguard hold, see [Am I affected by a safeguard hold?](/windows/deployment/update/safeguard-holds#am-i-affected-by-a-safeguard-hold).
### Monitoring deployments to detect rollback issues
During deployments of Windows 11 or Windows 10 feature updates, driver combinations can sometimes result in an unexpected update failure that makes the device revert to the previously installed operating system version. The deployment service can monitor devices for such issues and automatically pause deployments when this happens, giving you time to detect and mitigate issues.
## Get started with the deployment service
To use the deployment service, you use a management tool built on the platform like Microsoft Intune, script common actions using PowerShell, or build your own application.
To learn more about the deployment service and the deployment process, see:
- [Prerequisites for Windows Update for Business deployment service](deployment-service-prerequisites.md)
- [Deploy feature updates using Graph Explorer](deployment-service-feature-updates.md)
- [Deploy expedited updates using Graph Explorer](deployment-service-expedited-updates.md)
- [Deploy driver and firmware updates using Graph Explorer](deployment-service-drivers.md)
### Scripting common actions using PowerShell
The Microsoft Graph SDK includes a PowerShell extension that you can use to script and automate common update actions. For more information, see [Get started with the Microsoft Graph PowerShell SDK](/graph/powershell/get-started).
### Building your own application
Microsoft Graph makes deployment service APIs available through. Get started with the resources below:
- Learning path: [Microsoft Graph Fundamentals](/training/paths/m365-msgraph-fundamentals/)
- Learning path: [Build apps with Microsoft Graph](/training/paths/m365-msgraph-associate/)
- Windows Update for Business deployment service [sample driver deployment application](https://github.com/microsoftgraph/windowsupdates-webapplication-sample) on GitHub
- [Windows updates API overview in Microsoft Graph](/graph/windowsupdates-concept-overview)
### Use Microsoft Intune
Microsoft Intune integrates with the deployment service to provide Windows client update management capabilities. For more information, see:
- [Feature updates for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-feature-updates)
- [Expedite Windows quality updates in Microsoft Intune](/mem/intune/protect/windows-10-expedite-updates)

116
windows/deployment/update/deployment-service-prerequisites.md
View File

@ -1,116 +0,0 @@
---
title: Prerequisites for the deployment service
titleSuffix: Windows Update for Business deployment service
description: Prerequisites for using the Windows Update for Business deployment service for updating devices in your organization.
ms.service: windows-client
ms.subservice: itpro-updates
ms.topic: conceptual
ms.author: mstewart
author: mestew
manager: aaroncz
ms.collection:
- tier1
ms.localizationpriority: medium
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
ms.date: 07/01/2024
---
# Windows Update for Business deployment service prerequisites
<!--7512398-->
Before you begin the process of deploying updates with Windows Update for Business deployment service, ensure you meet the prerequisites.
<a name='azure-and-azure-active-directory'></a>
## Azure and Microsoft Entra ID
- An Azure subscription with [Microsoft Entra ID](/azure/active-directory/)
- Devices must be Microsoft Entra joined and meet the below OS requirements.
- Devices can be [Microsoft Entra joined](/azure/active-directory/devices/concept-azure-ad-join) or [Microsoft Entra hybrid joined](/azure/active-directory/devices/concept-azure-ad-join-hybrid).
- Devices that are [Microsoft Entra registered](/azure/active-directory/devices/concept-azure-ad-register) only (Workplace joined) aren't supported with Windows Update for Business
## Licensing
Windows Update for Business deployment service requires users of the devices to have one of the following licenses:
- Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5)
- Windows 10/11 Education A3 or A5 (included in Microsoft 365 A3 or A5)
- Windows Virtual Desktop Access E3 or E5
- Microsoft 365 Business Premium
## Operating systems and editions
- Windows 11 Professional, Education, Enterprise, Pro Education, or Pro for Workstations editions
- Windows 10 Professional, Education, Enterprise, Pro Education, or Pro for Workstations editions
Windows Update for Business deployment service supports Windows client devices on the **General Availability Channel**.
### Windows operating system updates
- Expediting updates requires the *Update Health Tools* on the clients. The tools are installed starting with [KB4023057](https://support.microsoft.com/kb/4023057). To confirm the presence of the Update Health Tools on a device:
- Look for the folder **C:\Program Files\Microsoft Update Health Tools** or review *Add Remove Programs* for **Microsoft Update Health Tools**.
- As an Admin, run the following PowerShell script: `Get-CimInstance -ClassName Win32_Product | Where-Object {$_.Name -match "Microsoft Update Health Tools"}`
- For [Changes to Windows diagnostic data collection](/windows/privacy/changes-to-windows-diagnostic-data-collection#services-that-rely-on-enhanced-diagnostic-data), installing the January 2023 release preview cumulative update, or a later equivalent update, is recommended
## Diagnostic data requirements
Deployment scheduling controls are always available. However, to take advantage of the unique deployment protections tailored to your population and to [deploy driver updates](deployment-service-drivers.md), devices must share diagnostic data with Microsoft. For these features, at minimum, the deployment service requires devices to send [diagnostic data](/windows/privacy/configure-windows-diagnostic-data-in-your-organization#diagnostic-data-settings) at the *Required* level (previously called *Basic*) for these features.
When you use [Windows Update for Business reports](wufb-reports-overview.md) in conjunction with the deployment service, using diagnostic data at the following levels allows device names to appear in reporting:
- *Optional* level (previously *Full*) for Windows 11 devices
- *Enhanced* level for Windows 10 devices
## Permissions
- [Windows Update for Business deployment service](/graph/api/resources/adminwindowsupdates) operations require [WindowsUpdates.ReadWrite.All](/graph/permissions-reference#windows-updates-permissions)
- Some roles, such as the [Windows Update deployment administrator](/azure/active-directory/roles/permissions-reference#windows-update-deployment-administrator), already have the permissions.
> [!NOTE]
> Leveraging other parts of the Graph API might require additional permissions. For example, to display [device](/graph/api/resources/device) information, a minimum of [Device.Read.All](/graph/permissions-reference#device-permissions) permission is needed.
## Required endpoints
- Have access to the following endpoints:
- [Windows Update endpoints](/windows/privacy/manage-windows-1809-endpoints#windows-update)
- *.prod.do.dsp.mp.microsoft.com
- *.windowsupdate.com
- *.dl.delivery.mp.microsoft.com
- *.update.microsoft.com
- *.delivery.mp.microsoft.com
- tsfe.trafficshaping.dsp.mp.microsoft.com
- Windows Update for Business deployment service endpoints
- devicelistenerprod.microsoft.com
- devicelistenerprod.eudb.microsoft.com for the [EU Data Boundary](/privacy/eudb/eu-data-boundary-learn) <!--9131668-->
- login.windows.net
- payloadprod*.blob.core.windows.net
- [Windows Push Notification Services](/windows/uwp/design/shell/tiles-and-notifications/firewall-allowlist-config): *(Recommended, but not required. Without this access, devices might not expedite updates until their next daily check for updates.)*
- *.notify.windows.com
## Limitations
<!--Using include for deployment service limitations-->
[!INCLUDE [Windows Update for Business deployment service limitations](./includes/wufb-deployment-limitations.md)]
## Policy considerations for drivers
<!--Using include for Policy considerations for drivers-->
[!INCLUDE [Windows Update for Business deployment service driver policy considerations](./includes/wufb-deployment-driver-policy-considerations.md)]
## General tips for the deployment service
Follow these suggestions for the best results with the service:
- Wait until devices finish provisioning before managing with the service. If a device is being provisioned by Autopilot, it can only be managed by the deployment service after it finishes provisioning (typically one day).
- Use the deployment service for feature update management without feature update deferral policy. If you want to use the deployment service to manage feature updates on a device that previously used a feature update deferral policy, it's best to set the feature update deferral policy to **0** days to avoid having multiple conditions governing feature updates. You should only change the feature update deferral policy value to 0 days after you've confirmed that the device was enrolled in the service with no errors.
- Avoid using different channels to manage the same resources. If you use Microsoft Intune along with Microsoft Graph APIs or PowerShell, aspects of resources (such as devices, deployments, updatable asset groups) might be overwritten if you use both channels to manage the same resources. Instead, only manage each resource through the channel that created it.

63
windows/deployment/update/deployment-service-troubleshoot.md
View File

@ -1,63 +0,0 @@
---
title: Troubleshoot the deployment service
titleSuffix: Windows Update for Business deployment service
description: Solutions to commonly encountered problems when using the Windows Update for Business deployment service.
ms.service: windows-client
ms.subservice: itpro-updates
ms.topic: troubleshooting
ms.author: mstewart
author: mestew
manager: aaroncz
ms.collection:
- tier1
ms.localizationpriority: medium
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
ms.date: 02/14/2023
---
# Troubleshoot the Windows Update for Business deployment service
This troubleshooting guide addresses the most common issues that IT administrators face when using the Windows Update for Business [deployment service](deployment-service-overview.md). For a general troubleshooting guide for Windows Update, see [Windows Update troubleshooting](/troubleshoot/windows-client/deployment/windows-update-issues-troubleshooting?toc=/windows/deployment/toc.json&bc=/windows/deployment/breadcrumb/toc.json).
## The device isn't receiving an update that I deployed
- Check that the device doesn't have updates of the relevant category paused. See [Pause feature updates](waas-configure-wufb.md#pause-feature-updates) and [Pause quality updates](waas-configure-wufb.md#pause-quality-updates).
- **Feature updates only**: The device might have a safeguard hold applied for the given feature update version. For more about safeguard holds, see [Safeguard holds](safeguard-holds.md) and [Opt out of safeguard holds](safeguard-opt-out.md).
- Check that the deployment to which the device is assigned has the state *offering*. Deployments that have the states *paused* or *scheduled* won't deploy content to devices.
- Check that the device has scanned for updates and is scanning the Windows Update service. To learn more about scanning for updates, see [Scanning updates](how-windows-update-works.md#scanning-updates).
- **Feature updates only**: Check that the device is successfully enrolled in feature update management by the deployment service. A device that is successfully enrolled will be represented by a Microsoft Entra device resource with an update management enrollment for feature updates and have no Microsoft Entra device registration errors.
- **Expedited quality updates only**: Check that the device has the Update Health Tools installed (available for Windows 10 version 1809 or later in the update described in [KB 4023057 - Update for Windows 10 Update Service components](https://support.microsoft.com/topic/kb4023057-update-for-windows-10-update-service-components-fccad0ca-dc10-2e46-9ed1-7e392450fb3a), or a more recent quality update). The Update Health Tools are required for a device to receive an expedited quality update. On a device, the program can be located at **C:\\Program Files\\Microsoft Update Health Tools**. You can verify its presence by reviewing **Add or Remove Programs** or using the following PowerShell script: `Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -match "Microsoft Update Health Tools"}`.
## The device is receiving an update that I didn't deploy
- Check that the device is scanning the Windows Update service and not a different endpoint. If the device is scanning for updates from a WSUS endpoint, for example, it might receive different updates. To learn more about scanning for updates, see [Scanning updates](how-windows-update-works.md#scanning-updates).
- **Feature updates only**: Check that the device is successfully enrolled in feature update management by the deployment service. A device that is not successfully enrolled might receive different updates according to its feature update deferral period, for example. A device that is successfully enrolled will be represented by a Microsoft Entra device resource with an update management enrollment for feature updates and have no Microsoft Entra device registration errors.
### The device installed a newer update then the expedited update I deployed
There are some scenarios when a deployment to expedite an update results in the installation of a more recent update than specified in policy. This result occurs when the newer update includes and surpasses the specified update, and that newer update is available before a device checks in to install the update that's specified in the expedite update policy.
Installing the most recent quality update reduces disruptions to the device and user while applying the benefits of the intended update. This avoids having to install multiple updates, which each might require separate reboots.
A more recent update is deployed when the following conditions are met:
- The device isn't targeted with a deferral policy that blocks installation of a more recent update. In this case, the most recently available update that isn't deferred is the update that might install.
- During the process to expedite an update, the device runs a new scan that detects the newer update. This can occur due to the timing of:
- When the device restarts to complete installation
- When the device runs its daily scan
- When a new update becomes available
When a scan identifies a newer update, Windows Update attempts to stop installation of the original update, cancel the restart, and then starts the download and installation of the more recent update.
While expedite update deployments will override an update deferral for the update version that's specified, they don't override deferrals that are in place for any other update version.
<!--Using include for Update Health Tools log location-->
[!INCLUDE [Windows Update for Business deployment service permissions using Graph Explorer](./includes/wufb-deployment-update-health-tools-logs.md)]
## Policy considerations for drivers
<!--Using include for Policy considerations for drivers-->
[!INCLUDE [Windows Update for Business deployment service driver policy considerations](./includes/wufb-deployment-driver-policy-considerations.md)]

15
windows/deployment/update/includes/wufb-deployment-limitations.md
View File

@ -1,15 +0,0 @@
---
author: mestew
ms.author: mstewart
manager: aaroncz
ms.subservice: itpro-updates
ms.service: windows-client
ms.topic: include
ms.date: 02/14/2023
ms.localizationpriority: medium
---
<!--This file is shared by deployment-service-overview.md and the deployment-service-prerequisites.md articles. Headings may be driven by article context. 7512398 -->
Windows Update for Business deployment service is a Windows service hosted in Azure Commercial that uses Windows diagnostic data. While customers with GCC tenants may choose to use it, the Windows Update for Business deployment service is outside the [US Government community compliance (GCC)](/office365/servicedescriptions/office-365-platform-service-description/office-365-us-government/gcc#us-government-community-compliance) boundary. For a list of GCC offerings for Microsoft products and services, see the [Microsoft Trust Center](/compliance/regulatory/offering-home).
Windows Update for Business deployment service isn't available in Azure Government for [Office 365 GCC High and DoD](/office365/servicedescriptions/office-365-platform-service-description/office-365-us-government/gcc-high-and-dod) tenants.

2
windows/deployment/update/safeguard-holds.md
View File

@ -27,7 +27,7 @@ The safeguard holds lifespan varies depending on the time required to investigat
Safeguard holds only affect devices that use the Windows Update service for updates. We encourage IT admins who manage updates to devices through other channels (such as media installations or updates coming from Windows Server Update Services) to remain aware of known issues that might also be present in their environments.
IT admins managing updates using the [Windows Update for Business deployment service](/windows/deployment/update/deployment-service-overview) also benefit from safeguard holds on devices that are likely to be affected by an issue. To learn more, see [Safeguard holds against likely and known issues](/windows/deployment/update/deployment-service-overview#safeguard-holds-against-likely-and-known-issues).
IT admins managing updates using [Windows Autopatch](/windows/deployment/windows-autopatch/overview/windows-autopatch-overview) also benefit from safeguard holds on devices that are likely to be affected by an issue. To learn more, see [Safeguard holds against likely and known issues](/windows/deployment/update/deployment-service-overview#safeguard-holds-against-likely-and-known-issues).
## Am I affected by a safeguard hold?

2
windows/deployment/update/waas-manage-updates-wufb.md
View File

@ -142,4 +142,4 @@ The following services are part of the Windows Update for Business product famil
- Report on devices with update compliance issues
- Analyze and display your data in multiple ways
- The [Windows Update for Business deployment service](deployment-service-overview.md) is a cloud service designed to work with your existing Windows Update for Business policies and Windows Update for Business reports. The deployment service provides additional control over the approval, scheduling, and safeguarding of updates delivered from Windows Update to managed devices.
- [Windows Autopatch](/windows/deployment/windows-autopatch/overview/windows-autopatch-overview) is a cloud service designed to work with your existing Windows Update for Business policies. Windows Autopatch provides additional control over the approval, scheduling, and safeguarding of updates delivered from Windows Update to managed devices.

6
windows/deployment/update/waas-wu-settings.md
View File

@ -14,7 +14,7 @@ ms.localizationpriority: medium
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
ms.date: 04/29/2024
ms.date: 09/03/2024
---
# Manage additional Windows Update settings
@ -103,9 +103,9 @@ By enabling the Group Policy setting under **Computer Configuration\Administrati
### Do not connect to any Windows Update Internet locations
Even when Windows Update is configured to receive updates from an intranet update service, it will periodically retrieve information from the public Windows Update service to enable future connections to Windows Update, and other services like Microsoft Update, the Microsoft Store, or the Microsoft Store for Business.
Even when Windows Update is configured to receive updates from an intranet update service, it will periodically retrieve information from the public Windows Update service to enable future connections to Windows Update, and other services like Microsoft Update or the Microsoft Store.
Use **Computer Configuration\Administrative Templates\Windows Components\Windows update\Do not connect to any Windows Update Internet locations** to enable this policy. When enabled, this policy will disable the functionality described above, and may cause connection to public services such as the Microsoft Store, Microsoft Store for Business, Windows Update for Business, and Delivery Optimization to stop working.
Use **Computer Configuration\Administrative Templates\Windows Components\Windows update\Do not connect to any Windows Update Internet locations** to enable this policy. When enabled, this policy will disable the functionality described above, and may cause connection to public services such as the Microsoft Store, Windows Update for Business, and Delivery Optimization to stop working.
>[!NOTE]
>This policy applies only when the device is configured to connect to an intranet update service using the "Specify intranet Microsoft update service location" policy.

4
windows/deployment/update/wufb-reports-do.md
View File

@ -12,7 +12,7 @@ ms.localizationpriority: medium
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
ms.date: 04/12/2023
ms.date: 09/03/2024
---
# Delivery Optimization data in Windows Update for Business reports
@ -154,7 +154,7 @@ There are many Microsoft [content types](waas-delivery-optimization.md#types-of-
| Content Category | Content Types Included |
| --- | --- |
| Apps | Windows 10 Store apps, Windows 10 Store for Business apps, Windows 11 UWP Store apps |
| Apps | Windows 10 Store apps, Windows 11 UWP Store apps |
| Driver Updates | Windows Update [Driver updates](get-started-updates-channels-tools.md#types-of-updates) |
| Feature Updates | Windows Update [Feature updates](get-started-updates-channels-tools.md#types-of-updates) |
| Office | Microsoft 365 Apps and updates |

1
windows/deployment/update/wufb-reports-overview.md
View File

@ -27,7 +27,6 @@ Windows Update for Business reports is a cloud-based solution that provides info
Some of the benefits of Windows Update for Business reports are:
- Integration with [Windows Update for Business deployment service](deployment-service-overview.md) to enable per deployment reporting, monitoring, and troubleshooting.
- Compatibility with [feature updates](/mem/intune/protect/windows-10-feature-updates) and [Expedite Windows quality updates](/mem/intune/protect/windows-10-expedite-updates) policies in Intune.
- A new **Alerts** data type to assist you with identifying devices that encounter issues during the update process. Error code information is provided to help troubleshoot update issues.

2
windows/deployment/update/wufb-reports-prerequisites.md
View File

@ -27,7 +27,7 @@ Before you begin the process of adding Windows Update for Business reports to yo
- Devices can be [Microsoft Entra joined](/azure/active-directory/devices/concept-azure-ad-join) or [Microsoft Entra hybrid joined](/azure/active-directory/devices/concept-azure-ad-join-hybrid).
- Devices that are [Microsoft Entra registered](/azure/active-directory/devices/concept-azure-ad-register) only (workplace joined) aren't supported with Windows Update for Business reports.
- The Log Analytics workspace must be in a [supported region](#log-analytics-regions).
- Data in the **Driver update** tab of the [workbook](wufb-reports-workbook.md) is only available for devices that receive driver and firmware updates from the [Windows Update for Business deployment service](deployment-service-overview.md).
- Data in the **Driver update** tab of the [workbook](wufb-reports-workbook.md) is only available for devices that receive driver and firmware updates from [Windows Autopatch](/windows/deployment/windows-autopatch/overview/windows-autopatch-overview).
## Permissions

12
windows/deployment/update/wufb-reports-schema-enumerated-types.md
View File

@ -75,9 +75,9 @@ Compliance status
|Value | Description |
|---|---|
| **Compliant** | The latest deployment from the Windows Update for Business deployment service is installed on the client |
| **NotCompliant** | The latest deployment from the Windows Update for Business deployment service isn't installed on the client|
| **NotApplicable** | Client isn't part of any Windows Update for Business deployment service deployments |
| **Compliant** | The latest deployment from Windows Autopatch is installed on the client |
| **NotCompliant** | The latest deployment from Windows Autopatch isn't installed on the client|
| **NotApplicable** | Client isn't part of any Windows Autopatch deployments |
## OSServicingChannel
@ -98,7 +98,7 @@ High-level service state OSServicingChannel
|Value | Description |
|---|---|
| **Pending** | Windows Update for Business deployment service isn't targeting this update to this device because the update isn't ready. |
| **Pending** | Windows Autopatch isn't targeting this update to this device because the update isn't ready. |
| **Offering** | Service is offering the update to the device. The update is available for the device to get if it scans Windows Update. |
| **OnHold** | Service is holding off on offering update to the device indefinitely. Until either the service or admin changes some condition, devices remain in this state. |
| **Canceled** | Service canceled offering update to the device, and the device is confirmed to not be installing the update. |
@ -207,9 +207,9 @@ Type of alert.
|Value | Description |
|---|---|
| **ServiceUpdateAlert** | Alert is relevant to Windows Update for Business deployment service's offering of the content to the client. |
| **ServiceUpdateAlert** | Alert is relevant to Windows Autopatch's offering of the content to the client. |
| **ClientUpdateAlert** | Alert is relevant to client's ability to progress through the installation of the update content. |
| **ServiceDeviceAlert** | Alert is relevant to device's status within Windows Update for Business deployment service |
| **ServiceDeviceAlert** | Alert is relevant to device's status within Windows Autopatch |
| **ClientDeviceAlert** | Alert is relevant to device's state |
| **DeploymentAlert** | Alert is relevant to an entire deployment, or a significant number of devices in the deployment. |

6
windows/deployment/update/wufb-reports-schema-ucclient.md
View File

@ -39,15 +39,15 @@ UCClient acts as an individual device's record. It contains data such as the cur
| **OSBuild** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `10.0.22621.1702` | The full operating system build installed on this device, such as Major.Minor.Build.Revision |
| **OSBuildNumber** | [int](/azure/kusto/query/scalar-data-types/int) | No | `22621` | The major build number, in int format, the device is using. |
| **OSEdition** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `Professional` | The Windows edition |
| **OSFeatureUpdateComplianceStatus** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `Compliant` | Whether the device is on the latest feature update that's offered from the Windows Update for Business deployment service, else NotApplicable. |
| **OSFeatureUpdateComplianceStatus** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `Compliant` | Whether the device is on the latest feature update that's offered from Windows Autopatch, else NotApplicable. |
| **OSFeatureUpdateEOSTime [UTC]** | [datetime](/azure/kusto/query/scalar-data-types/datetime) | No | `2020-05-14 09:26:03.478039` | The end of service date of the feature update currently installed on the device. |
| **OSFeatureUpdateReleaseTime [UTC]** | [datetime](/azure/kusto/query/scalar-data-types/datetime) | No | `2020-05-14 09:26:03.478039` | The release date of the feature update currently installed on the device. |
| **OSFeatureUpdateStatus** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `InService;EndOfService` | Whether the device is on the latest available feature update, for its feature update. |
| **OSQualityUpdateComplianceStatus** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `NotCompliant` | Whether the device is on the latest quality update that's offered from the Windows Update for Business deployment service, else NotApplicable. |
| **OSQualityUpdateComplianceStatus** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `NotCompliant` | Whether the device is on the latest quality update that's offered from Windows Autopatch, else NotApplicable. |
| **OSQualityUpdateReleaseTime [UTC]** | [datetime](/azure/kusto/query/scalar-data-types/datetime) | No | `2020-05-14 09:26:03.478039` | The release date of the quality update currently installed on the device. |
| **OSQualityUpdateStatus** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `Latest;NotLatest` | Whether the device is on the latest available quality update, for its feature update. |
| **OSRevisionNumber** | [int](/azure/kusto/query/scalar-data-types/int) | No | `836` | The revision, in int format, this device is on. |
| **OSSecurityUpdateComplianceStatus** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `NotCompliant` | Whether the device is on the latest security update (quality update where the Classification=Security) that's offered from the Windows Update for Business deployment service, else NotApplicable. |
| **OSSecurityUpdateComplianceStatus** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `NotCompliant` | Whether the device is on the latest security update (quality update where the Classification=Security) that's offered from Windows Autopatch, else NotApplicable. |
| **OSSecurityUpdateStatus** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `Latest;NotLatest;MultipleSecurityUpdatesMissing` | Whether the device is on the latest available security update, for its feature update. |
| **OSServicingChannel** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `SAC` | The elected Windows 10 servicing channel of the device. |
| **OSVersion** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `1909` | The Windows 10 operating system version currently installed on the device, such as 19H2, 20H1, 20H2. |

2
windows/deployment/update/wufb-reports-schema-ucclientupdatestatus.md
View File

@ -25,7 +25,7 @@ Update Event that combines the latest client-based data with the latest service-
|---|---|---|---|---|
| **AzureADDeviceId** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `71db1a1a-f1a6-4a25-b88f-79c2f513dae0` | Microsoft Entra Device ID |
| **AzureADTenantId** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `69ca04b0-703d-4b3a-9184-c4e3c15d6f5e` | Microsoft Entra tenant ID |
| **CatalogId** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `b0f410599615e2ce15e6614ac3fc4ec62d80324020351e172edef89091a64f2f` | This field applies to drivers only. The Catalog ID of the update from Windows Update for Business deployment service. |
| **CatalogId** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `b0f410599615e2ce15e6614ac3fc4ec62d80324020351e172edef89091a64f2f` | This field applies to drivers only. The Catalog ID of the update from Windows Autopatch. |
| **ClientState** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `Installing` | This field applies to drivers only. Higher-level bucket of ClientSubstate. |
| **ClientSubstate** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `DownloadStart` | Last-known state of this update relative to the device, from the client. |
| **ClientSubstateRank** | [int](/azure/kusto/query/scalar-data-types/int) | No | `2300` | Ranking of client substates for sequential ordering in funnel-type views. The rankings between ServiceSubstate and ClientSubstate can be used together. |

2
windows/deployment/update/wufb-reports-schema-ucdevicealert.md
View File

@ -16,7 +16,7 @@ ms.date: 12/06/2023
# UCDeviceAlert
<!--37063317, 30141258, 37063041-->
These alerts are activated as a result of an issue that is device-specific. It isn't specific to the combination of a specific update and a specific device. Like UpdateAlerts, the AlertType indicates where the Alert comes from (ServiceDeviceAlert, ClientDeviceAlert). For example, an EndOfService alert is a ClientDeviceAlert, as a build no longer being serviced (EOS) is a client-wide state. Meanwhile, DeviceRegistrationIssues in the Windows Update for Business deployment service will be a ServiceDeviceAlert, as it's a device-wide state in the service to not be correctly registered.
These alerts are activated as a result of an issue that is device-specific. It isn't specific to the combination of a specific update and a specific device. Like UpdateAlerts, the AlertType indicates where the Alert comes from (ServiceDeviceAlert, ClientDeviceAlert). For example, an EndOfService alert is a ClientDeviceAlert, as a build no longer being serviced (EOS) is a client-wide state. Meanwhile, DeviceRegistrationIssues in Windows Autopatch will be a ServiceDeviceAlert, as it's a device-wide state in the service to not be correctly registered.
## Schema for UCDeviceAlert
<!--8506381-->

2
windows/deployment/update/wufb-reports-schema-ucserviceupdatestatus.md
View File

@ -24,7 +24,7 @@ Update Event that comes directly from the service-side. The event has only servi
|---|---|---|---|---|
| **AzureADDeviceId** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `71db1a1a-f1a6-4a25-b88f-79c2f513dae0` | Microsoft Entra Device ID |
| **AzureADTenantId** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `69ca04b0-703d-4b3a-9184-c4e3c15d6f5e` | Microsoft Entra tenant ID |
| **CatalogId** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `b0f410599615e2ce15e6614ac3fc4ec62d80324020351e172edef89091a64f2f` | This field applies to drivers only. The Catalog ID of the update from Windows Update for Business deployment service. |
| **CatalogId** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `b0f410599615e2ce15e6614ac3fc4ec62d80324020351e172edef89091a64f2f` | This field applies to drivers only. The Catalog ID of the update from Windows Autopatch. |
| **DeploymentApprovedTime [UTC]** | [datetime](/azure/kusto/query/scalar-data-types/datetime) | No | `2020-05-14 09:26:03.478039` | This field applies to drivers only. Date and time of the update approval |
| **DeploymentId** | [string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `cf1b12a3-3d84-4ce3-bc8e-de48459e252d` | If this DeviceUpdateEvent is from content deployed by a deployment scheduler service policy, this GUID maps to that policy, otherwise it's empty. |
| **DeploymentIsExpedited** | [bool](/azure/data-explorer/kusto/query/scalar-data-types/bool) | No | `1` | Currently, data isn't gathered to populate this field. It indicated whether the content is being expedited |

2
windows/deployment/update/wufb-reports-schema-ucupdatealert.md
View File

@ -31,7 +31,7 @@ Alert for both client and service updates. Contains information that needs atten
| **AlertType** |[string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `ClientUpdateAlert` | The type of alert such as ClientUpdateAlert or ServiceUpdateAlert. Indicates which fields are present. |
| **AzureADDeviceId** |[string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `71db1a1a-f1a6-4a25-b88f-79c2f513dae0` | Microsoft Entra Device ID |
| **AzureADTenantId** |[string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `69ca04b0-703d-4b3a-9184-c4e3c15d6f5e` | Microsoft Entra tenant ID |
| **CatalogId** |[string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `b0f410599615e2ce15e6614ac3fc4ec62d80324020351e172edef89091a64f2f` | This field applies to drivers only. The Catalog ID of the update from Windows Update for Business deployment service. |
| **CatalogId** |[string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `b0f410599615e2ce15e6614ac3fc4ec62d80324020351e172edef89091a64f2f` | This field applies to drivers only. The Catalog ID of the update from Windows Autopatch. |
| **ClientSubstate** |[string](/azure/data-explorer/kusto/query/scalar-data-types/string) | Yes | `DownloadStart` | If the alert is from the client, the ClientSubstate at the time this alert was activated or updated, else empty. |
| **ClientSubstateRank** |[int](/azure/kusto/query/scalar-data-types/int) | No | `2300` | Rank of ClientSubstate |
| **DeploymentId** |[string](/azure/data-explorer/kusto/query/scalar-data-types/string) | No | `cf1b12a3-3d84-4ce3-bc8e-de48459e252d` | The deployment this alert is relative to, if there's one. |

8
windows/deployment/update/wufb-reports-workbook.md
View File

@ -75,7 +75,7 @@ The **Quality updates** tab displays generalized data at the top by using tiles.
| **Missing one security update** | Count of devices that haven't installed the latest security update.| - Select **View details** to display a flyout with a chart that displays the first 1000 items. </br> - Select `...` from the flyout to export the full list, or display the query in [Log Analytics](/azure/azure-monitor/logs/log-analytics-tutorial).|
| **Missing multiple security updates** | Count of devices that are missing two or more security updates. | - Select **View details** to display a flyout with a chart that displays the first 1000 items. </br> - Select `...` from the flyout to export the full list, or display the query in [Log Analytics](/azure/azure-monitor/logs/log-analytics-tutorial). |
| **Active alerts** | Count of active update and device alerts for quality updates. | |
| **Expedite status** | Overview of the progress for the expedited deployments of the latest security update. | Select **View details** to display a flyout with two tabs: **Deployments** and **Readiness** </br> </br> - The **Deployments** tab contins a chart that displays the total progress of each deployment, number of alerts, and count of devices. <ul><li> Select the count from the **Alerts** column to display the alerts, by name, for the deployment. Selecting the device count for the alert name displays a list of devices with the alert.</li><li> Select the count in the **TotalDevices** column to display a list of clients and their information for the deployment. <!--7626683--> </li></ul> </br> - The **Readiness** tab contains a chart that displays the number of devices that are **Eligible** and **Ineligible** to install expedited udpates. The **Readiness** tab also contains a table listing the deployments for expedited updates. <!--8682382--> <ul><li> Select the count from the **Alerts** column to display devices with a status of **RegistrationMissingUpdateClient**, which means the device is missing the Update Health Tools. The Update Health Tools are installed starting with [KB4023057](https://support.microsoft.com/kb/4023057) or from a [stand-alone package from the Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=103324). Example PowerShell script to verify tools installation: `Get-CimInstance -ClassName Win32_Product \| Where-Object {$_.Name -match "Microsoft Update Health Tools"}` </li><li> Select the count of **TotalDevices** to display a list of devices in the deployment. <!--8682382-->|
| **Expedite status** | Overview of the progress for the expedited deployments of the latest security update. | Select **View details** to display a flyout with two tabs: **Deployments** and **Readiness** </br> </br> - The **Deployments** tab contains a chart that displays the total progress of each deployment, number of alerts, and count of devices. <ul><li> Select the count from the **Alerts** column to display the alerts, by name, for the deployment. Selecting the device count for the alert name displays a list of devices with the alert.</li><li> Select the count in the **TotalDevices** column to display a list of clients and their information for the deployment. <!--7626683--> </li></ul> </br> - The **Readiness** tab contains a chart that displays the number of devices that are **Eligible** and **Ineligible** to install expedited updates. The **Readiness** tab also contains a table listing the deployments for expedited updates. <!--8682382--> <ul><li> Select the count from the **Alerts** column to display devices with a status of **RegistrationMissingUpdateClient**, which means the device is missing the Update Health Tools. The Update Health Tools are installed starting with [KB4023057](https://support.microsoft.com/kb/4023057) or from a [stand-alone package from the Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=103324). Example PowerShell script to verify tools installation: `Get-CimInstance -ClassName Win32_Product \| Where-Object {$_.Name -match "Microsoft Update Health Tools"}` </li><li> Select the count of **TotalDevices** to display a list of devices in the deployment. <!--8682382-->|
Below the tiles, the **Quality updates** tab is subdivided into **Update status** and **Device status** groups. These different chart groups allow you to easily discover trends in compliance data. For instance, you may remember that about third of your devices were in the installing state yesterday, but this number didn't change as much as you were expecting. That unexpected trend may cause you to investigate and resolve a potential issue before end users are impacted.
@ -142,11 +142,11 @@ The **Device status** group for feature updates contains the following items:
## Driver updates tab
The **Driver update** tab provides information on driver and firmware update deployments from [Windows Update for Business deployment service](deployment-service-overview.md). Generalized data is at the top of the page in tiles. The data becomes more specific as you navigate lower in this tab. The top of the driver updates tab contains tiles with the following information:
The **Driver update** tab provides information on driver and firmware update deployments from [Windows Autopatch](/windows/deployment/windows-autopatch/overview/windows-autopatch-overview). Generalized data is at the top of the page in tiles. The data becomes more specific as you navigate lower in this tab. The top of the driver updates tab contains tiles with the following information:
**Devices taking driver updates**: Count of devices that are installing driver and firmware updates.
**Approved updates**: Count of approved driver updates
**Total policies**: The total number of deployment polices for driver and firmware updates from [Windows Update for Business deployment service](deployment-service-overview.md)
**Total policies**: The total number of deployment polices for driver and firmware updates from [Windows Autopatch](/windows/deployment/windows-autopatch/overview/windows-autopatch-overview)
**Active alerts**: Count of active alerts for driver deployments
Selecting **View details** on any of the tiles displays a flyout with a chart that displays the first 1000 items. Select `...` from the flyout to export the full list, or display the query in [Log Analytics](/azure/azure-monitor/logs/log-analytics-tutorial).
@ -199,7 +199,7 @@ Updates can go though many phases from when they're initially deployed to being
- **Offering**: The update is being offered to the device for installation
- **Installing**: The update is in the process of being installed on the device
- **Installed**: The update has been installed on the device
- **Cancelled**: The update was cancelled from the [deployment service](deployment-service-overview.md) before it was installed
- **Canceled**: The update was canceled from the [deployment service](deployment-service-overview.md) before it was installed
- **Uninstalled**: The update was uninstalled from the device by either an admin or a user
- **OnHold**: The update was put on hold from the [deployment service](deployment-service-overview.md) before it was installed
- **Unknown**: This state occurs when there's a record for the device in the [UCClient](wufb-reports-schema-ucclient.md) table, but there isn't a record for the specific update for the specific device in the [UCClientUpdateStatus](wufb-reports-schema-ucclientupdatestatus.md) table. This means that there is no record of the update for the device in question.

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

@ -6,12 +6,8 @@
items:
- name: What is Windows Autopatch?
href: overview/windows-autopatch-overview.md
- name: Roles and responsibilities
href: overview/windows-autopatch-roles-responsibilities.md
- name: Privacy
href: overview/windows-autopatch-privacy.md
- name: Deployment guide
href: overview/windows-autopatch-deployment-guide.md
- name: FAQ
href: overview/windows-autopatch-faq.yml
- name: Prepare
@ -21,13 +17,9 @@
href: prepare/windows-autopatch-prerequisites.md
- name: Configure your network
href: prepare/windows-autopatch-configure-network.md
- name: Enroll your tenant
- name: Start using Windows Autopatch
href: prepare/windows-autopatch-feature-activation.md
items:
- name: Fix issues found by the Readiness assessment tool
href: prepare/windows-autopatch-fix-issues.md
- name: Submit a tenant enrollment support request
href: prepare/windows-autopatch-enrollment-support-request.md
- name: Deploy
href:
items:
@ -47,15 +39,24 @@
- name: Manage
href:
items:
- name: Manage Windows Autopatch groups
- name: Release schedule
href: manage/windows-autopatch-release-schedule.md
- name: Update rings
href: manage/windows-autopatch-update-rings.md
- name: Windows Autopatch groups
href: manage/windows-autopatch-manage-autopatch-groups.md
- name: Customize Windows Update settings
href: manage/windows-autopatch-customize-windows-update-settings.md
items:
- name: Customize Windows Update settings
href: manage/windows-autopatch-customize-windows-update-settings.md
- name: Windows Autopatch group policies
href: manage/windows-autopatch-groups-policies.md
- name: Windows feature updates
href: manage/windows-autopatch-windows-feature-update-overview.md
items:
- name: Manage Windows feature updates
href: manage/windows-autopatch-manage-windows-feature-update-releases.md
- name: Windows feature update policies
href: manage/windows-autopatch-windows-feature-update-policies.md
- name: Programmatic controls for Windows feature updates
href: manage/windows-autopatch-windows-feature-update-programmatic-controls.md
- name: Windows quality updates
href: manage/windows-autopatch-windows-quality-update-overview.md
items:
@ -65,8 +66,13 @@
href: manage/windows-autopatch-windows-quality-update-communications.md
- name: Windows quality update policies
href: manage/windows-autopatch-windows-update-policies.md
- name: Manage driver and firmware updates
- name: Programmatic controls for expedited Windows quality updates
href: manage/windows-autopatch-windows-quality-update-programmatic-controls.md
- name: Driver and firmware updates
href: manage/windows-autopatch-manage-driver-and-firmware-updates.md
items:
- name: Programmatic controls for driver and firmware updates
hreF: manage/windows-autopatch-driver-and-firmware-update-programmatic-controls.md
- name: Microsoft 365 Apps for enterprise
href: manage/windows-autopatch-microsoft-365-apps-enterprise.md
items:
@ -80,8 +86,10 @@
href: manage/windows-autopatch-support-request.md
- name: Exclude a device
href: manage/windows-autopatch-exclude-device.md
- name: Unenroll your tenant
- name: Deactivate Windows Autopatch features
href: manage/windows-autopatch-feature-deactivation.md
- name: Troubleshoot programmatic controls
href: manage/windows-autopatch-troubleshoot-programmatic-controls.md
- name: Monitor
href:
items:
@ -124,7 +132,7 @@
items:
- name: Conflicting configurations
href: references/windows-autopatch-conflicting-configurations.md
- name: Changes made at tenant enrollment
- name: Changes made at feature activation
href: references/windows-autopatch-changes-made-at-feature-activation.md
- name: What's new
href:

28
windows/deployment/windows-autopatch/deploy/windows-autopatch-admin-contacts.md
View File

@ -1,34 +1,34 @@
---
title: Add and verify admin contacts
description: This article explains how to add and verify admin contacts
ms.date: 07/08/2024
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
ms.topic: concept-article
ms.localizationpriority: medium
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.reviewer: hathind
ms.collection:
- tier2
- highpri
- tier1
---
# Add and verify admin contacts
There are several ways that Windows Autopatch service communicates with customers. To streamline communication and ensure we're checking with the right people when you [submit a support request](../operate/windows-autopatch-support-request.md), you must provide a set of admin contacts when you onboard with Windows Autopatch.
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
> [!IMPORTANT]
> You might have already added these contacts in the Microsoft Intune admin center during the [enrollment process](../prepare/windows-autopatch-enroll-tenant.md#step-4-enroll-your-tenant), or if you've [submitted a tenant enrollment support request](../prepare/windows-autopatch-enrollment-support-request.md). However, take a moment to double-check that the contact list is accurate, since the Windows Autopatch Service Engineering Team must be able to reach them if a severe incident occurs.
There are several ways that Windows Autopatch service communicates with customers. To streamline communication and ensure we're checking with the right people when you [submit a support request](../manage/windows-autopatch-support-request.md), you must provide a set of admin contacts when you onboard with Windows Autopatch.
You must have an admin contact for each specified area of focus. The Windows Autopatch Service Engineering Team will contact these individuals for assistance with your support request. Admin contacts should be the best person or group that can answer questions and make decisions for different [areas of focus](#area-of-focus).
You must have an admin contact for each specified area of focus. The Windows Autopatch Service Engineering Team contacts these individuals for assistance with your support request. Admin contacts should be the best person or group that can answer questions and make decisions for different [areas of focus](#area-of-focus).
> [!IMPORTANT]
> Whoever you choose as admin contacts, they must have the knowledge and authority to make decisions for your Windows Autopatch environment. The Windows Autopatch Service Engineering Team will contact these admin contacts for questions involving support requests.
## Area of focus
Your admin contacts will receive notifications about support request updates and new messages. These areas include the following:
Our admin contacts receive notifications about support request updates and new messages. These areas include the following areas of focus:
| Area of focus | Description |
| ----- | ----- |
@ -38,9 +38,9 @@ Your admin contacts will receive notifications about support request updates and
**To add admin contacts:**
1. Sign into the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Under **Tenant administration** in the **Windows Autopatch** section, select **Admin contacts**.
1. Select **+Add**.
1. Enter the contact details including name, email, phone number and preferred language. For a support ticket, the ticket's primary contact's preferred language will determine the language used for email communications.
1. Select an [Area of focus](#area-of-focus) and enter details of the contact's knowledge and authority in the specified area of focus.
1. Select **Save** to add the contact.
1. Repeat for each area of focus.
2. Under **Tenant administration** in the **Windows Autopatch** section, select **Admin contacts**.
3. Select **+Add**.
4. Enter the contact details including name, email, phone number, and preferred language. For a support ticket, the ticket's primary contact's preferred language determines the language used for email communications.
5. Select an [Area of focus](#area-of-focus) and enter details of the contact's knowledge and authority in the specified area of focus.
6. Select **Save** to add the contact.
7. Repeat for each area of focus.

158
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 an overview on how to register devices in Autopatch.
ms.date: 02/15/2024
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: concept-article
@ -17,7 +17,22 @@ ms.collection:
# Device registration overview
Windows Autopatch must [register your existing devices](windows-autopatch-register-devices.md) into its service to manage update deployments on your behalf.
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
Windows Autopatch must [register your existing devices](../deploy/windows-autopatch-register-devices.md) into its service to manage update deployments on your behalf.
## Prerequisites for device registration
### Built-in roles required for device registration
A role defines the set of permissions granted to users assigned to that role. You can use the Intune Service Administrator role to register devices. For more information, see [Required Intune permissions](../prepare/windows-autopatch-prerequisites.md#required-intune-permissions).
### Software prerequisites
To be eligible for Windows Autopatch management, devices must meet a minimum set of required software-based prerequisites. For more information, see [Windows Autopatch prerequisites](../prepare/windows-autopatch-prerequisites.md).
> [!IMPORTANT]
> Windows Autopatch supports registering [Windows 10 Long-Term Servicing Channel (LTSC)](/windows/whats-new/ltsc/) devices that are being currently serviced by the [Windows LTSC](/windows/release-health/release-information). The service only supports managing the [Windows quality updates](../operate/windows-autopatch-windows-quality-update-overview.md) workload for devices currently serviced by the LTSC. Windows Update for Business service and Windows Autopatch don't offer Windows feature updates for devices that are part of the LTSC. You must either use [LTSC media](https://www.microsoft.com/evalcenter/evaluate-windows-10-enterprise) or the [Configuration Manager Operating System Deployment capabilities to perform an in-place upgrade](/windows/deployment/deploy-windows-cm/upgrade-to-windows-10-with-configuration-manager) for Windows devices that are part of the LTSC.
The Windows Autopatch device registration process is transparent for end-users because it doesn't require devices to be reset.
@ -25,8 +40,8 @@ The overall device registration process is as follows:
:::image type="content" source="../media/windows-autopatch-device-registration-overview.png" alt-text="Overview of the device registration process" lightbox="../media/windows-autopatch-device-registration-overview.png":::
1. IT admin reviews [Windows Autopatch device registration prerequisites](windows-autopatch-register-devices.md#prerequisites-for-device-registration) before registering devices with Windows Autopatch.
2. IT admin identifies devices to be managed by Windows Autopatch through either adding device-based Microsoft Entra groups as part of the [Custom Autopatch group](../deploy/windows-autopatch-groups-overview.md) or the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md).
1. IT admin reviews [Windows Autopatch device registration prerequisites](#prerequisites-for-device-registration) before registering devices with Windows Autopatch.
2. IT admin identifies and adds devices or nests other Microsoft Entra device groups into any Microsoft Entra group used with an Autopatch group, imported (WUfB) policies, or direct membership to the **Modern Workplace Devices-Windows-Autopatch-X-groups**.
3. Windows Autopatch then:
1. Performs device readiness prior registration (prerequisite checks).
2. Calculates the deployment ring distribution.
@ -35,144 +50,69 @@ The overall device registration process is as follows:
5. Marks devices as active for management so it can apply its update deployment policies.
4. IT admin then monitors the device registration trends and the update deployment reports.
For more information about the device registration workflow, see the [Detailed device registration workflow diagram](#detailed-device-registration-workflow-diagram) section for more technical details behind the Windows Autopatch device registration process.
## Detailed device registration workflow diagram
See the following detailed workflow diagram. The diagram covers the Windows Autopatch device registration process:
:::image type="content" source="../media/windows-autopatch-device-registration-workflow-diagram.png" alt-text="Detailed device registration workflow diagram" lightbox="../media/windows-autopatch-device-registration-workflow-diagram.png":::
| Step | Description |
| ----- | ----- |
| **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 Microsoft Entra ID assigned or dynamic groups into the **Windows Autopatch Device Registration** Microsoft Entra ID assigned group when using adding existing device-based Microsoft Entra groups while [creating](../manage/windows-autopatch-manage-autopatch-groups.md#create-a-custom-autopatch-group)/[editing](../manage/windows-autopatch-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) Custom Autopatch groups, or [editing](../manage/windows-autopatch-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) the Default Autopatch group</li></ul> |
| **Step 3: Discover devices** | The Windows Autopatch Discover Devices function discovers devices (hourly) that were previously added by the IT admin into the **Windows Autopatch Device Registration** Microsoft Entra ID assigned group or from Microsoft Entra groups used with Autopatch groups in **step #2**. The Microsoft Entra device ID is used by Windows Autopatch to query device attributes in both Microsoft Intune and Microsoft Entra ID when registering devices into its service.<ol><li>Once devices are discovered from the Microsoft Entra 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 Microsoft Entra ID 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 before 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>**If the device is Intune-managed or not.**</li><ol><li>Windows Autopatch looks to see **if the Microsoft Entra 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 Microsoft Entra device attributes gathered and saved to its memory in **step 3a**.</li><ol><li>Once it has the device attributes gathered from Microsoft Entra ID 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 Microsoft Entra device ID is stale, it doesn't have an Intune device ID associated with it anymore. To remediate, [clean up any stale Microsoft Entra 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 device is a Windows and corporate-owned device.</li><ol><li>**If yes**, it means this device can be registered with the service because it's a Windows corporate-owned device.</li><li>**If not**, it means the device is a non-Windows device, or it's a Windows device but it's a personal device.</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 two deployment ring sets, the first one being the service-based deployment ring set represented by the following Microsoft Entra 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 Microsoft Entra 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>Then the second deployment ring set, the software updates-based deployment ring set represented by the following Microsoft Entra groups:<ul><li>**Windows Autopatch - Ring1**<ul><li>The Windows Autopatch device registration process doesn't automatically assign devices to the Test ring represented by the Microsoft Entra groups (**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></ul><li>**Windows Autopatch - Ring2**</li>**Windows Autopatch - Ring3**</li></li></ol> |
| **Step 7: Assign devices to a Microsoft Entra group** | Windows Autopatch also assigns devices to the following Microsoft Entra 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>**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 **Registered** tab.</li><li>The Microsoft Entra 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 **Registered** and **Not registered** tabs.<ol><li>If the device was **successfully registered**, the device shows up in the **Registered** 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
As described in **step #4** in the previous [Detailed device registration workflow diagram](#detailed-device-registration-workflow-diagram), the following diagram is a visual representation of the prerequisite construct for the Windows Autopatch device registration process. The prerequisite checks are sequentially performed.
:::image type="content" source="../media/windows-autopatch-prerequisite-check-workflow-diagram.png" alt-text="Detailed prerequisite check workflow diagram" lightbox="../media/windows-autopatch-prerequisite-check-workflow-diagram.png":::
For more information about the device registration workflow, see the [Detailed device registration workflow diagram](../deploy/windows-autopatch-register-devices.md#detailed-device-registration-workflow-diagram) section for more technical details behind the Windows Autopatch device registration process.
## Windows Autopatch deployment rings
During the tenant enrollment process, Windows Autopatch creates two different deployment ring sets:
> [!CAUTION]
> **Don't** modify the Microsoft Entra group membership types (Assigned and Dynamic). Otherwise, the Windows Autopatch service won’t be able to read the device group membership from these groups, and causes the Autopatch groups feature and other service-related operations to not work properly.<p>Additionally, it's not supported to have Configuration Manager collections directly synced to any Microsoft Entra group created by Autopatch groups.</p>
- [Service-based deployment ring set](../deploy/windows-autopatch-groups-overview.md#service-based-deployment-rings)
- [Software update-based deployment ring set](../deploy/windows-autopatch-groups-overview.md#software-based-deployment-rings)
When you [start using Autopatch](../prepare/windows-autopatch-feature-activation.md), Windows Autopatch creates the following deployment ring set to organize devices.
The following four Microsoft Entra ID assigned groups are used to organize devices for the service-based deployment ring set:
| Service-based deployment ring | Description |
| ----- | ----- |
| Deployment ring | Description |
| --- | --- |
| Modern Workplace Devices-Windows Autopatch-Test | Deployment ring for testing service-based configuration, app 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 |
The five Microsoft Entra ID assigned groups that are used to organize devices for the software update-based deployment ring set within the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#default-deployment-ring-composition):
| Software updates-based deployment ring | Description |
| ----- | ----- |
| Windows Autopatch - Test | Deployment ring for testing software updates-based deployments prior production rollout. |
| Windows Autopatch - Ring1 | First production deployment ring for early adopters. |
| Windows Autopatch - Ring2 | Fast deployment ring for quick rollout and adoption. |
| Windows Autopatch - Ring3 | Final deployment ring for broad rollout into the organization. |
| Windows Autopatch - Last | Optional deployment ring for specialized devices or VIP/executives that must receive software update deployments after it's well tested with early and general populations in an organization. |
In the software-based deployment ring set, each deployment ring has a different set of update deployment policies to control the updates rollout.
> [!CAUTION]
> Adding or importing devices directly into any of these groups isn't supported. Doing so might affect the Windows Autopatch service. To move devices between these groups, see [Moving devices in between deployment rings](#moving-devices-in-between-deployment-rings).
> Adding or importing devices directly into any of these groups isn't supported. Doing so might affect the Windows Autopatch service. To move devices between these groups, see [Move devices in between deployment rings](../deploy/windows-autopatch-register-devices.md#move-devices-in-between-deployment-rings).
> [!IMPORTANT]
> Windows Autopatch device registration doesn't assign devices to the Test deployment rings of either the service-based (**Modern Workplace Devices-Windows Autopatch-Test**), or software updates-based (**Windows Autopatch - Test and Windows Autopatch - Last**) in the Default Autopatch group. 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.
During the device registration process, Windows Autopatch assigns each device to a [service-based and software-update based deployment ring](../deploy/windows-autopatch-groups-overview.md#service-based-versus-software-update-based-deployment-rings) so that the service has the proper representation of device diversity across your organization.
> Windows Autopatch device registration doesn't assign devices to the Test deployment rings of either the service-based (**Modern Workplace Devices-Windows Autopatch-Test**), or your Autopatch groups. 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.
During the device registration process, Windows Autopatch assigns each device to a deployment ring so that the service has the proper representation of device diversity across your organization.
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]
> You can't create additional deployment rings or use your own rings for devices managed by the Windows Autopatch service.
### Device record and deployment ring assignment
## Default deployment ring calculation logic
Registering your devices with Windows Autopatch does the following:
The Windows Autopatch deployment ring calculation occurs during the device registration process and it applies to both the [service-based and the software update-based deployment ring sets](../deploy/windows-autopatch-groups-overview.md#service-based-versus-software-update-based-deployment-rings):
1. Makes a record of devices in the service.
2. Assign devices to the [deployment ring set](#default-deployment-ring-calculation-logic) and other groups required for software update management.
### Default deployment ring calculation logic
The Windows Autopatch deployment ring calculation occurs during the device registration process:
- 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%)**.
- 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%)**.
- If the Windows Autopatch tenant's existing managed device size is **>200**, the deployment ring assignment is First **(1%)**, Fast **(9%)**, remaining devices go to the Broad ring **(90%)**.
> [!NOTE]
> You can customize the deployment ring calculation logic by editing the Default Autopatch group.
> You can customize the deployment ring calculation logic by [editing an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group).
| Service-based deployment ring | Default Autopatch group deployment ring | Default device balancing percentage | Description |
| ----- | ----- | ----- | ----- |
| Test | 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 | Ring 1 | **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 | Ring 2 | **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 | Ring 3 | 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 a software update deployment.|
| N/A | Last | **zero** | The Last ring is intended to be used for either specialized devices or devices that belong to VIP/executives in an organization. Windows Autopatch doesn't automatically add devices to this deployment ring. |
## Software update-based to service-based deployment ring mapping
There's a one-to-one mapping in between the service-based and software updates-based deployment rings introduced with Autopatch groups. This mapping is intended to help move devices in between deployment rings for other software update workloads that don't yet support Autopatch groups such as Microsoft 365 Apps and Microsoft Edge.
| If moving a device to | The device also moves to |
| ----- | ----- |
| Windows Autopatch - Test | Modern Workplace Devices-Windows Autopatch-Test |
| Windows Autopatch - Ring1 | Modern Workplace Devices-Windows Autopatch-First |
| Windows Autopatch - Ring2 | Modern Workplace Devices-Windows Autopatch-Fast |
| Windows Autopatch - Ring3 | Modern Workplace Devices-Windows Autopatch-Broad |
| Windows Autopatch - Last | Modern Workplace Devices-Windows Autopatch-Broad |
If your Autopatch groups have more than five deployment rings, and you must move devices to deployment rings after Ring3. For example, `<Autopatch group name - Ring4, Ring5, Ring6, etc.>`. The devices will be moved to **Modern Workplace Devices-Windows Autopatch-Broad**.
## Moving devices in between deployment rings
If you want to move devices to different deployment rings (either service or software update-based), after Windows Autopatch's deployment ring assignment, you can repeat the following steps for one or more devices from the **Registered** tab.
> [!IMPORTANT]
> You can only move devices in between deployment rings within the **same** Autopatch group. You can't move devices in between deployment rings across different Autopatch groups. If you try to select a device that belongs to one Autopatch group, and another device that belongs to a different Autopatch group, you'll receive the following error message on the top right corner of the Microsoft Intune portal: "**An error occurred. Please select devices within the same Autopatch group**.
**To move devices in between deployment rings:**
> [!NOTE]
> You can only move devices to other deployment rings when they're in an active state in the **Registered** tab.
1. In the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), select **Devices** in the left pane.
1. In the **Windows Autopatch** section, select **Devices**.
1. In the **Registered** tab, select one or more devices you want to assign. All selected devices will be assigned to the deployment ring you specify.
1. Select **Device actions** from the menu.
1. Select **Assign ring**. A fly-in opens.
1. Use the dropdown menu to select the deployment ring to move devices to, and then select Save. The Ring assigned by column will change to Pending.
1. When the assignment is complete, the **Ring assigned by** column changes to Admin (which indicates that you made the change) and the **Ring** column shows the new deployment ring assignment.
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 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 Microsoft Entra 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.
| 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 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 before 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 a software update deployment.|
| N/A | **zero** | The Last ring is intended to be used for either specialized devices or devices that belong to VIP/executives in an organization. Windows Autopatch doesn't automatically add devices to this deployment ring. |
## Automated deployment ring remediation functions
Windows Autopatch monitors device membership in its deployment rings, except for the **Modern Workplace Devices-Windows Autopatch-Test**, **Windows Autopatch - Test** and **Windows Autopatch - Last** rings, 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:
Windows Autopatch monitors device membership in its deployment rings, except for the **Modern Workplace Devices-Windows Autopatch-Test**, **Windows Autopatch - Test** and **Windows Autopatch - Last** rings, 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:
- Changes performed by the IT admin on objects created by the Windows Autopatch tenant enrollment process, or
- An issue occurred which prevented devices from getting a deployment ring assigned during the device registration process.
- An issue occurred which prevented devices from getting a deployment ring assigned during the device registration process.
There are two automated deployment ring remediation functions:
| Function | Description |
| ----- | ----- |
| Check device deployment ring membership | Every hour, Windows Autopatch checks to see if any of its managed devices aren't part of one of the deployment rings. If a device isn't part of a deployment ring, Windows Autopatch randomly assigns the device to one of its deployment rings (except for the **Modern Workplace Devices-Windows Autopatch-Test**, **Windows Autopatch - Test and Windows Autopatch - Last** rings). |
| Multi-deployment ring device remediator | Every hour, Windows Autopatch checks to see if any of its managed devices are part of multiple deployment rings (except for the **Modern Workplace Devices-Windows Autopatch-Test**, **Windows Autopatch - Test** and **Windows Autopatch - Last** rings). If a device is part of multiple deployment rings, Windows Autopatch randomly removes the device until the device is only part of one deployment ring. |
| Check device deployment ring membership | Every hour, Windows Autopatch checks to see if any of its managed devices aren't part of one of the deployment rings. If a device isn't part of a deployment ring, Windows Autopatch randomly assigns the device to one of its deployment rings (except for the **Modern Workplace Devices-Windows Autopatch-Test**, **Windows Autopatch - Test and Windows Autopatch - Last** rings). |
| Multi-deployment ring device remediator | Every hour, Windows Autopatch checks to see if any of its managed devices are part of multiple deployment rings (except for the **Modern Workplace Devices-Windows Autopatch-Test**, **Windows Autopatch - Test** and **Windows Autopatch - Last** rings). If a device is part of multiple deployment rings, Windows Autopatch randomly removes the device until the device is only part of one deployment ring. |
> [!IMPORTANT]
> Windows Autopatch automated deployment ring functions don't assign or remove devices to or from the following deployment rings:<li>**Modern Workplace Devices-Windows Autopatch-Test**</li><li>**Windows Autopatch - Test**</li><li>**Windows Autopatch - Last**</li></ul>

205
windows/deployment/windows-autopatch/deploy/windows-autopatch-groups-overview.md
View File

@ -1,7 +1,7 @@
---
title: Windows Autopatch groups overview
description: This article explains what Autopatch groups are
ms.date: 07/08/2024
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: concept-article
@ -15,13 +15,19 @@ ms.collection:
- tier1
---
# Windows Autopatch groups overview
# Windows Autopatch groups
As organizations move to a managed-service model where Microsoft manages update processes on their behalf, they're challenged with having the right representation of their organizational structures followed by their own deployment cadence. Windows Autopatch groups help organizations manage updates in a way that makes sense for their businesses with no extra cost or unplanned disruptions.
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
As organizations move to a managed-service model where Microsoft manages update processes on their behalf, they’re challenged with having the right representation of their organizational structures followed by their own deployment cadence. Windows Autopatch groups help organizations manage updates in a way that makes sense for their businesses with no extra cost or unplanned disruptions.
## What are Windows Autopatch groups?
Autopatch groups is a logical container or unit that groups several [Microsoft Entra groups](/azure/active-directory/fundamentals/active-directory-groups-view-azure-portal), and software update policies, such as [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) and [feature updates for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates).
An Autopatch group is a logical container or unit that groups several [Microsoft Entra groups](/entra/fundamentals/groups-view-azure-portal), and software update policies, such as [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) and [feature updates for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates).
Autopatch groups are intended to help organizations that require a more precise representation of their organization's structures along with their own update deployment cadence in the service.
By default, an Autopatch group has the Test and Last deployment rings automatically present. For more information, see [Test and Last deployment rings](#test-and-last-deployment-rings).
## Key benefits
@ -31,101 +37,41 @@ Autopatch groups help Microsoft Cloud-Managed services meet organizations where
| ----- | ----- |
| Replicating your organizational structure | You can set up Autopatch groups to replicate your organizational structures represented by your existing device-based Microsoft Entra group targeting logic. |
| Having a flexible number of deployments | Autopatch groups give you the flexibility of having the right number of deployment rings that work within your organization. You can set up to 15 deployment rings per Autopatch group. |
| Deciding which device(s) belong to deployment rings | Along with using your existing device-based Microsoft Entra groups and choosing the number of deployment rings, you can also decide which devices belong to deployment rings during the device registration process when setting up Autopatch groups. |
| Deciding which devices belong to deployment rings | Along with using your existing device-based Microsoft Entra groups and choosing the number of deployment rings, you can also decide which devices belong to deployment rings during the device distribution process when setting up Autopatch groups. |
| Choosing the deployment cadence | You choose the right software update deployment cadence for your business. |
## Prerequisites
Before you start managing Autopatch groups, ensure you meet the following prerequisites:
| Prerequisite | Details |
| --- | --- |
| Review [Windows Autopatch groups overview documentation](../deploy/windows-autopatch-groups-overview.md) | Understand [key benefits](../deploy/windows-autopatch-groups-overview.md#key-benefits) and [common ways to use Autopatch groups](../deploy/windows-autopatch-groups-overview.md#common-ways-to-use-autopatch-groups) within your organization. |
| Make sure you have [app-only auth turned on in your Windows Autopatch tenant](../monitor/windows-autopatch-maintain-environment.md#windows-autopatch-tenant-actions). Otherwise, the Autopatch groups functionality doesn't work properly. Autopatch uses app-only auth to: |<ul><li>Read device attributes to successfully register devices.</li><li>Manage all configurations related to the operation of the service.</li></ul> |
| Make sure that all device-based Microsoft Entra groups you intend to use with Autopatch groups are created before using the feature. | Review your existing Microsoft Entra group dynamic queries and direct device memberships to:<ul><li>Avoid having device membership overlaps in between device-based Microsoft Entra groups that are going to be used with Autopatch groups.</li><li>Prevent device conflicts within an Autopatch group or across several Autopatch groups. **Autopatch groups doesn't support user-based Microsoft Entra groups**.</li></ul> |
| Ensure devices used with your existing Microsoft Entra groups meet [device registration prerequisite checks](../deploy/windows-autopatch-device-registration-overview.md#prerequisites-for-device-registration) when being registered with the service | Autopatch groups register devices on your behalf, and device readiness states are determined based on the registration state and if any applicable alerts are targeting the device. For more information, see the [Devices report](../deploy/windows-autopatch-register-devices.md#devices-report). |
> [!TIP]
> [Update rings](/mem/intune/protect/windows-10-update-rings) and [feature updates](/mem/intune/protect/windows-10-feature-updates) for Windows 10 and later policies that are created and managed by Windows Autopatch can be restored using the [Policy health](../monitor/windows-autopatch-policy-health-and-remediation.md) feature. For more information on remediation actions, see [restore Windows update policies](../monitor/windows-autopatch-policy-health-and-remediation.md#restore-missing-windows-update-policies).
## Register devices into Autopatch groups
Autopatch groups register devices with the Windows Autopatch service when you either [create](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) or [edit an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group). For more information, see [Register devices into Autopatch groups](../deploy/windows-autopatch-register-devices.md#register-devices-into-autopatch-groups).
## High-level architecture diagram overview
:::image type="content" source="../media/windows-autopatch-groups-high-level-architecture-diagram.png" alt-text="Overview of the device registration process" lightbox="../media/windows-autopatch-groups-high-level-architecture-diagram.png":::
Autopatch groups is a function app that is part of the device registration micro service within the Windows Autopatch service. The following table explains the high-level workflow:
An Autopatch group is a function app that is part of the device registration micro service within the Windows Autopatch service. The following table explains the high-level workflow:
| Step | Description |
| ----- | ----- |
| Step 1: Create an Autopatch group | Create an Autopatch group. |
| Step 2: Windows Autopatch uses Microsoft Graph to create Microsoft Entra ID and policy assignments | Windows Autopatch service uses Microsoft Graph to coordinate the creation of:<ul><li>Microsoft Entra groups</li><li>Software update policy assignments with other Microsoft services, such as Microsoft Entra ID, Intune, and Windows Update for Business (WUfB) based on IT admin choices when you create or edit an Autopatch group.</li></ul> |
| Step 1: Create an Autopatch group | Create an Autopatch group. Autopatch groups register devices with the Windows Autopatch service when you either [create](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) or [edit an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group). |
| Step 2: Windows Autopatch uses Microsoft Graph to create Microsoft Entra ID and policy assignments | Windows Autopatch service uses Microsoft Graph to coordinate the creation of:<ul><li>Microsoft Entra groups</li><li>Software update policy assignments with other Microsoft services, such as Microsoft Entra ID, Intune, and Windows Update for Business (WUfB) based on IT admin choices when you [create](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) or [edit an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group).</li></ul> |
| Step 3: Intune assigns software update policies | Once Microsoft Entra groups are created in the Microsoft Entra service, Intune is used to assign the software update policies to these groups and provide the number of devices that need the software update policies to the Windows Update for Business (WUfB) service. |
| Step 4: Windows Update for Business responsibilities | Windows Update for Business (WUfB) is the service responsible for:<ul><li>Delivering those update policies</li><li>Retrieving update deployment statuses back from devices</li><li>Sending back the status information to Microsoft Intune, and then to the Windows Autopatch service</li></ul> |
## Key concepts
There are a few key concepts to be familiar with before using Autopatch groups.
### About the Default Autopatch group
> [!NOTE]
> The Default Autopatch group is recommended for organizations that can meet their business needs using the pre-configured five deployment ring composition.
The Default Autopatch group uses Windows Autopatch's default update management process recommendation. The Default Autopatch group contains:
- A set of **[five deployment rings](#default-deployment-ring-composition)**
- A default update deployment cadence for both [Windows quality](../operate/windows-autopatch-groups-windows-quality-update-overview.md) and [feature updates](../operate/windows-autopatch-groups-windows-feature-update-overview.md).
The Default Autopatch group is intended to serve organizations that are looking to:
- Enroll into the service
- Align to Windows Autopatch's default update management process without requiring more customizations.
The Default Autopatch group **can't** be deleted or renamed. However, you can customize its deployment ring composition to add and/or remove deployment rings, and you can also customize the update deployment cadences for each deployment ring within it.
#### Default deployment ring composition
By default, the following [software update-based deployment rings](#software-based-deployment-rings), represented by Microsoft Entra ID assigned groups, are used:
- Windows Autopatch - Test
- Windows Autopatch - Ring1
- Windows Autopatch - Ring2
- Windows Autopatch - Ring3
- Windows Autopatch - Last
**Windows Autopatch - Test** and **Last** can be only used as **Assigned** device distributions. **Windows Autopatch - Ring1**, **Ring2** and **Ring3** can be used with either **Assigned** or **Dynamic** device distributions, or have a combination of both device distribution types.
> [!TIP]
> For more information about the differences between **Assigned** and **Dynamic** deployment ring distribution types, see [about deployment rings](#about-deployment-rings). Only deployment rings that are placed in between the **Test** and the **Last** deployment rings can be used with the **Dynamic** deployment ring distributions.
> [!CAUTION]
> These and other Microsoft Entra ID assigned groups created by Autopatch groups **can't** be missing in your tenant, otherwise, Autopatch groups might not function properly.
The **Last** deployment ring, the fifth deployment ring in the Default Autopatch group, is intended to provide coverage for scenarios where a group of specialized devices and/or VIP/Executive users. They must receive software update deployments after the organization's general population to mitigate disruptions to your organization's critical businesses.
#### Default update deployment cadences
The Default Autopatch group provides a default update deployment cadence for its deployment rings except for the **Last** (fifth) deployment ring.
##### Update rings policy for Windows 10 and later
Autopatch groups set up the [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) for each of its deployment rings in the Default Autopatch group. See the following default policy values:
| Policy name | Microsoft Entra group assignment | Quality updates deferral in days | Feature updates deferral in days | Feature updates uninstall window in days | Deadline for quality updates in days | Deadline for feature updates in days | Grace period | Auto restart before deadline |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Windows Autopatch Update Policy - default - Test | Windows Autopatch - Test | 0 | 0 | 30 | 0 | 5 | 0 | Yes |
| Windows Autopatch Update Policy - default - Ring1 | Windows Autopatch - Ring1 | 1 | 0 | 30 | 2 | 5 |2 | Yes |
| Windows Autopatch Update Policy - default - Ring2 | Windows Autopatch - Ring2 | 6 | 0 | 30 | 2 | 5 | 2 | Yes |
| Windows Autopatch Update Policy - default - Ring3 | Windows Autopatch - Ring3 | 9 | 0 | 30 | 5 | 5 | 2 | Yes |
| Windows Autopatch Update Policy - default - Last | Windows Autopatch - Last | 11 | 0 | 30 | 3 | 5 | 2 | Yes |
##### Feature update policy for Windows 10 and later
Autopatch groups set up the [feature updates for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates) for each of its deployment rings in the Default Autopatch group, see the following default policy values:
| Policy name | Microsoft Entra group assignment |Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Windows Autopatch - DSS Policy [Test] | Windows Autopatch - Test | Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024; 1:00AM |
| Windows Autopatch - DSS Policy [Ring1] | Windows Autopatch - Ring1 | Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024; 1:00AM |
| Windows Autopatch - DSS Policy [Ring2] | Windows Autopatch - Ring2 | Windows 10 21H2 | Make update available as soon as possible | December 14, 2022 | December 21, 2022 | 1 | June 11, 2024; 1:00AM |
| Windows Autopatch - DSS Policy [Ring3] | Windows Autopatch - Ring3 | Windows 10 21H2 | Make update available as soon as possible | December 15, 2022 | December 29, 2022 | 1 | June 11, 2024; 1:00AM |
| Windows Autopatch - DSS Policy [Last] | Windows Autopatch - Last | Windows 10 21H2 | Make update available as soon as possible | December 15, 2022 | December 29, 2022 | 1 | June 11, 2024; 1:00AM |
### About Custom Autopatch groups
> [!NOTE]
> The [Default Autopatch group](#about-the-default-autopatch-group) is recommended for organizations that can meet their business needs using the pre-configured five deployment ring composition.
Custom Autopatch groups are intended to help organizations that require a more precise representation of their organization's structures along with their own update deployment cadence in the service.
By default, a Custom Autopatch group has the Test and Last deployment rings automatically present. For more information, see [Test and Last deployment rings](#about-the-test-and-last-deployment-rings).
### About deployment rings
## Autopatch group deployment rings
Deployment rings make it possible for an Autopatch group to have software update deployments sequentially delivered in a gradual rollout within the Autopatch group.
@ -137,92 +83,38 @@ Windows Autopatch aligns with Microsoft Entra ID and Intune terminology for devi
| Assigned | You can use one single device-based Microsoft Entra group, either dynamic query-based, or assigned to use in your deployment ring composition. |
| Combination of Dynamic and Assigned | To provide a greater level of flexibility when working on deployment ring compositions, you can combine both device distribution types in Autopatch groups.<p>The combination of Dynamic and Assigned device distribution is **not** supported for the Test and Last deployment ring in Autopatch groups.</p> |
#### About the Test and Last deployment rings
### Test and Last deployment rings
Both the **Test** and **Last** deployment rings are default deployment rings that are automatically present in the Default Autopatch group and Custom Autopatch groups. These default deployment rings provide the recommended minimum number of deployment rings that an Autopatch group should have.
Both the **Test** and **Last** deployment rings are default deployment rings that are automatically present in an Autopatch group. These default deployment rings provide the recommended minimum number of deployment rings that an Autopatch group should have.
If you only keep Test and Last deployment rings in your Default Autopatch group, or you don't add more deployment rings when creating a Custom Autopatch group, the Test deployment ring can be used as the pilot deployment ring and Last can be used as the production deployment ring.
If you don't add more deployment rings when creating an Autopatch group, the Test deployment ring can be used as the pilot deployment ring and Last can be used as the production deployment ring.
> [!IMPORTANT]
> Both the **Test** and **Last** deployment rings **can't** be removed or renamed from the Default or Custom Autopatch groups. Autopatch groups don't support the use of one single deployment ring as part of its deployment ring composition because you need at least two deployment rings for their gradual rollout. If you must implement a specific scenario with a single deployment ring, and gradual rollout isn't required, consider managing these devices outside Windows Autopatch.
> Both the **Test** and **Last** deployment rings **can't** be removed or renamed from Autopatch groups. Autopatch groups don't support the use of one single deployment ring as part of its deployment ring composition because you need **at least two deployment rings** for their gradual rollout. If you must implement a specific scenario with a single deployment ring, and gradual rollout isn't required, consider managing these devices outside Autopatch groups.
> [!TIP]
> Both the **Test** and **Last** deployment rings only support one single Microsoft Entra group assignment at a time. If you need to assign more than one Microsoft Entra group, you can nest the other Microsoft Entra groups under the ones you plan to use with the **Test** and **Last** deployment rings. Only one level of Microsoft Entra group nesting is supported.
#### Service-based versus software update-based deployment rings
Autopatch groups creates two different layers. Each layer contains its own deployment ring set.
> [!IMPORTANT]
> Both service-based and software update-based deployment ring sets are, by default, assigned to devices that successfully register with Windows Autopatch.
##### Service-based deployment rings
The service-based deployment ring set is exclusively used to keep Windows Autopatch updated with both service and device-level configuration policies, apps and APIs needed for core functions of the service.
The following are the Microsoft Entra ID assigned groups that represent the service-based deployment rings. These groups can't be deleted or renamed:
- Modern Workplace Devices-Windows Autopatch-Test
- Modern Workplace Devices-Windows Autopatch-First
- Modern Workplace Devices-Windows Autopatch-Fast
- Modern Workplace Devices-Windows Autopatch-Broad
> [!CAUTION]
> **Don't** modify the Microsoft Entra group membership types (Assigned and Dynamic). Otherwise, the Windows Autopatch service won't be able to read the device group membership from these groups, and causes the Autopatch groups feature and other service-related operations to not work properly. <p>Additionally, it's **not** supported to have Configuration Manager collections directly synced to any Microsoft Entra group created by Autopatch groups.</p>
##### Software-based deployment rings
The software-based deployment ring set is exclusively used with software update management policies, such as the Windows update ring and feature update policies, in the Default Windows Autopatch group.
The following are the Microsoft Entra ID assigned groups that represent the software updates-based deployment rings. These groups can't be deleted or renamed:
- Windows Autopatch - Test
- Windows Autopatch - Ring1
- Windows Autopatch - Ring2
- Windows Autopatch - Ring3
- Windows Autopatch - Last
> [!IMPORTANT]
> Additional Microsoft Entra ID assigned groups are created and added to list when you add more deployment rings to the Default Autopatch group.
> [!CAUTION]
> **Don't** modify the Microsoft Entra group membership types (Assigned and Dynamic). Otherwise, the Windows Autopatch service won't be able to read the device group membership from these groups, and causes the Autopatch groups feature and other service-related operations to not work properly. <p>Additionally, it's **not** supported to have Configuration Manager collections directly synced to any Microsoft Entra group created by Autopatch groups.</p>
### About device registration
Autopatch groups register devices with the Windows Autopatch service when you either [create](../manage/windows-autopatch-manage-autopatch-groups.md#create-a-custom-autopatch-group) or [edit a Custom Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group), and/or when you [edit the Default Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) to use your existing Microsoft Entra groups instead of the Windows Autopatch Device Registration group provided by the service.
## Common ways to use Autopatch groups
The following are three common uses for using Autopatch groups.
### Use case #1
> [!NOTE]
> The [Default Autopatch group](#about-the-default-autopatch-group) is recommended for organizations that can meet their business needs using the pre-configured five deployment ring composition.
| Scenario | Solution |
| ----- | ----- |
| You're working as the IT admin at Contoso Ltd. And manage several Microsoft and non-Microsoft cloud services. You don't have extra time to spend setting up and managing several Autopatch groups.<p>Your organization currently operates its update management by using five deployment rings, but there's an opportunity to have flexible deployment cadences if it's precommunicated to your end-users.</p> | If you don't have thousands of devices to manage, use the Default Autopatch group for your organization. You can edit the Default Autopatch group to include additional deployment rings and/or slightly modify some of its default deployment cadences.<p>The Default Autopatch group is preconfigured and doesn't require extra configurations when registering devices with the Windows Autopatch service.</p><p>The following is a visual representation of a gradual rollout for the Default Autopatch group preconfigured and fully managed by the Windows Autopatch service.</p> |
:::image type="content" source="../media/autopatch-groups-default-autopatch-group.png" alt-text="Default Autopatch group" lightbox="../media/autopatch-groups-default-autopatch-group.png":::
### Use case #2
| Scenario | Solution |
| ----- | ----- |
| You're working as the IT admin at Contoso Ltd. Your organization needs to plan a gradual rollout of software updates within specific critical business units or departments to help mitigate the risk of end-user disruption. | You can create a Custom Autopatch group for each of your business units. For example, you can create a Custom Autopatch group for the finance department and breakdown the deployment ring composition per the different user personas or based on how critical certain user groups can be for the department and then for the business.<p>The following is a visual representation of a gradual rollout for Contoso's Finance department.</p> |
| You're working as the IT admin at Contoso Ltd. Your organization needs to plan a gradual rollout of software updates within specific critical business units or departments to help mitigate the risk of end-user disruption. | You can create an Autopatch group for each of your business units. For example, you can create an Autopatch group for the finance department and breakdown the deployment ring composition per the different user personas or based on how critical certain user groups can be for the department and then for the business.<p>The following is a visual representation of a gradual rollout for Contoso’s Finance department.</p> |
:::image type="content" source="../media/autopatch-groups-finance-department-example.png" alt-text="Finance department example" lightbox="../media/autopatch-groups-finance-department-example.png":::
> [!IMPORTANT]
> Once Autopatch groups are setup, the release of either Windows quality or feature updates will be deployed sequentially through its deployment rings.
### Use case #3
### Use case #2
| Scenario | Solution |
| ----- | ----- |
| You're working as the IT admin at Contoso Ltd. Your branch location in Chicago needs to plan a gradual rollout of software updates within specific departments to make sure the Chicago office doesn't experience disruptions in its operations. | You can create a Custom Autopatch group for the branch location in Chicago and breakdown the deployment ring composition per the departments within the branch location.<p>The following is a visual representation of a gradual rollout for the Contoso Chicago branch location.</p> |
| You're working as the IT admin at Contoso Ltd. Your branch location in Chicago needs to plan a gradual rollout of software updates within specific departments to make sure the Chicago office doesn’t experience disruptions in its operations. | You can create an Autopatch group for the branch location in Chicago and breakdown the deployment ring composition per the departments within the branch location.<p>The following is a visual representation of a gradual rollout for the Contoso Chicago branch location.</p> |
:::image type="content" source="../media/autopatch-groups-contoso-chicago-example.png" alt-text="Contoso Chicago example" lightbox="../media/autopatch-groups-contoso-chicago-example.png":::
@ -235,16 +127,19 @@ The following configurations are supported when using Autopatch groups.
### Software update workloads
Autopatch groups works with the following software update workloads:
Autopatch groups work with the following software update workloads:
- [Windows quality updates](../operate/windows-autopatch-groups-windows-quality-update-overview.md)
- [Windows feature updates](../operate/windows-autopatch-groups-windows-feature-update-overview.md)
- [Windows feature updates](../manage/windows-autopatch-windows-feature-update-overview.md)
- [Windows quality updates](../manage/windows-autopatch-windows-quality-update-overview.md)
- [Driver and firmware updates](../manage/windows-autopatch-manage-driver-and-firmware-updates.md)
- [Microsoft 365 Apps for enterprise](../manage/windows-autopatch-microsoft-365-apps-enterprise.md)
- [Microsoft Edge](../manage/windows-autopatch-edge.md)
### Maximum number of Autopatch groups
Windows Autopatch supports up to 50 Autopatch groups in your tenant. You can create up to 49 [Custom Autopatch groups](#about-custom-autopatch-groups) in addition to the [Default Autopatch group](#about-the-default-autopatch-group). Each Autopatch group supports up to 15 deployment rings.
Windows Autopatch supports up to 50 Autopatch groups in your tenant. Each Autopatch group supports up to 15 deployment rings.
> [!TIP]
> If you reach the maximum number of Autopatch groups supported (50), and try to create more Custom Autopatch groups, the "**Create**" option in the Autopatch groups blade will be greyed out.
> [!NOTE]
> If you reach the maximum number of Autopatch groups supported (50), and try to create more Autopatch groups, the "Create" option in the Autopatch groups blade will be greyed out.
To manage your Autopatch groups, see [Manage Windows Autopatch groups](../deploy/windows-autopatch-groups-manage-autopatch-groups.md).
To manage your Autopatch groups, see [Manage Windows Autopatch groups](../manage/windows-autopatch-manage-autopatch-groups.md).

34
windows/deployment/windows-autopatch/deploy/windows-autopatch-post-reg-readiness-checks.md
View File

@ -1,7 +1,7 @@
---
title: Post-device registration readiness checks
description: This article details how post-device registration readiness checks are performed in Windows Autopatch
ms.date: 07/08/2024
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: concept-article
@ -15,14 +15,13 @@ ms.collection:
- tier1
---
# Post-device registration readiness checks (public preview)
# Post-device registration readiness checks
> [!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.
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
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.
Having a way of measuring, quickly detecting and remediating when something goes wrong with ongoing 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.
@ -37,13 +36,13 @@ Device readiness in Windows Autopatch is divided into two different scenarios:
### 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) |
| Required device readiness (prerequisite checks) before 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> |
| <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.
The status of each post-device registration readiness check is shown in the Windows Autopatch's Devices blade under the **Not registered** tab. You can take appropriate actions on devices that aren't ready to be fully managed by the Windows Autopatch service.
## About the three tabs in the Devices blade
## Devices blade: Registered and Not registered tabs
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.
@ -52,13 +51,12 @@ Figuring out device health can be challenging and disruptive to the end user whe
- Obtain proactive data sent by the device to the service, or
- Proactively detect and remediate 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 remediate potential device health issues:
Windows Autopatch has devices readiness states within its [**Devices report**](../deploy/windows-autopatch-register-devices.md#devices-report). Each state provides IT admins monitoring information on which devices might have 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 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. |
| Registered |<ul><li>**Ready**</li><ul><li>Passed the prerequisite checks</li><li>Registered with Windows Autopatch</li><li>No active alerts targeted to the device</li></ul><li>**Not Ready**</li><ul><li>Devices that didn’t pass one or more post-device registration readiness checks</li><li>Devices that didn't communicate with the Microsoft Intune service in the last 28 days</li></ul></ul> |
| Not registered |<ul><li>**Prerequisite failed**<ul><li>Devices with the **Prerequisite failed** status didn't pass one or more prerequisite checks during the device registration process.</li></ul><li>**Excluded**</li><ul><li>Devices with the Excluded status are removed from the Windows Autopatch service</li></ul></ul>|
## Details about the post-device registration readiness checks
@ -68,7 +66,7 @@ A healthy or active device in Windows Autopatch is:
- 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 sub-component of the overall Windows Autopatch service.
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:
@ -95,16 +93,16 @@ See the following diagram for the post-device registration readiness checks work
| **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. |
| **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 in 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>|
| **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 provides information about the failure and how to potentially remediate devices.<p>Once devices are remediated, it can take up to **24 hours** to appear in the **Ready** tab.</p>|
## Additional resources
- [Device registration overview](windows-autopatch-device-registration-overview.md)
- [Register your devices](windows-autopatch-register-devices.md)
- [Device registration overview](../deploy/windows-autopatch-device-registration-overview.md)
- [Register your devices](../deploy/windows-autopatch-register-devices.md)

240
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: 07/10/2024
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
@ -17,29 +17,106 @@ ms.collection:
# Register your devices
Before Microsoft can manage your devices in Windows Autopatch, you must have devices registered with the service.
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
## Before you begin
Before Microsoft can manage your devices in Windows Autopatch, you must register devices with the service. Make sure your devices meet the [device registration prerequisites](../deploy/windows-autopatch-device-registration-overview.md#prerequisites-for-device-registration).
Windows Autopatch can take over software update management control of devices that meet software-based prerequisites as soon as an IT admin decides to have their tenant managed by the service. The Windows Autopatch software update management scope includes the following software update workloads:
## Detailed device registration workflow diagram
- [Windows quality updates](../operate/windows-autopatch-groups-windows-quality-update-overview.md)
- [Windows feature updates](../operate/windows-autopatch-groups-windows-feature-update-overview.md)
- [Microsoft 365 Apps for enterprise updates](../operate/windows-autopatch-microsoft-365-apps-enterprise.md)
- [Microsoft Edge updates](../operate/windows-autopatch-edge.md)
- [Microsoft Teams updates](../operate/windows-autopatch-teams.md)
See the following detailed workflow diagram. The diagram covers the Windows Autopatch device registration process:
### Windows Autopatch groups device registration
:::image type="content" source="../media/windows-autopatch-device-registration-workflow-diagram.png" alt-text="Diagram of the device registration workflow." lightbox="../media/windows-autopatch-device-registration-workflow-diagram.png":::
When you either create/edit a [Custom Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-custom-autopatch-groups) or edit the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group) to add or remove deployment rings, the device-based Microsoft Entra groups you use when setting up your deployment rings are scanned to see if devices need to be registered with the Windows Autopatch service.
| Step | Description |
| ----- | ----- |
| **Step 1: Identify devices** | IT admin identifies devices to be managed by the Windows Autopatch service. |
| **Step 2: Add devices** | IT admin identifies and adds devices, or nests other Microsoft Entra device groups into any Microsoft Entra group when you [create an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) or [edit an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group) or imported (WUfB) policies. |
| **Step 3: Discover devices** | The Windows Autopatch Discover Devices function discovers devices (hourly) that were previously added by the IT admin from Microsoft Entra groups used with Autopatch groups in **step #2**. The Microsoft Entra device ID is used by Windows Autopatch to query device attributes in both Microsoft Intune and Microsoft Entra ID when registering devices into its service.<ol><li>Once devices are discovered from the Microsoft Entra 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 Microsoft Entra ID 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 before 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>**If the device is Intune-managed or not.**</li><ol><li>Windows Autopatch looks to see **if the Microsoft Entra 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 Microsoft Entra device attributes gathered and saved to its memory in **step 3a**.</li><ol><li>Once it has the device attributes gathered from Microsoft Entra ID in **step 3a**, the device is flagged with the **Prerequisite failed** status, and the device's Autopatch readiness status appears as **Not registered** in the [**Devices report**](#devices-report). The IT admin can review the reasons the device wasn't registered into Windows Autopatch. The IT admin remediates 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 Microsoft Entra device ID is stale, it doesn't have an Intune device ID associated with it anymore. To remediate, [clean up any stale Microsoft Entra 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 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 device is a Windows and corporate-owned device.</li><ol><li>**If yes**, it means this device can be registered with the service because it's a Windows corporate-owned device.</li><li>**If not**, it means the device is a non-Windows device, or it's a Windows device but it's a personal device.</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 the device's Autopatch readiness status appears as **Not registered** in the **Devices report**.</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 is **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 two deployment ring sets, the first one being the service-based deployment ring set represented by the following Microsoft Entra 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 Microsoft Entra 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> |
| **Step 7: Assign devices to a Microsoft Entra group** | Windows Autopatch also assigns devices to the following Microsoft Entra 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>**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 **Ready**. The device's Autopatch readiness status appears as **Registered** in the **Devices report**.</li><li>The Microsoft Entra 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's Autopatch readiness status. Devices are either **Registered** or **Not registered** in the **Devices report**.<ol><li>If the device was **successfully registered**, the device's Autopatch readiness status appears as **Registered** in the **Devices report**.</li><li>If **not**, the device's Autopatch readiness status appears as **Not registered** in the **Devices report**.</li></ol> |
| **Step 10: End of registration workflow** | This is the end of the Windows Autopatch device registration workflow. |
If devices aren't registered, Autopatch groups starts the device registration process by using your existing device-based Microsoft Entra groups instead of the Windows Autopatch Device Registration group.
## Detailed prerequisite check workflow diagram
For more information, see [create Custom Autopatch groups](../manage/windows-autopatch-manage-autopatch-groups.md#create-a-custom-autopatch-group) and [edit Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) to register devices using the Autopatch groups device registration method.
As described in **step #4** in the previous [Detailed device registration workflow diagram](#detailed-device-registration-workflow-diagram), the following diagram is a visual representation of the prerequisite construct for the Windows Autopatch device registration process. The prerequisite checks are sequentially performed.
<a name='supported-scenarios-when-nesting-other-azure-ad-groups'></a>
:::image type="content" source="../media/windows-autopatch-prerequisite-check-workflow-diagram.png" alt-text="Diagram of the prerequisite check workflow." lightbox="../media/windows-autopatch-prerequisite-check-workflow-diagram.png":::
#### Supported scenarios when nesting other Microsoft Entra groups
## Devices report
Windows Autopatch has a device report that allows you to see:
- Each registered devices readiness for the service
- Update status
- Policies that target each device
### View the device report
**To view the device report:**
1. In the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), select **Devices** in the left pane.
1. Under Manage updates, select **Windows updates**.
1. Select the **Monitor** tab, and then select **Autopatch devices**.
Once a device is registered to the service, a readiness status is displayed. Each readiness status helps you to determine if there are any actions to take or if the device is ready for the service.
#### Readiness statuses
| Autopatch readiness status in the Devices report | Sub-status description |
| --- | --- |
| Registered |<ul><li>**Ready**: Devices successfully passed all prerequisite checks and successfully registered with Windows Autopatch. Additionally, Ready devices successfully passed all [post-device registration readiness checks](../deploy/windows-autopatch-post-reg-readiness-checks.md) and don't have any active alerts targeting them.</li><li>**Not ready**: These devices were successfully registered with Windows Autopatch. However, these devices:</li><ul><li>Failed to pass one or more [post-device registration readiness checks](../deploy/windows-autopatch-post-reg-readiness-checks.md).</li><li>Aren't ready to have one or more software update workloads managed by the service.</li><li>The device didn't communicate with Microsoft Intune in the last 28 days</li><li>The device has a conflict with policies or with Autopatch group membership</li></ul></ul> |
| Not registered |<ul><li>**Autopatch group conflict**: The device has a conflict with Autopatch group membership</li><li>**Prerequisites failed**: The device failed to pass one or more [post-device registration readiness checks](../deploy/windows-autopatch-post-reg-readiness-checks.md).</li><li>**Excluded**: Devices with this status are removed from the Windows Autopatch service only. Microsoft assumes you manage these devices yourself in some capacity.</li></ul> |
### View only excluded devices
You can view the excluded devices in the Not registered tab to make it easier for you to bulk restore devices that were previously excluded from the Windows Autopatch service.
**To view only excluded devices:**
1. In the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), navigate to **Windows Autopatch** > **Devices**.
2. In the **Not registered** tab, select **Excluded** from the filter list. Leave all other filter options unselected.
## Move devices in between deployment rings
If you want to move devices to different deployment rings after Windows Autopatch's deployment ring assignment, you can repeat the following steps for one or more devices from the **Devices report**.
> [!IMPORTANT]
> **You can only move devices in between deployment rings within the same Autopatch group**. You can't move devices in between deployment rings across different Autopatch groups. If you try to select a device that belongs to one Autopatch group, and another device that belongs to a different Autopatch group, you'll receive the following error message on the top right corner of the Microsoft Intune portal: **An error occurred. Please select devices within the same Autopatch group**.
**To move devices in between deployment rings:**
> [!NOTE]
> You can only move devices to other deployment rings when the device's Autopatch readiness status appears as **Registered** and the Update status is **Active**.
1. In the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), select **Devices** in the left pane.
1. Under **Manage updates** section, select **Windows updates**.
1. In the **Devices report**, select one or more devices you want to assign. All selected devices are assigned to the deployment ring you specify.
1. Select **Device actions** from the menu.
1. Select **Assign ring**. A fly-in opens.
1. Use the dropdown menu to select the deployment ring to move devices to, and then select **Save**. The Ring assigned by column changes to **Pending**.
1. When the assignment is complete, the **Ring assigned by** column changes to Admin (which indicates that you made the change) and the **Ring** column shows the new deployment ring assignment.
> [!WARNING]
> Moving devices between deployment rings through directly changing Microsoft Entra group membership isn't supported and might 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.
## Register devices into Autopatch groups
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
An Autopatch group is a logical container or unit that groups several [Microsoft Entra groups](/entra/fundamentals/groups-view-azure-portal), and software update policies. For more information, see [Windows Autopatch groups](../deploy/windows-autopatch-groups-overview.md).
When you [create an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) or [edit an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group) to add or remove deployment rings, the device-based Microsoft Entra groups you use when setting up your deployment rings, are scanned to see if devices need to be registered with the Windows Autopatch service.
If devices aren't registered, Autopatch groups start the device registration process by using your existing device-based Microsoft Entra groups.
- For more information, see [create an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) or [edit an Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-an-autopatch-group) to register devices into Autopatch groups.
- For more information about moving devices between deployment rings, see [Move devices in between deployment rings](#move-devices-in-between-deployment-rings).
### Supported scenarios when nesting other Microsoft Entra groups
Windows Autopatch also supports the following Microsoft Entra nested group scenarios:
@ -48,94 +125,7 @@ Microsoft Entra groups synced up from:
- On-premises Active Directory groups (Windows Server AD)
- [Configuration Manager collections](/mem/configmgr/core/clients/manage/collections/create-collections#bkmk_aadcollsync)
> [!WARNING]
> It isn't recommended to sync Configuration Manager collections straight to the **Windows Autopatch Device Registration** Microsoft Entra group. Use a different Microsoft Entra group when syncing Configuration Manager collections to Microsoft Entra groups then you can nest this or these groups into the **Windows Autopatch Device Registration** Microsoft Entra group.
> [!IMPORTANT]
> The **Windows Autopatch Device Registration** Microsoft Entra group only supports **one level** of Microsoft Entra nested groups.
<a name='clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant'></a>
### Clean up dual state of Microsoft Entra hybrid joined and Azure registered devices in your Microsoft Entra tenant
An [Microsoft Entra dual state](/azure/active-directory/devices/hybrid-azuread-join-plan#handling-devices-with-azure-ad-registered-state) occurs when a device is initially connected to Microsoft Entra ID as an [Microsoft Entra registered](/azure/active-directory/devices/concept-azure-ad-register) device. However, when you enable Microsoft Entra hybrid join, the same device is connected twice to Microsoft Entra ID but as a [Hybrid Microsoft Entra device](/azure/active-directory/devices/concept-azure-ad-join-hybrid).
In the dual state, you end up having two Microsoft Entra device records with different join types for the same device. In this case, the Hybrid Microsoft Entra device record takes precedence over the Microsoft Entra registered device record for any type of authentication in Microsoft Entra ID, which makes the Microsoft Entra registered device record stale.
It's recommended to detect and clean up stale devices in Microsoft Entra ID before registering devices with Windows Autopatch, see [How To: Manage stale devices in Microsoft Entra ID](/azure/active-directory/devices/manage-stale-devices).
> [!WARNING]
> If you don't clean up stale devices in Microsoft Entra ID before registering devices with Windows Autopatch, you might end up seeing devices failing to meet the **Intune or Cloud-Attached (Device must be either Intune-managed or Co-managed)** pre-requisite check in the **Not ready** tab because it's expected that these stale Microsoft Entra devices aren't enrolled into the Intune service anymore.
## Prerequisites for device registration
To be eligible for Windows Autopatch management, devices must meet a minimum set of required software-based prerequisites:
- Windows 10 (1809+)/11 Enterprise or Professional editions (only x64 architecture).
- Either [Microsoft Entra hybrid joined](/azure/active-directory/devices/concept-azure-ad-join-hybrid) or [Microsoft Entra joined only](/azure/active-directory/devices/concept-azure-ad-join-hybrid) (personal devices aren't supported).
- Managed by Microsoft Intune.
- [Already enrolled into Microsoft Intune](/mem/intune/user-help/enroll-windows-10-device) and/or [Configuration Manager co-management](/windows/deployment/windows-autopatch/prepare/windows-autopatch-prerequisites#configuration-manager-co-management-requirements).
- Must switch the following Microsoft Configuration Manager [co-management workloads](/mem/configmgr/comanage/how-to-switch-workloads) to Microsoft Intune (either set to Pilot Intune or Intune):
- Windows updates policies
- Device configuration
- Office Click-to-run
- Last Intune device check in completed within the last 28 days.
> [!IMPORTANT]
> Windows Autopatch supports registering [Windows 10 Long-Term Servicing Channel (LTSC)](/windows/whats-new/ltsc/) devices that are being currently serviced by the [Windows LTSC](/windows/release-health/release-information). The service only supports managing the [Windows quality updates](../operate/windows-autopatch-windows-quality-update-overview.md) workload for devices currently serviced by the LTSC. Windows Update for Business service and Windows Autopatch don't offer Windows feature updates for devices that are part of the LTSC. You must either use [LTSC media](https://www.microsoft.com/evalcenter/evaluate-windows-10-enterprise) or the [Configuration Manager operating system deployment capabilities to perform an in-place upgrade](/mem/configmgr/osd/deploy-use/upgrade-windows-to-the-latest-version) for Windows devices that are part of the LTSC.
For more information, see [Windows Autopatch Prerequisites](../prepare/windows-autopatch-prerequisites.md).
## About the Registered, Not ready and Not registered tabs
> [!IMPORTANT]
> Registered devices can appear in the Registered, Not ready, or Not registered tabs. When devices successfully register with the service, the devices are listed in the Registered tab. However, even if the device(s)is successfully registered, they can be part of Not ready tab. If devices fail to register, the devices are listed in the Not registered tab.
Windows Autopatch has three tabs within its device blade. Each tab is designed to provide a different set of device readiness statuses so the IT admin knows where to go to monitor, and fix potential device health issues.
| Device blade tab | Purpose | Expected device readiness status |
| ----- | ----- | ----- |
| Registered | 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. | Prerequisites failed |
## Device readiness statuses
The following are the possible device readiness statuses in Windows Autopatch:
| Readiness status | Description | Device blade tab |
| ----- | ----- | ----- |
| Active | Devices with this status successfully passed all prerequisite checks and then successfully registered with Windows Autopatch. Additionally, devices with this status successfully passed all post-device registration readiness checks. | Registered |
| 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 Intune in the last 28 days. | Not ready |
| Prerequisites failed | Devices with this status haven't passed one or more prerequisite checks and haven't successfully registered with Windows Autopatch | Not registered |
## Built-in roles required for device registration
A role defines the set of permissions granted to users assigned to that role. You can use the **Intune Service Administrator** role to register devices.
For more information, see [Microsoft Entra built-in roles](/azure/active-directory/roles/permissions-reference) and [Role-based access control (RBAC) with Microsoft Intune](/mem/intune/fundamentals/role-based-access-control).
If you want to assign less-privileged user accounts to perform specific tasks in the Windows Autopatch portal, such as register devices with the service, you can add these user accounts into one of the two Microsoft Entra groups created during the [tenant enrollment](../prepare/windows-autopatch-enroll-tenant.md) process:
| Microsoft Entra group name | Discover devices | Modify columns | Refresh device list | Export to .CSV | Device actions |
| ----- | ----- | ----- | ----- | ----- | ----- |
| Modern Workplace Roles - Service Administrator | Yes | Yes | Yes | Yes | Yes |
| Modern Workplace Roles - Service Reader | No | Yes | Yes | Yes | No |
> [!TIP]
> If you're adding less-privileged user accounts into the **Modern Workplace Roles - Service Administrator** Microsoft Entra group, it's recommended to add the same users as owners of the **Windows Autopatch Device Registration** Microsoft Entra group. Owners of the **Windows Autopatch Device Registration** Microsoft Entra group can add new devices as members of the group for registration purposes.<p>For more information, see [assign an owner of member of a group in Microsoft Entra ID](/azure/active-directory/privileged-identity-management/groups-assign-member-owner#assign-an-owner-or-member-of-a-group).</p>
## Details about the device registration process
Registering your devices with Windows Autopatch does the following:
1. Makes a record of devices in the service.
2. Assign devices to the [two deployment ring sets](../deploy/windows-autopatch-groups-overview.md#about-deployment-rings) and other groups required for software update management.
For more information, see [Device registration overview](../deploy/windows-autopatch-device-registration-overview.md).
### Windows Autopatch on Windows 365 Enterprise Workloads
## Windows Autopatch on Windows 365 Enterprise Workloads
Windows 365 Enterprise gives IT admins the option to register devices with the Windows Autopatch service as part of the Windows 365 provisioning policy creation. This option provides a seamless experience for admins and users to ensure your Cloud PCs are always up to date. When IT admins decide to manage their Windows 365 Cloud PCs with Windows Autopatch, the Windows 365 provisioning policy creation process calls Windows Autopatch device registration APIs to register devices on behalf of the IT admin.
@ -148,22 +138,19 @@ Windows 365 Enterprise gives IT admins the option to register devices with the W
1. Provide a policy name and select **Join Type**. For more information, see [Device join types](/windows-365/enterprise/identity-authentication#device-join-types).
1. Select **Next**.
1. Choose the desired image and select **Next**.
1. Under the **Microsoft managed services** section, select **Windows Autopatch**. Then, select **Next**. If the *Windows Autopatch (preview) can't manage your Cloud PCs until a Global Admin has finished setting it up.* message appears, you must [enroll your tenant](../prepare/windows-autopatch-enroll-tenant.md) to continue.
1. Under the **Microsoft managed services** section, select **Windows Autopatch**. Then, select **Next**. If the *Windows Autopatch (preview) can't manage your Cloud PCs until a Global Admin has finished setting it up.* message appears, you must [activate Windows Autopatch features](../prepare/windows-autopatch-feature-activation.md) to continue.
1. Assign your policy accordingly and select **Next**.
1. Select **Create**. Now your newly provisioned Windows 365 Enterprise Cloud PCs will automatically be enrolled and managed by Windows Autopatch.
1. Select **Create**. Now your newly provisioned Windows 365 Enterprise Cloud PCs are automatically enrolled and managed by Windows Autopatch.
For more information, see [Create a Windows 365 Provisioning Policy](/windows-365/enterprise/create-provisioning-policy).
> [!IMPORTANT]
> Starting in May 2023, Windows 365 Cloud PC devices are assigned to two deployment ring sets, the service-based and the software-based deployment rings. Additionally, once registered with Windows Autopatch, Windows 365 Cloud PC devices are automatically added to the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group). For more information, see [service-based versus software update-based deployment ring sets](../deploy/windows-autopatch-groups-overview.md#service-based-versus-software-update-based-deployment-rings).
### Windows Autopatch on Azure Virtual Desktop workloads
## Windows Autopatch on Azure Virtual Desktop workloads
Windows Autopatch is available for your Azure Virtual Desktop workloads. Enterprise admins can provision their Azure Virtual Desktop workloads to be managed by Windows Autopatch using the existing device registration process.
Windows Autopatch provides the same scope of service with virtual machines as it does with [physical devices](#windows-autopatch-groups-device-registration). However, Windows Autopatch defers any Azure Virtual Desktop specific support to [Azure support](#contact-support-for-device-registration-related-incidents), unless otherwise specified.
Windows Autopatch provides the same scope of service with virtual machines as it does with [physical devices](../deploy/windows-autopatch-device-registration-overview.md). However, Windows Autopatch defers any Azure Virtual Desktop specific support to [Azure support](#contact-support-for-device-registration-related-incidents), unless otherwise specified.
#### Prerequisites
### Prerequisites
Windows Autopatch for Azure Virtual Desktop follows the same [prerequisites](../prepare/windows-autopatch-prerequisites.md) as Windows Autopatch, and the [Azure Virtual Desktop prerequisites](/azure/virtual-desktop/prerequisites).
@ -177,9 +164,9 @@ The following Azure Virtual Desktop features aren't supported:
- Pooled non persistent virtual machines
- Remote app streaming
#### Deploy Autopatch on Azure Virtual Desktop
### Deploy Autopatch on Azure Virtual Desktop
Azure Virtual Desktop workloads can be registered into Windows Autopatch by using the same method as your [physical devices](#windows-autopatch-groups-device-registration).
Azure Virtual Desktop workloads can be registered into Windows Autopatch by using the same method as your physical devices.
For ease of deployment, we recommend nesting a dynamic device group in your Autopatch device registration group. The dynamic device group would target the **Name** prefix defined in your session host, but **exclude** any Multi-Session Session Hosts. For example:
@ -187,13 +174,30 @@ For ease of deployment, we recommend nesting a dynamic device group in your Auto
| ----- | ----- |
| Windows Autopatch - Host Pool Session Hosts | <ul><li>`(device.displayName -contains "AP")`</li><li>`(device.deviceOSType -ne "Windows 10 Enterprise for Virtual Desktops")`</li></ul> |
<a name='clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant'></a>
### Clean up dual state of Microsoft Entra hybrid joined and Azure registered devices in your Microsoft Entra tenant
An [Microsoft Entra dual state](/entra/identity/devices/hybrid-join-plan#handling-devices-with-azure-ad-registered-state) occurs when a device is initially connected to Microsoft Entra ID as an [Microsoft Entra registered](/entra/identity/devices/concept-device-registration) device. However, when you enable Microsoft Entra hybrid join, the same device is connected twice to Microsoft Entra ID but as a [Hybrid Microsoft Entra device](/entra/identity/devices/concept-hybrid-join).
In the dual state, you end up having two Microsoft Entra device records with different join types for the same device. In this case, the Hybrid Microsoft Entra device record takes precedence over the Microsoft Entra registered device record for any type of authentication in Microsoft Entra ID, which makes the Microsoft Entra registered device record stale.
It's recommended to detect and clean up stale devices in Microsoft Entra ID before registering devices with Windows Autopatch, see [How To: Manage stale devices in Microsoft Entra ID](/entra/identity/devices/manage-stale-devices).
> [!WARNING]
> If you don't clean up stale devices in Microsoft Entra ID before registering devices with Windows Autopatch, you might end up seeing devices failing to meet the **Intune or Cloud-Attached (Device must be either Intune-managed or Co-managed)** pre-requisite check in the **Not ready** tab because it's expected that these stale Microsoft Entra devices aren't enrolled into the Intune service anymore.
### Contact support for device registration-related incidents
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
Support is available either through Windows 365, or the Windows Autopatch Service Engineering team for device registration-related incidents.
- For Windows 365 support, see [Get support](/mem/get-support).
- For Azure Virtual Desktop support, see [Get support](https://azure.microsoft.com/support/create-ticket/).
- For Windows Autopatch support, see [Submit a support request](/windows/deployment/windows-autopatch/operate/windows-autopatch-support-request).
- For Windows Autopatch support, see [Submit a support request](../manage/windows-autopatch-support-request.md).
---
## Device management lifecycle scenarios
@ -203,17 +207,17 @@ There's a few more device management lifecycle scenarios to consider when planni
If a device was previously registered into the Windows Autopatch service, but it needs to be reimaged, you must run one of the device provisioning processes available in Microsoft Intune to reimage the device.
The device will be rejoined to Microsoft Entra ID (either Hybrid or Microsoft Entra-only). Then, re-enrolled into Intune as well. No further action is required from you or the Windows Autopatch service, because the Microsoft Entra device ID record of that device remains the same.
The device is rejoined to Microsoft Entra ID (either Hybrid or Microsoft Entra-only). Then, re-enrolled into Intune as well. No further action is required from you or the Windows Autopatch service, because the Microsoft Entra device ID record of that device remains the same.
### Device repair and hardware replacement
If you need to repair a device that was previously registered into the Windows Autopatch service, by replacing the motherboard, non-removable network interface cards (NIC) or hard drive, you must re-register the device into the Windows Autopatch service, because a new hardware ID is generated when there are major hardware changes, such as:
If you need to repair a device that was previously registered into the Windows Autopatch service, by replacing the motherboard, nonremovable network interface cards (NIC) or hard drive, you must re-register the device into the Windows Autopatch service, because a new hardware ID is generated when there are major hardware changes, such as:
- SMBIOS UUID (motherboard)
- MAC address (non-removable NICs)
- MAC address (nonremovable NICs)
- OS hard drive's serial, model, manufacturer information
When one of these hardware changes occurs, Microsoft Entra ID creates a new device ID record for that device, even if it's technically the same device.
> [!IMPORTANT]
> If a new Microsoft Entra device ID is generated for a device that was previously registered into the Windows Autopatch service, even if it's technically same device, the new Microsoft Entra device ID must be added either through device direct membership or through nested Microsoft Entra dynamic/assigned group into the **Windows Autopatch Device Registration** Microsoft Entra group. This process guarantees that the newly generated Microsoft Entra device ID is registered with Windows Autopatch and that the device continues to have its software updates managed by the service.
> If a new Microsoft Entra device ID is generated for a device that was previously registered into the Windows Autopatch service, even if it's technically same device, the new Microsoft Entra device ID must be added either through device direct membership or through nested Microsoft Entra dynamic/assigned group in the Windows Autopatch group experience. This process guarantees that the newly generated Microsoft Entra device ID is registered with Windows Autopatch and that the device continues to have its software updates managed by the service.

14
windows/deployment/windows-autopatch/includes/windows-autopatch-applies-to-all-licenses.md Normal file
View File

@ -0,0 +1,14 @@
---
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.service: windows-client
ms.subservice: autopatch
ms.topic: include
ms.date: 09/16/2024
ms.localizationpriority: medium
---
<!--This file is used throughout the Windows Autopatch documentation. -->
> [!IMPORTANT]
> The information in section applies to Business premium, A3+, E3+ and F3 licenses. For more information, see [Features and capabilities](../overview/windows-autopatch-overview.md#features-and-capabilities) and [Licenses and entitlements](../prepare/windows-autopatch-prerequisites.md#licenses-and-entitlements).

8
windows/deployment/update/includes/wufb-deployment-audience-graph-explorer.md → windows/deployment/windows-autopatch/includes/windows-autopatch-audience-graph-explorer.md
View File

@ -1,11 +1,11 @@
---
author: mestew
ms.author: mstewart
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.subservice: itpro-updates
ms.service: windows-client
ms.subservice: autopatch
ms.topic: include
ms.date: 02/14/2023
ms.date: 09/16/2024
ms.localizationpriority: medium
---
<!--This file is shared by deployment-service-drivers.md and the deployment-service-feature-updates.md articles. Headings may be driven by article context. 7512398 -->

14
windows/deployment/windows-autopatch/includes/windows-autopatch-business-premium-a3-licenses.md Normal file
View File

@ -0,0 +1,14 @@
---
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.service: windows-client
ms.subservice: autopatch
ms.topic: include
ms.date: 09/16/2024
ms.localizationpriority: medium
---
<!--This file is used throughout the Windows Autopatch documentation. -->
> [!IMPORTANT]
> To [activate all Windows Autopatch features](../overview/windows-autopatch-overview.md#windows-enterprise-e3-and-f3-licenses), you must have Windows 10/11 Enterprise E3+ or F3 (included in Microsoft 365 F3, E3, or E5) licenses. [Feature activation](../prepare/windows-autopatch-feature-activation.md) is optional and at no additional cost to you when you have Windows 10/11 Enterprise E3+ or F3 licenses. For more information, see [Licenses and entitlements](../prepare/windows-autopatch-prerequisites.md#licenses-and-entitlements).

28
windows/deployment/update/includes/wufb-deployment-driver-policy-considerations.md → windows/deployment/windows-autopatch/includes/windows-autopatch-driver-policy-considerations.md
View File

@ -1,16 +1,16 @@
---
author: mestew
ms.author: mstewart
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.subservice: itpro-updates
ms.service: windows-client
ms.subservice: autopatch
ms.topic: include
ms.date: 02/14/2023
ms.date: 09/16/2024
ms.localizationpriority: medium
---
<!--This file is shared by deployment-service-drivers.md, deployment-service-troubleshoot.md, and the deployment-service-prerequisites.md articles. Headings may be driven by article context. 7512398 -->
<!--This file is shared by windows-autopatch-driver-and-firmware-programmatic-controls.md, windows-autopatch-troubleshoot-programmatic-controls.md, and the deployment-service-prerequisites.md articles. Headings may be driven by article context. 7512398 -->
It's possible for the service to receive content approval but the content doesn't get installed on the device because of a Group Policy, CSP, or registry setting on the device. In some cases, organizations specifically configure these policies to fit their current or future needs. For instance, organizations may want to review applicable driver content through the deployment service, but not allow installation. Configuring this sort of behavior can be useful, especially when transitioning management of driver updates due to changing organizational needs. The following list describes driver related update policies that can affect deployments through the deployment service:
It's possible for the service to receive content approval but the content doesn't get installed on the device because of a Group Policy, CSP, or registry setting on the device. In some cases, organizations specifically configure these policies to fit their current or future needs. For instance, organizations may want to review applicable driver content, but not allow installation. Configuring this sort of behavior can be useful, especially when transitioning management of driver updates due to changing organizational needs. The following list describes driver related update policies that can affect deployments:
### Policies that exclude drivers from Windows Update for a device
@ -22,10 +22,10 @@ The following policies exclude drivers from Windows Update for a device:
- **Registry**: `HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\ExcludeWUDriversFromQualityUpdates` set to `1`
- **Intune**: [**Windows Drivers** update setting](/mem/intune/protect/windows-update-settings#update-settings) for the update ring set to `Block`
**Behavior with the deployment service**: Devices with driver exclusion polices that are enrolled for **drivers** and added to an audience though the deployment service:
- Will display the applicable driver content in the deployment service
- Won't install drivers that are approved from the deployment service
- If drivers are deployed to a device that's blocking them, the deployment service displays the driver is being offered and reporting displays the install is pending.
**Behavior**: Devices with driver exclusion polices that are enrolled for **drivers** and added to an audience:
- Will display the applicable driver content
- Won't install drivers that are approved
- If drivers are deployed to a device that's blocking them, Windows Autopatch displays the driver is being offered and reporting displays the install is pending.
### Policies that define the source for driver updates
@ -37,9 +37,9 @@ The following policies define the source for driver updates as either Windows Up
- **Registry**: `HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\SetPolicyDrivenUpdateSourceForDriverUpdates` set to `0`. Under `\AU`, `UseUpdateClassPolicySource` also needs to be set to `1`
- **Intune**: Not applicable. Intune deploys updates using Windows Update for Business. [Co-managed clients from Configuration Manager](/mem/configmgr/comanage/overview?toc=/mem/configmgr/cloud-attach/toc.json&bc=/mem/configmgr/cloud-attach/breadcrumb/toc.json) with the workload for Windows Update policies set to Intune will also use Windows Update for Business.
**Behavior with the deployment service**: Devices with these update source policies that are enrolled for **drivers** and added to an audience though the deployment service:
- Will display the applicable driver content in the deployment service
- Will install drivers that are approved from the deployment service
**Behavior**: Devices with these update source policies that are enrolled for **drivers** and added to an audience:
- Will display the applicable driver content
- Will install drivers that are approved
> [!NOTE]
> When the scan source for drivers is set to WSUS, the deployment service doesn't get inventory events from devices. This means that the deployment service won't be able to report the applicability of a driver for the device.
> When the scan source for drivers is set to WSUS, Windows Autopatch doesn't get inventory events from devices. This means that Windows Autopatch won't be able to report the applicability of a driver for the device.

8
windows/deployment/update/includes/wufb-deployment-enroll-device-graph-explorer.md → windows/deployment/windows-autopatch/includes/windows-autopatch-enroll-device-graph-explorer.md
View File

@ -1,11 +1,11 @@
---
author: mestew
ms.author: mstewart
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.subservice: itpro-updates
ms.service: windows-client
ms.subservice: autopatch
ms.topic: include
ms.date: 02/14/2023
ms.date: 09/16/2024
ms.localizationpriority: medium
---
<!--This file is shared by deployment-service-drivers.md and the deployment-service-feature-updates.md articles. Headings may be driven by article context. 7512398 -->

14
windows/deployment/windows-autopatch/includes/windows-autopatch-enterprise-e3-f3-licenses.md Normal file
View File

@ -0,0 +1,14 @@
---
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.service: windows-client
ms.subservice: autopatch
ms.topic: include
ms.date: 09/16/2024
ms.localizationpriority: medium
---
<!--This file is used throughout the Windows Autopatch documentation. -->
> [!IMPORTANT]
> **The information in this article or section only applies if you have Windows Enterprise E3+ or F3 licenses (included in Microsoft 365 F3, E3, or E5) licenses and have [activated Windows Autopatch features](../overview/windows-autopatch-overview.md#windows-enterprise-e3-and-f3-licenses).**<p>[Feature activation](../prepare/windows-autopatch-feature-activation.md) is optional and at no additional cost to you if you have Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5) licenses.</p><p>For more information, see [Licenses and entitlements](../prepare/windows-autopatch-prerequisites.md#licenses-and-entitlements). If you choose not to go through feature activation, you can still use the Windows Autopatch service for the features included in [Business premium and A3+ licenses](../overview/windows-autopatch-overview.md#business-premium-and-a3-licenses).</p>

10
windows/deployment/update/includes/wufb-deployment-find-device-name-graph-explorer.md → windows/deployment/windows-autopatch/includes/windows-autopatch-find-device-name-graph-explorer.md
View File

@ -1,16 +1,16 @@
---
author: mestew
ms.author: mstewart
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.subservice: itpro-updates
ms.service: windows-client
ms.subservice: autopatch
ms.topic: include
ms.date: 02/14/2023
ms.date: 09/16/2024
ms.localizationpriority: medium
---
<!--This file is shared by deployment-service-drivers.md, deployment-service-expedited-updates.md, and the deployment-service-feature-updates.md articles. Headings may be driven by article context. 7512398 -->
Use the [device](/graph/api/resources/device) resource type to find clients to enroll into the deployment service. Change the query parameters to fit your specific needs. For more information, see [Use query parameters](/graph/query-parameters).
Use the [device](/graph/api/resources/device) resource type to find clients to enroll into Windows Autopatch. Change the query parameters to fit your specific needs. For more information, see [Use query parameters](/graph/query-parameters).
- Displays the **AzureAD Device ID** and **Name** of all devices:

12
windows/deployment/update/includes/wufb-deployment-graph-explorer-permissions.md → windows/deployment/windows-autopatch/includes/windows-autopatch-graph-explorer-permissions.md
View File

@ -1,18 +1,18 @@
---
author: mestew
ms.author: mstewart
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.subservice: itpro-updates
ms.service: windows-client
ms.subservice: autopatch
ms.topic: include
ms.date: 02/14/2023
ms.date: 09/16/2024
ms.localizationpriority: medium
---
<!--This file is shared by deployment-service-drivers.md, deployment-service-expedited-updates.md, and the deployment-service-feature-updates.md articles. Headings may be driven by article context. 7512398 -->
<!--This file is shared by windows-autopatch-driver-and-firmware-programmatic-controls.md, windows-autopatch-windows-quality-update-programmatic-controls.md, and the deployment-service-feature-updates.md articles. Headings may be driven by article context. 7512398 -->
The following permissions are needed for the queries listed in this article:
- [WindowsUpdates.ReadWrite.All](/graph/permissions-reference#windows-updates-permissions) for [Windows Update for Business deployment service](/graph/api/resources/adminwindowsupdates) operations.
- [WindowsUpdates.ReadWrite.All](/graph/permissions-reference#windows-updates-permissions) for [Windows Autopatch](/graph/api/resources/adminwindowsupdates) operations.
- At least [Device.Read.All](/graph/permissions-reference#device-permissions) permission to display [device](/graph/api/resources/device) information.
Some roles, such as the [Windows Update deployment administrator](/azure/active-directory/roles/permissions-reference#windows-update-deployment-administrator), already have these permissions.

13
windows/deployment/update/includes/wufb-deployment-graph-explorer.md → windows/deployment/windows-autopatch/includes/windows-autopatch-graph-explorer.md
View File

@ -1,14 +1,14 @@
---
author: mestew
ms.author: mstewart
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.subservice: itpro-updates
ms.service: windows-client
ms.subservice: autopatch
ms.topic: include
ms.date: 02/14/2023
ms.date: 09/16/2024
ms.localizationpriority: medium
---
<!--This file is shared by deployment-service-drivers.md, deployment-service-expedited-updates.md, and the deployment-service-feature-updates.md articles. Headings may be driven by article context. 7512398 -->
<!--This file is shared by windows-autopatch-driver-and-firmware-programmatic-controls.md, windows-autopatch-windows-quality-update-programmatic-controls.md, and the windows-autopatch-windows-feature-update-programmatic-controls.md articles. Headings may be driven by article context. 7512398 -->
For this article, you'll use Graph Explorer to make requests to the [Microsoft Graph APIs](/graph/api/resources/adminwindowsupdates) to retrieve, add, delete, and update data. Graph Explorer is a developer tool that lets you learn about Microsoft Graph APIs. For more information about using Graph Explorer, see [Get started with Graph Explorer](/graph/graph-explorer/graph-explorer-overview).
@ -21,8 +21,7 @@ For this article, you'll use Graph Explorer to make requests to the [Microsoft G
1. You may need to enable the [`WindowsUpdates.ReadWrite.All` permission](/graph/permissions-reference#windows-updates-permissions) to use the queries in this article. To enable the permission:
1. Select the **Modify permissions** tab in Graph Explorer.
1. In the permissions dialog box, select the **WindowsUpdates.ReadWrite.All** permission then select **Consent**. You may need to sign in again to grant consent.
:::image type="content" source="../media/7512398-wufbds-graph-modify-permission.png" alt-text="Screenshot of the modify permissions tab in Graph Explorer" lightbox="../media/7512398-wufbds-graph-modify-permission.png" :::
:::image type="content" source="../media/7512398-graph-modify-permission.png" alt-text="Screenshot of the modify permissions tab in Graph Explorer" lightbox="../media/7512398-graph-modify-permission.png" :::
1. To make requests:
1. Select either GET, POST, PUT, PATCH, or DELETE from the drop-down list for the HTTP method.

14
windows/deployment/update/includes/wufb-deployment-graph-unenroll.md → windows/deployment/windows-autopatch/includes/windows-autopatch-graph-unenroll.md
View File

@ -1,19 +1,19 @@
---
author: mestew
ms.author: mstewart
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.subservice: itpro-updates
ms.service: windows-client
ms.subservice: autopatch
ms.topic: include
ms.date: 02/14/2023
ms.date: 09/16/2024
ms.localizationpriority: medium
---
<!--This file is shared by deployment-service-drivers.md and the deployment-service-feature-updates.md articles. Headings may be driven by article context. 7512398 -->
<!--This file is shared by windows-autopatch-driver-and-firmware-programmatic-controls.md, windows-autopatch-windows-feature-update-programmatic-controls.md articles. Headings may be driven by article context. 7512398 -->
When a device no longer requires management, unenroll it from the deployment service. Just like [enrolling a device](#enroll-devices), specify either `driver` or `feature` as the value for the `updateCategory`. The device will no longer receive updates from the deployment service for the specified update category. Depending on the device's configuration, it may start to receive updates from Windows Update. For instance, if a device is still enrolled for feature updates, but it's unenrolled from drivers:
When a device no longer requires management, unenroll it from Windows Autopatch. Just like [enrolling a device](#enroll-devices), specify either `driver` or `feature` as the value for the `updateCategory`. The device will no longer receive updates from Windows Autopatch for the specified update category. Depending on the device's configuration, it may start to receive updates from Windows Update. For instance, if a device is still enrolled for feature updates, but it's unenrolled from drivers:
- Existing driver deployments from the service won't be offered to the device
- The device continues to receive feature updates from the deployment service
- The device continues to receive feature updates from Windows Autopatch
- Drivers may start being installed from Windows Update depending on the device's configuration
To unenroll a device, POST to [updatableAssets](/graph/api/resources/windowsupdates-updatableasset) using [unenrollAssets](/graph/api/windowsupdates-updatableasset-unenrollassets). In the request body, specify:

15
windows/deployment/windows-autopatch/includes/windows-autopatch-limitations.md Normal file
View File

@ -0,0 +1,15 @@
---
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.service: windows-client
ms.subservice: autopatch
ms.topic: include
ms.date: 09/16/2024
ms.localizationpriority: medium
---
<!--This file is shared by windows-autopatch-overview.md and the windows-autopatch-prerequisites.md articles. Headings may be driven by article context. 7512398 -->
Windows Autopatch is a Windows service hosted in Azure Commercial that uses Windows diagnostic data. While customers with GCC tenants may choose to use it, Windows Autopatch is outside the [US Government community compliance (GCC)](/office365/servicedescriptions/office-365-platform-service-description/office-365-us-government/gcc#us-government-community-compliance) boundary. For a list of GCC offerings for Microsoft products and services, see the [Microsoft Trust Center](/compliance/regulatory/offering-home).
Windows Autopatch isn't available in Azure Government for [Office 365 GCC High and DoD](/office365/servicedescriptions/office-365-platform-service-description/office-365-us-government/gcc-high-and-dod) tenants.

10
windows/deployment/update/includes/wufb-deployment-update-health-tools-logs.md → windows/deployment/windows-autopatch/includes/windows-autopatch-update-health-tools-logs.md
View File

@ -1,14 +1,14 @@
---
author: mestew
ms.author: mstewart
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.subservice: itpro-updates
ms.service: windows-client
ms.subservice: autopatch
ms.topic: include
ms.date: 02/14/2023
ms.date: 09/16/2024
ms.localizationpriority: medium
---
<!--This file is shared by deployment-service-expedite.md and the deployment-service-troubleshoot.md articles. Headings may be driven by article context. 7512398 -->
<!--This file is shared by windows-autopatch-windows-quality-update-programmatic-controls, and windows-autopatch-troubleshoot-programmatic-controls.md articles. Headings may be driven by article context. 7512398 -->
## Log location for the Update Health Tools
The Update Health Tools are used when you deploy expedited updates. In some cases, you may wish to review the logs for the Update Health Tools.

43
windows/deployment/windows-autopatch/manage/windows-autopatch-customize-windows-update-settings.md
View File

@ -1,7 +1,7 @@
---
title: Customize Windows Update settings Autopatch groups experience
description: How to customize Windows Updates with Autopatch groups
ms.date: 07/08/2024
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
@ -17,9 +17,11 @@ ms.collection:
# Customize Windows Update settings
You can customize the Windows Update deployment schedule for each deployment ring in Windows Autopatch groups per your business and organizational needs. This capability is allowed for both [Default](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group) and [Custom Autopatch groups](../deploy/windows-autopatch-groups-overview.md#about-custom-autopatch-groups). However, we recommend that you remain within service defined boundaries to maintain compliance.
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
When the deployment cadence is customized, Windows Autopatch will override our service defaults with your preferred deployment cadence. Depending on the selected options, devices with [customized schedules](#scheduled-install) may not count towards the Windows Autopatch [Windows quality update service level objective](../operate/windows-autopatch-groups-windows-quality-update-overview.md#service-level-objective).
You can customize the Windows Update deployment schedule for each deployment ring in Windows Autopatch groups per your business and organizational needs. However, we recommend that you remain within service defined boundaries to maintain compliance.
When the deployment cadence is customized, Windows Autopatch overrides our service defaults with your preferred deployment cadence. Depending on the selected options, devices with [customized schedules](#scheduled-install) might not count towards the Windows Autopatch [Windows quality update service level objective](../manage/windows-autopatch-windows-quality-update-overview.md#service-level-objective).
## Deployment cadence
@ -37,35 +39,30 @@ For each tenant, at the deployment ring level, there are two cadence types to co
With the deadline-drive cadence type, you can control and customize the deferral, deadline, and grace period to meet your specific business needs and organizational requirements.
There are certain limits that Windows Autopatch defines and you'll only be able to make changes with those boundaries. The following boundaries are implemented so that Windows Autopatch can maintain update compliance.
| Boundary | Description |
| ----- | ----- |
| Deferrals and deadlines | Windows Autopatch will enforce that deadline plus deferral days for a deployment ring to be less than or equal to 14 days. |
| Grace period | The permitted customization range is zero to seven days. |
> [!NOTE]
> The configured grace period will apply to both Windows quality updates and Windows feature updates.
Each deployment ring can be scheduled independent of the others, and there are no dependencies that the previous deployment ring must be scheduled before the next ring. Further, if the cadence type is set as **Deadline-driven**, the automatic update behavior setting, **Reset to default** in the Windows Update for Business policy, will be applied.
Each deployment ring can be scheduled independent of the others, and there are no dependencies that the previous deployment ring must be scheduled before the next ring. Further, if the cadence type is set as **Deadline-driven**, the automatic update behavior setting, **Reset to default** in the Windows Update for Business policy, are applied.
It's possible for you to change the cadence from the Windows Autopatch Release management blade while update deployments are in progress. Windows Autopatch will abide by the principle to always respect your preferences over service-defined values.
It's possible for you to change the cadence from the Windows Autopatch groups blade while update deployments are in progress. Windows Autopatch abides by the principle to always respect your preferences over service-defined values.
However, if an update has already started for a particular deployment ring, Windows Autopatch won't be able to change the cadence for that ring during that ongoing update cycle. The changes will only be effective in the next update cycle.
However, if an update already started for a particular deployment ring, Windows Autopatch isn't able to change the cadence for that ring during that ongoing update cycle. The changes will only be effective in the next update cycle.
#### Scheduled install
> [!NOTE]
>If you select the Schedule install cadence type, the devices in that ring won't be counted towards the [Windows quality update service level objective](../operate/windows-autopatch-groups-windows-quality-update-overview.md#service-level-objective).
>If you select the Schedule install cadence type, the devices in that ring won't be counted towards the [Windows quality update service level objective](../manage/windows-autopatch-windows-quality-update-overview.md#service-level-objective).
While the Windows Autopatch default options will meet the majority of the needs for regular users with corporate devices, we understand there are devices that run critical activities and can only receive Windows Updates at specific times. The **Scheduled install** cadence type will minimize disruptions by preventing forced restarts and interruptions to critical business activities for end users. Upon selecting the **Scheduled install** cadence type, any previously set deadlines and grace periods will be removed. Devices will only update and restart according to the time specified.
While the Windows Autopatch default options meet most the needs for regular users with corporate devices, we understand there are devices that run critical activities and can only receive Windows Updates at specific times.
If other applications force a device to restart outside of the specified time and a Windows Update is pending a restart, the Windows Update will complete its installation at this time. For this reason, ensure that you consider your update and restart scenarios for devices running business critical activities, or restart sensitive workloads before using the Scheduled Install option.
The **Scheduled install** cadence type minimizes disruptions by preventing forced restarts and interruptions to critical business activities for end users. When you select the **Scheduled install** cadence type, any previously set deadlines and grace periods are removed. Devices will only update and restart according to the time specified.
If other applications force a device to restart outside of the specified time and a Windows Update is pending a restart, the Windows Update completes its installation at this time. For this reason, ensure that you consider your update and restart scenarios for devices running business critical activities, or restart sensitive workloads before using the Scheduled Install option.
> [!NOTE]
> The compliance deadline and grace period for Windows quality updates won't be configured for the Scheduled Install cadence type.
Devices **must** be active and available at the time when the device is scheduled for installation to ensure the optimal experience. If the device is consistently unavailable during the scheduled install time, the device can remain unprotected and unsecured, or the device may have the Windows Update scan and install during active hours.
Devices **must** be active and available at the time when the device is scheduled for installation to ensure the optimal experience. If the device is consistently unavailable during the scheduled install time, the device can remain unprotected and unsecured, or the device might have the Windows Update scan and install during active hours.
##### Scheduled install types
@ -76,7 +73,7 @@ The Scheduled install cadence has two options:
| Option | Description |
| ----- | ----- |
| Active hours | The period (daily) that the user normally does their work, or the device is busy performing business critical actions.<p>The time outside of active hours is when the device is available for Windows to perform an update and restart the device (daily). The max range for Active hours is 18 hours. The six-hour period outside of the active hours is the deployment period, when Windows Update for Business will scan, install and restart the device.</p>
| Active hours | The period (daily) that the user normally does their work, or the device is busy performing business critical actions.<p>The time outside of active hours is when the device is available for Windows to perform an update and restart the device (daily). The max range for Active hours is 18 hours. The six-hour period outside of the active hours is the deployment period, when Windows Update for Business scans, install and restart the device.</p>
| Schedule install and restart | Use this option to prevent the service from installing Windows Updates except during the specified start time. You can specify the following occurrence options:<ul><li>Weekly</li><li>Bi-weekly</li><li>Monthly</li></ul><p>Select a time when the device has low activity for the updates to complete. Ensure that the Windows Update has three to four hours to complete the installation and restart the device.</p> |
> [!NOTE]
@ -84,7 +81,7 @@ The Scheduled install cadence has two options:
### User notifications
In addition to the cadence type, you can also manage the end user notification settings. End users will receive all update notifications by default. For critical devices or devices where notifications need to be hidden, use the **Manage notifications** option to configure notifications. For each tenant, at the deployment ring level, there are four options for you to configure end user update notification settings:
In addition to the cadence type, you can also manage the end user notification settings. End users receive all update notifications by default. For critical devices or devices where notifications need to be hidden, use the **Manage notifications** option to configure notifications. For each tenant, at the deployment ring level, there are four options for you to configure end user update notification settings:
- Not configured
- Use the default Windows Update notifications
@ -101,12 +98,12 @@ For more information, see [Windows Update settings you can manage with Intune up
**To customize the Windows Update deployment cadence:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
2. Navigate to **Devices** > **Windows Autopatch** > **Release management** > **Release settings** select **Autopatch groups**. Select the **horizontal ellipses (…)** > **Edit** for the Autopatch group you want to edit.
2. Navigate to **Tenant administration** > **Windows Autopatch** > **Autopatch groups**. Select the **horizontal ellipses (…)** > **Edit** for the Autopatch group you want to edit.
3. Select the **horizontal ellipses (…)** across each ring to manage the deployment cadence or notification settings.
4. Select **Next** to navigate to the Windows update settings page. The page lists the existing settings for each of the deployment rings in the Autopatch group.
5. Select [**Manage deployment cadence**](#cadence-types) to customize Windows Update settings.
1. Select one of the cadence types for the ring:
1. Select **Deadline-driven** to configure the deferral, deadline, and grace periods. This option will enforce forced restarts based on the selected deadline and grace period. In the event you want to switch back to the service recommended defaults, for each of the settings, select the option tagged as "default".
1. Select **Deadline-driven** to configure the deferral, deadline, and grace periods. This option enforces forced restarts based on the selected deadline and grace period. In the event you want to switch back to the service recommended defaults, for each of the settings, select the option tagged as "default".
1. Select **Scheduled install** to opt-out of deadline-based forced restart.
1. Select either **Active hours** or **Schedule install and restart time**.
2. Select **Save**.
@ -118,5 +115,5 @@ For more information, see [Windows Update settings you can manage with Intune up
1. Turn off all notifications included restart warnings
1. Select **Save** once you select the preferred setting.
7. Repeat the same process to customize each of the rings. Once done, select **Next**.
8. In **Review + apply**, you'll be able to review the selected settings for each of the rings.
9. Select **Apply** to apply the changes to the ring policy. Once the settings are applied, the saved changes can be verified in the **Release schedule** tab. The Windows quality update schedule on the **Release schedule** tab will be updated as per the customized settings.
8. In **Review + apply**, you're able to review the selected settings for each of the rings.
9. Select **Apply** to apply the changes to the ring policy.

47
windows/deployment/update/deployment-service-drivers.md → windows/deployment/windows-autopatch/manage/windows-autopatch-driver-and-firmware-update-programmatic-controls.md
View File

@ -1,12 +1,12 @@
---
title: Deploy drivers and firmware updates
titleSuffix: Windows Update for Business deployment service
description: Use Windows Update for Business deployment service to deploy driver and firmware updates to devices.
title: Programmatic controls for drivers and firmware
titleSuffix: Windows Autopatch
description: Use programmatic controls to deploy driver and firmware updates to devices.
ms.service: windows-client
ms.subservice: itpro-updates
ms.topic: conceptual
author: mestew
ms.author: mstewart
ms.subservice: autopatch
ms.topic: how-to
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.collection:
- tier1
@ -14,13 +14,13 @@ ms.localizationpriority: medium
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
ms.date: 06/22/2023
ms.date: 09/16/2024
---
# Deploy drivers and firmware updates with Windows Update for Business deployment service
# Programmatic controls for drivers and firmware updates
<!--7260403, 7512398-->
The Windows Update for Business deployment service is used to approve and schedule software updates. The deployment service exposes its capabilities through the [Microsoft Graph API](/graph/use-the-api). You can call the API directly, through a [Graph SDK](/graph/sdks/sdks-overview), or integrate them with a management tool such as [Microsoft Intune](/mem/intune).
Windows Autopatch programmatic controls are used to approve and schedule software updates through the [Microsoft Graph API](/graph/use-the-api). You can call the API directly, through a [Graph SDK](/graph/sdks/sdks-overview), or integrate them with a management tool such as [Microsoft Intune](/mem/intune).
This article uses [Graph Explorer](/graph/graph-explorer/graph-explorer-overview) to walk through the entire process of deploying a driver update to clients. In this article, you will:
> [!div class="checklist"]
@ -37,36 +37,36 @@ This article uses [Graph Explorer](/graph/graph-explorer/graph-explorer-overview
## Prerequisites
All of the [prerequisites for the Windows Update for Business deployment service](deployment-service-prerequisites.md) must be met.
All of the [Windows Autopatch prerequisites](../prepare/windows-autopatch-fix-issues.md) must be met.
### Permissions
<!--Using include for Graph Explorer permissions-->
[!INCLUDE [Windows Update for Business deployment service permissions using Graph Explorer](./includes/wufb-deployment-graph-explorer-permissions.md)]
[!INCLUDE [Windows Autopath permissions using Graph Explorer](../includes/windows-autopatch-graph-explorer-permissions.md)]
## Open Graph Explorer
<!--Using include for Graph Explorer sign in-->
[!INCLUDE [Graph Explorer sign in](./includes/wufb-deployment-graph-explorer.md)]
[!INCLUDE [Graph Explorer sign in](../includes/windows-autopatch-graph-explorer.md)]
## Run queries to identify devices
<!--Using include for Graph Explorer device queries-->
[!INCLUDE [Graph Explorer device queries](./includes/wufb-deployment-find-device-name-graph-explorer.md)]
[!INCLUDE [Graph Explorer device queries](../includes/windows-autopatch-find-device-name-graph-explorer.md)]
## Enroll devices
When you enroll devices into driver management, the deployment service becomes the authority for driver updates coming from Windows Update. Devices don't receive drivers or firmware from Windows Update until a deployment is manually created or they're added to a driver update policy with approvals.
When you enroll devices into driver management, Windows Autopatch becomes the authority for driver updates coming from Windows Update. Devices don't receive drivers or firmware from Windows Update until a deployment is manually created or they're added to a driver update policy with approvals.
<!--Using include for enrolling devices using Graph Explorer-->
[!INCLUDE [Graph Explorer enroll devices](./includes/wufb-deployment-enroll-device-graph-explorer.md)]
[!INCLUDE [Graph Explorer enroll devices](../includes/windows-autopatch-enroll-device-graph-explorer.md)]
## Create a deployment audience and add audience members
<!--Using include for creating deployment audiences and adding audience members using Graph Explorer-->
[!INCLUDE [Graph Explorer enroll devices](./includes/wufb-deployment-audience-graph-explorer.md)]
[!INCLUDE [Graph Explorer enroll devices](../includes/windows-autopatch-audience-graph-explorer.md)]
Once a device has been enrolled and added to a deployment audience, the Windows Update for Business deployment service will start collecting scan results from Windows Update to build a catalog of applicable drivers to be browsed, approved, and scheduled for deployment.
Once a device has been enrolled and added to a deployment audience, Windows Autopatch will start collecting scan results from Windows Update to build a catalog of applicable drivers to be browsed, approved, and scheduled for deployment.
## Create an update policy
@ -75,7 +75,6 @@ Update policies define how content is deployed to a deployment audience. An [upd
> [!IMPORTANT]
> Any [deployment settings](/graph/api/resources/windowsupdates-deploymentsettings) configured for a [content approval](#approve-driver-content-for-deployment) will be combined with the existing update policy's deployment settings. If the content approval and update policy specify the same deployment setting, the setting from the content approval is used.
### Create a policy and define the settings later
To create a policy without any deployment settings, in the request body specify the **Audience ID** as `id`. In the following example, the **Audience ID** is `d39ad1ce-0123-4567-89ab-cdef01234567`, and the `id` given in the response is the **Policy ID**:
@ -115,6 +114,7 @@ content-type: application/json
### Specify settings during policy creation
To create a policy with additional settings, in the request body:
- Specify the **Audience ID** as `id`
- Define any [deployment settings](/graph/api/resources/windowsupdates-deploymentsettings).
- Add the `content-length` header to the request if a status code of 411 occurs. The value should be the length of the request body in bytes. For information on error codes, see [Microsoft Graph error responses and resource types](/graph/errors).
@ -147,7 +147,6 @@ To create a policy with additional settings, in the request body:
}
```
### Review and edit update policy settings
To review the policy settings, run the following query using the **Policy ID**, for example `9011c330-1234-5678-9abc-def012345678`:
@ -181,10 +180,9 @@ content-type: application/json
}
```
## Review applicable driver content
Once Windows Update for Business deployment service has scan results from devices, the applicability for driver and firmware updates can be displayed for a deployment audience. Each applicable update returns the following information:
Once Windows Autopatch has scan results from devices, the applicability for driver and firmware updates can be displayed for a deployment audience. Each applicable update returns the following information:
- An `id` for its [catalog entry](/graph/api/resources/windowsupdates-catalogentry)
- The **Microsoft Entra ID** of the devices it's applicable to
@ -197,6 +195,7 @@ GET https://graph.microsoft.com/beta/admin/windows/updates/deploymentAudiences/d
```
The following truncated response displays:
- An **Microsoft Entra ID** of `01234567-89ab-cdef-0123-456789abcdef`
- The **Catalog ID** of `5d6dede684ba5c4a731d62d9c9c2a99db12c5e6015e9f8ad00f3e9387c7f399c`
@ -332,9 +331,9 @@ GET https://graph.microsoft.com/beta/admin/windows/updates/deployments?orderby=c
## Unenroll devices
<!--Using include for removing device enrollment-->
[!INCLUDE [Graph Explorer enroll devices](./includes/wufb-deployment-graph-unenroll.md)]
[!INCLUDE [Graph Explorer unenroll devices](../includes/windows-autopatch-graph-unenroll.md)]
## Policy considerations for drivers
<!--Using include for Policy considerations for drivers-->
[!INCLUDE [Windows Update for Business deployment service driver policy considerations](./includes/wufb-deployment-driver-policy-considerations.md)]
[!INCLUDE [Windows Autopatch driver policy considerations](../includes/windows-autopatch-driver-policy-considerations.md)]

50
windows/deployment/windows-autopatch/manage/windows-autopatch-edge.md
View File

@ -1,7 +1,7 @@
---
title: Microsoft Edge
description: This article explains how Microsoft Edge updates are managed in Windows Autopatch
ms.date: 09/15/2023
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
@ -17,8 +17,13 @@ ms.collection:
# Microsoft Edge
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
Windows Autopatch uses the [Stable Channel](/deployedge/microsoft-edge-channels#stable-channel) of Microsoft Edge.
> [!IMPORTANT]
> To update Microsoft 365 Apps for enterprise, you must [create at least one Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) first and **Microsoft Edge update setting** must be set to [**Allow**](#allow-or-block-microsoft-edge-updates). For more information on workloads supported by Windows Autopatch groups, see [Software update workloads](../deploy/windows-autopatch-groups-overview.md#software-update-workloads).
## Device eligibility
For a device to be eligible for Microsoft Edge updates as a part of Windows Autopatch, they must meet the following criteria:
@ -28,15 +33,54 @@ For a device to be eligible for Microsoft Edge updates as a part of Windows Auto
- The device must be able to access the required network endpoints to reach the Microsoft Edge update service.
- If Microsoft Edge is open, it must restart for the update process to complete.
## Allow or block Microsoft Edge updates
> [!IMPORTANT]
> You must be an Intune Administrator to make changes to the setting.
For organizations seeking greater control, you can allow or block Microsoft Edge updates for Windows Autopatch-enrolled devices.
| Microsoft Edge setting | Description |
| ----- | ----- |
| **Allow** | When set to **Allow**, Windows Autopatch assigns devices to Microsoft Edge's [Stable Channel](/deployedge/microsoft-edge-channels#stable-channel). To manage updates manually, set the Microsoft Edge setting to **Block**. |
| **Block** | When set to **Block**, Windows Autopatch doesn't assign devices to Microsoft Edge's [Stable Channel](/deployedge/microsoft-edge-channels#stable-channel) updates on your behalf, and your organizations have full control over these updates. You can continue to receive updates from [channels](/deployoffice/overview-update-channels) other than the default [Monthly Enterprise Channel](/deployoffice/overview-update-channels#monthly-enterprise-channel-overview). |
**To allow or block Edge updates:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Navigate to **Tenant administration** > **Windows Autopatch** > **Autopatch groups** > **Update settings**.
1. Go to the **Edge updates** section. By default, the Allow/Block toggle is set to **Block**.
1. Turn off the **Allow** toggle (set to Block) to opt out of Microsoft Edge update policies. You see the notification: *Update in process. This setting will be unavailable until the update is complete.*
1. Once the update is complete, you receive the notification: *This setting is updated*.
> [!NOTE]
> If the notification: *This setting couldn't be updated. Please try again or submit a support request.* appears, use the following steps:<ol><li>Refresh your page.</li><li>Please repeat the same steps in To allow or block Edge updates.</li><li>If the issue persists, [submit a support request](../manage/windows-autopatch-support-request.md).</li>
**To verify if the Edge update setting is set to Allow:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
2. Navigate to **Devices** > **Configuration profiles** > **Profiles**.
3. The following profiles should be discoverable from the list of profiles:
1. Windows Autopatch - Microsoft Edge Update Channel Stable
2. Windows Autopatch - Microsoft Edge Update Channel Beta
**To verify if the Edge update setting is set to Block:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
2. Navigate to **Devices** > **Configuration profiles** > **Profiles**.
3. The following **five** profiles should be removed from your list of profiles and no longer visible/active. Use the Search with the keywords "Microsoft Edge Configuration". The result should return *0 profiles filtered*.
1. Windows Autopatch - Microsoft Edge Update Channel Stable
2. Windows Autopatch - Microsoft Edge Update Channel Beta
## Update release schedule
Microsoft Edge checks for updates every 10 hours. Quality updates occur weekly by default. Feature updates occur automatically every four weeks and are rolled out [progressively](/deployedge/microsoft-edge-update-progressive-rollout) by the Microsoft Edge product group to ensure the best experience for customers. The update is available within a few days of the initial release.
Microsoft Edge checks for updates every 10 hours. Quality updates occur weekly by default. The Microsoft Edge product group [progressively](/deployedge/microsoft-edge-update-progressive-rollout) rolls out feature updates automatically every four weeks to ensure the best experience for customers. The update is available within a few days of the initial release.
Browser updates with critical security fixes have a faster rollout cadence than updates that don't have critical security fixes to ensure fast protection from vulnerabilities.
Devices in the Test device group receive feature updates from the [Beta Channel](/deployedge/microsoft-edge-channels#beta-channel). This channel is fully supported and automatically updated with new features approximately every four weeks.
## Pausing and resuming updates
## Pause and resume updates
Currently, Windows Autopatch can't pause or resume Microsoft Edge updates.

16
windows/deployment/windows-autopatch/manage/windows-autopatch-exclude-device.md
View File

@ -1,7 +1,7 @@
---
title: Exclude a device
description: This article explains how to exclude a device from the Windows Autopatch service
ms.date: 07/08/2024
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
@ -16,9 +16,11 @@ ms.collection:
# Exclude a device
To avoid end-user disruption, excluding a device in Windows Autopatch only deletes the Windows Autopatch device record itself. Excluding a device can't delete the Microsoft Intune and/or the Microsoft Entra device records. Microsoft assumes you'll keep managing those devices yourself in some capacity.
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
When you exclude a device from the Windows Autopatch service, the device is flagged as **excluded** so Windows Autopatch doesn't try to restore the device into the service again, since the exclusion command doesn't trigger device membership removal from the **Windows Autopatch Device Registration** group, or any other Microsoft Entra group, used with Autopatch groups.
To avoid end-user disruption, excluding a device in Windows Autopatch only deletes the Windows Autopatch device record itself. Excluding a device can't delete the Microsoft Intune and/or the Microsoft Entra device records. Microsoft assumes you manage those devices yourself in some capacity.
When you exclude a device from the Windows Autopatch service, the device is flagged as **Excluded** so Windows Autopatch doesn't try to restore the device into the service again. The exclusion command doesn't trigger device membership removal from any other Microsoft Entra group, used with Autopatch groups.
> [!IMPORTANT]
> The Microsoft Entra team doesn't recommend appending query statements to remove specific device from a dynamic query due to dynamic query performance issues.
@ -28,7 +30,7 @@ When you exclude a device from the Windows Autopatch service, the device is flag
1. Sign into the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Windows Autopatch** in the left navigation menu.
1. Select **Devices**.
1. In either the **Ready** or **Not ready** tab, select the device(s) you want to exclude.
1. Select the devices you want to exclude.
1. Once a device or multiple devices are selected, select **Device actions**. Then, select **Exclude device**.
> [!WARNING]
@ -36,14 +38,14 @@ When you exclude a device from the Windows Autopatch service, the device is flag
## Only view excluded devices
You can view the excluded devices in the **Not registered** tab to make it easier for you to bulk restore devices that were previously excluded from the Windows Autopatch service.
You can view the excluded devices in the [**Devices report**](../deploy/windows-autopatch-register-devices.md#devices-report) to make it easier for you to bulk restore devices that were previously excluded from the Windows Autopatch service.
**To view only excluded devices:**
1. Sign into the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Windows Autopatch** in the left navigation menu.
1. Select **Devices**.
1. In the **Not registered** tab, select **Excluded** from the filter list. Leave all other filter options unselected.
1. Select **Excluded** from the filter list. Leave all other filter options unselected.
## Restore a device or multiple devices previously excluded
@ -52,5 +54,5 @@ You can view the excluded devices in the **Not registered** tab to make it easie
1. Sign into the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Windows Autopatch** in the left navigation menu.
1. Select **Devices**.
1. In the **Not registered** tab, select the device(s) you want to restore.
1. Select the devices you want to restore.
1. Once a device or multiple devices are selected, select **Device actions**. Then, select **Restore excluded device**.

51
windows/deployment/windows-autopatch/manage/windows-autopatch-feature-deactivation.md
View File

@ -1,7 +1,7 @@
---
title: Unenroll your tenant
description: This article explains what unenrollment means for your organization and what actions you must take.
ms.date: 07/08/2024
title: Deactivate Windows Autopatch
description: This article explains what deactivation means for your organization and what actions you must take.
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
@ -15,45 +15,48 @@ ms.collection:
- tier1
---
# Unenroll your tenant
# Deactivate Windows Autopatch
If you're looking to unenroll your tenant from Windows Autopatch, this article details what unenrollment means for your organization and what actions you must take.
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
If you're looking to deactivate Windows Autopatch features, this article details what deactivation means for your organization and what actions you must take.
> [!IMPORTANT]
> You must be a Global Administrator to unenroll your tenant.
> You must be a Global Administrator to deactivate Windows Autopatch features.
Unenrolling from Windows Autopatch requires manual actions from both you and from the Windows Autopatch Service Engineering Team. The Windows Autopatch Service Engineering Team will:
Deactivating from Windows Autopatch requires manual actions from both you and from the Windows Autopatch Service Engineering Team. The Windows Autopatch Service Engineering Team:
- Remove Windows Autopatch access to your tenant.
- Exclude your devices from the Windows Autopatch service. Excluding your devices from Windows Autopatch won't remove your devices from Intune, Microsoft Entra ID or Configuration Manager. The Windows Autopatch Service Engineering Team follows the same process and principles as laid out in [Exclude a device](../operate/windows-autopatch-exclude-device.md).
- Delete all data that we've stored in the Windows Autopatch data storage.
- Removes Windows Autopatch access to your tenant.
- We remove the [Modern Workplace Management application](../references/windows-autopatch-changes-made-at-feature-activation.md#windows-autopatch-enterprise-applications) from your tenant that is used to run the Windows Autopatch service on your tenant
- Excludes your devices from the Windows Autopatch service. Excluding your devices from Windows Autopatch doesn't remove your devices from Intune, Microsoft Entra ID or Configuration Manager. The Windows Autopatch Service Engineering Team follows the same process and principles as laid out in [Exclude a device](../manage/windows-autopatch-exclude-device.md).
- Deletes all data that we stored in the Windows Autopatch data storage.
> [!NOTE]
> We will **not** delete any of your customer or Intune data.
## Microsoft's responsibilities during unenrollment
## Microsoft's responsibilities during deactivation
| Responsibility | Description |
| ----- | ----- |
| Windows Autopatch data | Windows Autopatch will delete user data that is within the Windows Autopatch service. We won't make changes to any other data. For more information about how data is used in Windows Autopatch, see [Privacy](../overview/windows-autopatch-privacy.md). |
| Excluding devices | Windows Autopatch will exclude all devices previously registered with the service. Only the Windows Autopatch device record is deleted. We won't delete Microsoft Intune and/or Microsoft Entra device records. For more information, see [Exclude a device](../operate/windows-autopatch-exclude-device.md). |
| Windows Autopatch data | Windows Autopatch deletes user data that is within the Windows Autopatch service. We don't make changes to any other data. For more information about how data is used in Windows Autopatch, see [Privacy](../overview/windows-autopatch-privacy.md). |
| Excluding devices | Windows Autopatch excludes all devices previously registered with the service. Only the Windows Autopatch device record is deleted. We don't delete Microsoft Intune and/or Microsoft Entra device records. For more information, see [Exclude a device](../manage/windows-autopatch-exclude-device.md). |
## Your responsibilities after unenrolling your tenant
## Your responsibilities after deactivating Windows Autopatch features
| Responsibility | Description |
| ----- | ----- |
| 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). |
| Microsoft Intune roles | After unenrollment, you may safely remove the Modern Workplace Intune Admin role. |
| Updates | After the Windows Autopatch service is deactivated, 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 doesn't remove the configuration policies or groups used to enable updates on your devices. You're responsible for these policies following tenant deactivation. If you don't wish to use these policies for your devices after deactivation, you can safely delete them. For more information, see [Changes made at feature activation](../references/windows-autopatch-changes-made-at-feature-activation.md). |
| Microsoft Intune roles | After deactivation, you can safely remove the Modern Workplace Intune Admin role. |
## Unenroll from Windows Autopatch
## To Deactivate Windows Autopatch features
**To unenroll from Windows Autopatch:**
**To deactivate Windows Autopatch features:**
1. [Submit a support request](../operate/windows-autopatch-support-request.md) and request to unenroll from the Windows Autopatch service.
1. The Windows Autopatch Service Engineering Team communicates with your IT Administrator to confirm your intent to unenroll from the service.
1. [Submit a support request](../manage/windows-autopatch-support-request.md) and request to deactivate Windows Autopatch features.
1. The Windows Autopatch Service Engineering Team communicates with your IT Administrator to confirm your intent to deactivate Windows Autopatch features.
1. You have 14 days to review and confirm the communication sent by the Windows Autopatch Service Engineering Team.
2. The Windows Autopatch Service Engineering Team can proceed sooner than 14 days if your confirmation arrives sooner.
1. The Windows Autopatch Service Engineering Team proceeds with the removal of all items listed under [Microsoft's responsibilities during unenrollment](#microsofts-responsibilities-during-unenrollment).
1. The Windows Autopatch Service Engineering Team informs you when unenrollment is complete.
1. You're responsible for the items listed under [Your responsibilities after unenrolling your tenant](#your-responsibilities-after-unenrolling-your-tenant).
1. The Windows Autopatch Service Engineering Team proceeds with the removal of all items listed under [Microsoft's responsibilities during deactivation](#microsofts-responsibilities-during-deactivation).
1. The Windows Autopatch Service Engineering Team informs you when deactivation is complete.
1. You're responsible for the items listed under [Your responsibilities after deactivating Windows Autopatch features](#your-responsibilities-after-deactivating-windows-autopatch-features).

48
windows/deployment/windows-autopatch/manage/windows-autopatch-groups-policies.md Normal file
View File

@ -0,0 +1,48 @@
---
title: Autopatch group policies
description: This article describes Autopatch group policies
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
ms.localizationpriority: medium
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.reviewer: andredm7
ms.collection:
- highpri
- tier1
---
# Autopatch group policies
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
The following Autopatch group policies are only created when you create an Autopatch group.
## Update rings policy for Windows 10 and later
Update rings policy for Windows 10 and later
Autopatch groups set up the [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) for each of its deployment rings in the Default Autopatch group. See the following default policy values:
| Policy name | Quality updates deferral in days | Feature updates deferral in days | Feature updates uninstall window in days | Deadline for quality updates in days | Deadline for feature updates in days | Grace period | Auto restart before deadline |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Test | 0 | 0 | 30 | 0 | 5 | 0 | Yes |
| Ring 1 | 1 | 0 | 30 | 2 | 5 |2 | Yes |
| Ring 2 | 6 | 0 | 30 | 2 | 5 | 2 | Yes |
| Ring 3 | 9 | 0 | 30 | 5 | 5 | 2 | Yes |
| Last | 11 | 0 | 30 | 3 | 5 | 2 | Yes |
## Feature update policy for Windows 10 and later
Autopatch groups set up the [feature updates for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates) for each of its deployment rings in the Default Autopatch group, see the following default policy values:
| Policy name |Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Autopatch group name - DSS Policy [Test]| Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024 |
| Autopatch group name - DSS Policy [Ring1] | Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024 |
| Autopatch group name - DSS Policy [Ring2] | Windows 10 21H2 | Make update available as soon as possible | December 14, 2022 | December 21, 2022 | 1 | June 11, 2024 |
| Autopatch group name - DSS Policy [Ring3] | Windows 10 21H2 | Make update available as soon as possible | December 15, 2022 | December 29, 2022 | 1 | June 11, 2024 |
| Autopatch group name - DSS Policy [Last] | Windows 10 21H2 | Make update available as soon as possible | December 15, 2022 | December 29, 2022 | 1 | June 11, 2024 |

137
windows/deployment/windows-autopatch/manage/windows-autopatch-manage-autopatch-groups.md
View File

@ -1,7 +1,7 @@
---
title: Manage Windows Autopatch groups
description: This article explains how to manage Autopatch groups
ms.date: 07/08/2024
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
@ -17,62 +17,31 @@ ms.collection:
# Manage Windows Autopatch groups
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
Autopatch groups help Microsoft Cloud-Managed services meet organizations where they are in their update management journey.
Autopatch groups is a logical container or unit that groups several [Microsoft Entra groups](/azure/active-directory/fundamentals/active-directory-groups-view-azure-portal), and software update policies, such as [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) and [feature updates policy for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates).
An Autopatch group is a logical container or unit that groups several [Microsoft Entra groups](/azure/active-directory/fundamentals/active-directory-groups-view-azure-portal), and software update policies, such as [Update rings policy for Windows 10 and later](/mem/intune/protect/windows-10-update-rings) and [feature updates policy for Windows 10 and later policies](/mem/intune/protect/windows-10-feature-updates).
## Autopatch groups prerequisites
Before you start managing Autopatch groups, ensure you meet the [Windows Autopatch groups prerequisites](../deploy/windows-autopatch-groups-overview.md#prerequisites).
Before you start managing Autopatch groups, ensure you've met the following prerequisites:
## Create an Autopatch group
- Review [Windows Autopatch groups overview documentation](../deploy/windows-autopatch-groups-overview.md) to understand [key benefits](../deploy/windows-autopatch-groups-overview.md#key-benefits), [concepts](../deploy/windows-autopatch-groups-overview.md#key-concepts) and [common ways to use Autopatch groups](../deploy/windows-autopatch-groups-overview.md#common-ways-to-use-autopatch-groups) within your organization.
- Ensure the following [update rings for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-update-rings) are created in your tenant:
- Modern Workplace Update Policy [Test]-[Windows Autopatch]
- Modern Workplace Update Policy [First]-[Windows Autopatch]
- Modern Workplace Update Policy [Fast]-[Windows Autopatch]
- Modern Workplace Update Policy [Broad]-[Windows Autopatch]
- Ensure the following [feature updates for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-feature-updates) are created in your tenant:
- Windows Autopatch - DSS Policy [Test]
- Windows Autopatch - DSS Policy [First]
- Windows Autopatch - DSS Policy [Fast]
- Windows Autopatch - DSS Policy [Broad]
- Ensure the following Microsoft Entra ID assigned groups are in your tenant before using Autopatch groups. **Don't** modify the Microsoft Entra group membership types (Assigned or Dynamic). Otherwise, the Windows Autopatch service won't be able to read the device group membership from these groups and causes the Autopatch groups feature and other service-related operations to not work properly.
- Modern Workplace Devices-Windows Autopatch-Test
- Modern Workplace Devices-Windows Autopatch-First
- Modern Workplace Devices-Windows Autopatch-Fast
- Modern Workplace Devices-Windows Autopatch-Broad
- Windows Autopatch - Test
- Windows Autopatch - Ring1
- Windows Autopatch - Ring2
- Windows Autopatch - Ring3
- Windows Autopatch - Last
- Additionally, **don't** modify the Microsoft Entra group ownership of any of the groups above otherwise, Autopatch groups device registration process won't be able to add devices into these groups. If the ownership is modified, you must add the **Modern Workplace Management** enterprise application as the owner of these groups.
- For more information, see [assign an owner or member of a group in Microsoft Entra ID](/azure/active-directory/privileged-identity-management/groups-assign-member-owner#assign-an-owner-or-member-of-a-group) for steps on how to add owners to Azure Microsoft Entra groups.
- Make sure you have [app-only auth turned on in your Windows Autopatch tenant](../operate/windows-autopatch-maintain-environment.md#windows-autopatch-tenant-actions). Otherwise, the Autopatch groups functionality won't work properly. Autopatch uses app-only auth to:
- Read device attributes to successfully register devices.
- Manage all configurations related to the operation of the service.
- Make sure that all device-based Microsoft Entra groups you intend to use with Autopatch groups are created prior to using the feature.
- Review your existing Microsoft Entra group dynamic queries and direct device memberships to avoid having device membership overlaps in between device-based Microsoft Entra groups that are going to be used with Autopatch groups. This can help prevent device conflicts within an Autopatch group or across several Autopatch groups. **Autopatch groups doesn't support user-based Microsoft Entra groups**.
- Ensure devices used with your existing Microsoft Entra groups meet [device registration prerequisite checks](../deploy/windows-autopatch-register-devices.md#prerequisites-for-device-registration) when being registered with the service. Autopatch groups register devices on your behalf, and devices can be moved to **Registered** or **Not registered** tabs in the Devices blade accordingly.
> [!IMPORTANT]
> Windows Autopatch creates the device-based Microsoft Entra ID assigned groups based on the choices made in the deployment ring composition page. Additionally, the service assigns the update ring policies for each deployment ring created in the Autopatch group based on the choices made in the Windows Update settings page as part of the Autopatch group guided end-user experience.
> [!TIP]
> [Update rings](/mem/intune/protect/windows-10-update-rings) and [feature updates](/mem/intune/protect/windows-10-feature-updates) for Windows 10 and later policies that are created and managed by Windows Autopatch can be restored using the [Policy health](../operate/windows-autopatch-policy-health-and-remediation.md) feature. For more information on remediation actions, see [restore Windows update policies](../operate/windows-autopatch-policy-health-and-remediation.md#restore-windows-update-policies).
> For more information on workloads supported by Windows Autopatch groups, see [Supported software workloads](../deploy/windows-autopatch-groups-overview.md#software-update-workloads).<ul><li>To manage Microsoft 365 Apps for enterprise, you must create an Autopatch group first and [set the Microsoft 365 app update setting to Allow](../manage/windows-autopatch-microsoft-365-apps-enterprise.md#allow-or-block-microsoft-365-app-updates).</li><li>To manage Microsoft Edge updates, you must create an Autopatch group first and [set the Edge update setting to Allow](../manage/windows-autopatch-edge.md#allow-or-block-microsoft-edge-updates).</li></ul>
## Create a Custom Autopatch group
> [!NOTE]
> The Default Autopatch group is recommended for organizations that can meet their business needs using the pre-configured five deployment ring composition.
**To create a Custom Autopatch group:**
**To create an Autopatch group:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** from the left navigation menu.
1. Under the **Windows Autopatch** section, select **Release management**.
1. In the **Release management** blade, select **Autopatch groups**.
1. Select **Tenant administration** from the left navigation menu.
1. Under the **Windows Autopatch** section, select **Autopatch groups**.
1. In the **Autopatch groups** blade, select **Create**.
1. In **Basics** page, enter a **name** and a **description** then select **Next: Deployment rings**.
1. Enter up to 64 characters for the Autopatch group name and 150 characters maximum for the description. The Autopatch group name is appended to both the update rings and the DSS policy names that get created once the Custom Autopatch group is created.
1. In **Deployment rings** page, select **Add deployment ring** to add the number of deployment rings to the Custom Autopatch group.
1. In the **Basics** page, enter a **name** and a **description** then select **Next: Deployment rings**.
1. Enter up to 64 characters for the Autopatch group name and 150 characters maximum for the description. The Autopatch group name is appended to both the update rings and the DSS policy names that get created once the Autopatch group is created.
1. In the **Deployment rings** page, select **Add deployment ring** to add the number of deployment rings to the Autopatch group.
1. Each new deployment ring added must have either a Microsoft Entra device group assigned to it, or a Microsoft Entra group that is dynamically distributed across your deployments rings using defined percentages.
1. In the **Dynamic groups** area, select **Add groups** to select one or more existing device-based Microsoft Entra groups to be used for Dynamic group distribution.
1. In the **Dynamic group distribution** column, select the desired deployment ring checkbox. Then, either:
@ -80,27 +49,27 @@ Before you start managing Autopatch groups, ensure you've met the following prer
1. Select **Apply default dynamic group distribution** to use the default values.
1. In the **Assigned group** column, select **Add group to ring** to add an existing Microsoft Entra group to any of the defined deployment rings. The **Test** and **Last** deployment rings only support Assigned group distribution. These deployment rings don't support Dynamic distribution.
1. Select **Next: Windows Update settings**.
1. Select the **horizontal ellipses (…)** > **Manage deployment cadence** to [customize your gradual rollout of Windows quality and feature updates](../operate/windows-autopatch-windows-update.md). Select **Save**.
1. Select the **horizontal ellipses (…)** > **Manage deployment cadence** to [customize your gradual rollout of Windows quality and feature updates](../manage/windows-autopatch-customize-windows-update-settings.md). Select **Save**.
1. Select the **horizontal ellipses (…)** > **Manage notifications** to customize the end-user experience when receiving Windows updates. Select **Save**.
1. Select **Review + create** to review all changes made.
1. Once the review is done, select **Create** to save your custom Autopatch group.
1. Once the review is done, select **Create** to save your Autopatch group.
> [!CAUTION]
> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that's been already used, you'll receive an error that prevents you from finish creating or editing the Autopatch group (Default or Custom).
> **Don't** modify the Microsoft Entra group membership types (Assigned and Dynamic). Otherwise, the Windows Autopatch service won't be able to read the device group membership from these groups, and causes the Autopatch groups feature and other service-related operations to not work properly.<p>Additionally, it's not supported to have Configuration Manager collections directly synced to any Microsoft Entra group created by Autopatch groups.</p>
> [!IMPORTANT]
> Windows Autopatch creates the device-based Microsoft Entra ID assigned groups based on the choices made in the deployment ring composition page. Additionally, the service assigns the update ring policies for each deployment ring created in the Autopatch group based on the choices made in the Windows Update settings page as part of the Autopatch group guided end-user experience.
> [!CAUTION]
> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that's been already used, you'll receive an error that prevents you from creating or editing the Autopatch group.
## Edit the Default or a Custom Autopatch group
## Edit an Autopatch group
> [!TIP]
> You can't edit an Autopatch group when there's one or more Windows feature update releases targeted to it. If you try to edit an Autopatch group with one or more ongoing Windows feature update releases targeted to it, you get the following informational banner message: "**Some settings are not allowed to be modified as there's one or more on-going Windows feature update release targeted to this Autopatch group.**"
> See [Manage Windows feature update releases](../operate/windows-autopatch-groups-manage-windows-feature-update-release.md) for more information on release and phase statuses.
> For more information on release and phase statuses, see [Windows feature update](../manage/windows-autopatch-windows-feature-update-overview.md).
**To edit either the Default or a Custom Autopatch group:**
**To edit an Autopatch group:**
1. Select the **horizontal ellipses (…)** > **Edit** for the Autopatch group you want to edit.
1. You can only modify the **description** of the Default or a Custom Autopatch group. You **can't** modify the name. Once the description is modified, select **Next: Deployment rings**.
1. You can only modify the **description** of an Autopatch group. You **can't** modify the name. Once the description is modified, select **Next: Deployment rings**. To rename an Autopatch group, see [Rename an Autopatch group](#rename-an-autopatch-group).
1. Make the necessary changes in the **Deployment rings** page, then select **Next: Windows Update settings**.
1. Make the necessary changes in the **Windows Update settings** page, then select **Next: Review + save**.
1. Select **Review + create** to review all changes made.
@ -109,46 +78,42 @@ Before you start managing Autopatch groups, ensure you've met the following prer
> [!IMPORTANT]
> Windows Autopatch creates the device-based Microsoft Entra ID assigned groups based on the choices made in the deployment ring composition page. Additionally, the service assigns the update ring policies for each deployment ring created in the Autopatch group based on the choices made in the Windows Update settings page as part of the Autopatch group guided end-user experience.
## Rename a Custom Autopatch group
## Rename an Autopatch group
You **can't** rename the Default Autopatch group. However, you can rename a Custom Autopatch group.
**To rename an Autopatch group:**
**To rename a Custom Autopatch group:**
1. Select the **horizontal ellipses (…)** > **Rename** for the Custom Autopatch group you want to rename. The **Rename Autopatch group** fly-in opens.
1. In the **New Autopatch group name**, enter the new Autopatch group name of your choice, then click **Rename group**.
1. Select the **horizontal ellipses (…)** > **Rename** for the Autopatch group you want to rename. The **Rename Autopatch group** fly-in opens.
1. In the **New Autopatch group name**, enter the new Autopatch group name of your choice, then select **Rename group**.
> [!IMPORTANT]
> Autopatch supports up to 64 characters for the custom Autopatch group name. Additionally, when you rename a custom Autopatch group all [update rings for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-update-rings) and [feature updates for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-feature-updates) associated with the custom Autopatch group are renamed to include the new Autopatch group name you define in its name string. Also, when renaming a custom Autopatch group all Microsoft Entra groups representing the custom Autopatch group's deployment rings are renamed to include the new Autopatch group name you define in its name string.
> Autopatch supports up to 64 characters for the Autopatch group name. Additionally, when you rename a Autopatch group all [update rings for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-update-rings) and [feature updates for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-feature-updates) associated with the Autopatch group are renamed to include the new Autopatch group name you define in its name string. Also, when renaming an Autopatch group all Microsoft Entra groups representing the Autopatch group's deployment rings are renamed to include the new Autopatch group name you define in its name string.
## Delete a Custom Autopatch group
## Delete an Autopatch group
You **can't** delete the Default Autopatch group. However, you can delete a Custom Autopatch group.
**To delete an Autopatch group:**
**To delete a Custom Autopatch group:**
1. Select the **horizontal ellipses (…)** > **Delete** for the Custom Autopatch group you want to delete.
1. Select **Yes** to confirm you want to delete the Custom Autopatch group.
1. Select the **horizontal ellipses (…)** > **Delete** for the Autopatch group you want to delete.
1. Select **Yes** to confirm you want to delete the Autopatch group.
> [!CAUTION]
> You can't delete a Custom Autopatch group when it's being used as part of one or more active or paused feature update releases. However, you can delete a Custom Autopatch group when the release for either Windows quality or feature updates have either the **Scheduled** or **Paused** statuses.
> You can't delete an Autopatch group when it's being used as part of one or more active or paused feature update releases. However, you can delete an Autopatch group when the release for either Windows quality or feature updates have either the **Scheduled** or **Paused** statuses.
## Manage device conflict scenarios when using Autopatch groups
Overlap in device membership is a common scenario when working with device-based Microsoft Entra groups since sometimes dynamic queries can be large in scope or the same assigned device membership can be used across different Microsoft Entra groups.
Overlap in device membership is a common scenario when working with device-based Microsoft Entra groups. Sometimes dynamic queries can be large in scope or the same assigned device membership can be used across different Microsoft Entra groups.
Since Autopatch groups allow you to use your existing Microsoft Entra groups to create your own deployment ring composition, the service takes on the responsibility of monitoring and automatically solving some of the device conflict scenarios that may occur.
Since Autopatch groups allow you to use your existing Microsoft Entra groups to create your own deployment ring composition, the service takes on the responsibility of monitoring and automatically solving some of the device conflict scenarios that might occur.
> [!CAUTION]
> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that's been already used, you'll receive an error that prevents you from creating or editing the Autopatch group (Default or Custom).
> A device-based Microsoft Entra group can only be used with one deployment ring in an Autopatch group at a time. This applies to deployment rings within the same Autopatch group and across different deployment rings across different Autopatch groups. If you try to create or edit an Autopatch group to use a device-based Microsoft Entra group that's been already used, you'll receive an error that prevents you from creating or editing the Autopatch group.
### Device conflict in deployment rings within an Autopatch group
Autopatch groups uses the following logic to solve device conflicts on your behalf within an Autopatch group:
Autopatch groups use the following logic to solve device conflicts on your behalf within an Autopatch group:
| Step | Description |
| ----- | ----- |
| Step 1: Checks for the deployment ring distribution type (**Assigned** or **Dynamic**) that the device belongs to. | For example, if a device is part of one deployment ring with **Dynamic** distribution (Ring3), and one deployment ring with **Assigned** distribution (Test,) within the same Autopatch group, the deployment ring with **Assigned** distribution (Test) takes precedence over the one with the **Dynamic** distribution type (Ring3). |
| Step 1: Checks for the deployment ring distribution type (**Assigned** or **Dynamic**) that the device belongs to. | For example, if a device is part of one deployment ring with **Dynamic** distribution (Ring3), and one deployment ring with **Assigned** distribution (Test) within the same Autopatch group, the deployment ring with **Assigned** distribution (Test) takes precedence over the one with the **Dynamic** distribution type (Ring3). |
| Step 2: Checks for deployment ring ordering when device belongs to one or more deployment ring with the same distribution type (**Assigned** or **Dynamic**) | For example, if a device is part of one deployment ring with **Assigned** distribution (Test), and in another deployment ring with **Assigned** distribution (Ring3) within the **same** Autopatch group, the deployment ring that comes later (Ring3) takes precedence over the deployment ring that comes earlier (Test) in the deployment ring order. |
> [!IMPORTANT]
@ -156,28 +121,18 @@ Autopatch groups uses the following logic to solve device conflicts on your beha
### Device conflict across different Autopatch groups
Device conflict across different deployment rings in different Autopatch groups may occur, review the following examples about how the Windows Autopatch services handles the following scenarios:
Device conflict across different deployment rings in different Autopatch groups might occur, review the following examples about how the Windows Autopatch services handles the following scenarios:
#### Default to Custom Autopatch group device conflict
#### Same device in different deployment rings across different Autopatch groups
| Conflict scenario | Conflict resolution |
| ----- | ----- |
| You, the IT admin at Contoso Ltd., starts using only the Default Autopatch group, but later decides to create an Autopatch group called "Marketing".<p>However, you notice that the same devices that belong to the deployment rings in the Default Autopatch group are now also part of the new deployment rings in the Marketing Autopatch group.</p> | Autopatch groups automatically resolve this conflict on your behalf.<p>In this example, devices that belong to the deployment rings as part of the "Marketing" Autopatch group take precedence over devices that belong to the deployment ring in the Default Autopatch group, because you, the IT admin, demonstrated clear intent on managing deployment rings using a Custom Autopatch group outside the Default Autopatch group.</p> |
| You, the IT admin at Contoso Ltd., are using several Autopatch groups. While navigating through devices in the Windows Autopatch Devices blade, you notice that the same device is part of different deployment rings across several different Autopatch groups. This device appears as **Not ready**. | You must resolve this conflict.<p>Autopatch groups inform you about the device conflict in the [**Devices report**](../deploy/windows-autopatch-register-devices.md#devices-report). Select the **Not ready** status for the device you want to address. You're required to manually indicate which of the existing Autopatch groups the device should exclusively belong to.</p> |
#### Custom to Custom Autopatch group device conflict
#### Device conflict before device registration
When you create or edit an Autopatch group, Windows Autopatch checks if the devices that are part of the Microsoft Entra groups, used in Autopatch groups’ deployment rings, are registered with the service.
| Conflict scenario | Conflict resolution |
| ----- | ----- |
| You, the IT admin at Contoso Ltd., are using several Custom Autopatch groups. While navigating through devices in the Windows Autopatch Devices blade (**Not ready** tab), you notice that the same device is part of different deployment rings across several different Custom Autopatch groups. | You must resolve this conflict.<p>Autopatch groups informs you about the device conflict in the **Devices** > **Not ready** tab. You're required to manually indicate which of the existing Custom Autopatch groups the device should exclusively belong to.</p> |
#### Device conflict prior to device registration
When you create or edit the Custom or Default Autopatch group, Windows Autopatch checks if the devices that are part of the Microsoft Entra groups, used in Autopatch groups' deployment rings, are registered with the service.
| Conflict scenario | Conflict resolution |
| ----- | ----- |
| Devices are in the Custom-to-Custom Autopatch group device conflict scenario | You must resolve this conflict.<p>Devices will fail to register with the service and will be sent to the **Not registered** tab. You're required to make sure the Microsoft Entra groups that are used with the Custom Autopatch groups don't have device membership overlaps.</p> |
#### Device conflict post device registration
Autopatch groups will keep monitoring for all device conflict scenarios listed in the [Manage device conflict scenarios when using Autopatch groups](../manage/windows-autopatch-manage-autopatch-groups.md#manage-device-conflict-scenarios-when-using-autopatch-groups) section even after devices were successfully registered with the service.
| Device conflict before device registration due to device membership overlap | You must resolve this conflict.<p>Devices fail to register with the service and are marked with a **Not registered** status. You’re required to make sure the Microsoft Entra groups that are used in an Autopatch group don’t have device membership overlaps.</p> |

124
windows/deployment/windows-autopatch/manage/windows-autopatch-manage-driver-and-firmware-updates.md
View File

@ -1,7 +1,7 @@
---
title: Manage driver and firmware updates
description: This article explains how you can manage driver and firmware updates with Windows Autopatch
ms.date: 07/08/2024
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
@ -17,46 +17,116 @@ ms.collection:
# Manage driver and firmware updates
You can manage and control your driver and firmware updates with Windows Autopatch. You can choose to receive driver and firmware updates automatically, or self-manage the deployment.
You can manage driver and firmware profiles for Windows 10 and later devices. By using targeted policies, you can expedite a specific driver and firmware update to release to your tenant. For more information about driver updates for Windows 10 and later, see [Windows driver update management in Intune](/mem/intune/protect/windows-driver-updates-overview).
> [!TIP]
> Windows Autopatch's driver and firmware update management is based on [Intune's driver and firmware update management](/mem/intune/protect/windows-driver-updates-overview). You can use **both** Intune and Windows Autopatch to manage your driver and firmware updates.
## Driver and firmware controls
## Automatic and Self-managed modes
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
Switching the toggle between Automatic and Self-managed modes creates driver profiles on a per-ring basis within your tenant.
You can manage and control your driver and firmware updates by:
- Controlling the flow of all drivers to an Autopatch group or rings within an Autopatch group
- Controlling the flow of a specific driver or firmware across your entire tenant via approvals
- Approving and deploying other drivers and firmware that previously couldn’t be centrally managed
### Automatic and Manual modes
The Autopatch service creates additional driver profiles on a per-deployment ring and per group basis within your tenant.
> [!NOTE]
> For more information about policies created for Driver updates for Windows 10 and later, see [Changes made at feature activation](../references/windows-autopatch-changes-made-at-feature-activation.md#driver-updates-for-windows-10-and-later).
Choosing between Automatic and Manual modes can be done per-deployment ring and/or per Autopatch group. For a single Autopatch group, a mix of both Automatic and Manual policies is allowed. If you were previously in Manual mode, we create Manual policies for all your group rings. If Automatic (the default) was previously used, we create Automatic policies instead.
> [!IMPORTANT]
> If you switch between Automatic and Manual modes, new policies are generated to **replace old policies**. **You’ll lose any approvals, paused drivers, and declined drivers previously made for those groups and/or deployment rings**.
| Modes | Description |
| ----- | -----|
| Automatic | We recommend using **Automatic** mode.<p>Automatic mode (default) is recommended for organizations with standard Original Equipment Manufacturer (OEM) devices where no recent driver or hardware issues have occurred due to Windows Updates. Automatic mode ensures the most secure drivers are installed using Autopatch deployment ring rollout.</p> |
| Self-managed | When you use **Self-managed** mode, no drivers are installed in your environment without your explicit approval. You can still use Intune to choose specific drivers and deploy them on a ring-by-ring basis.<p>Self-managed mode turns off Windows Autopatch's automatic driver deployment. Instead, the Administrator controls the driver deployment.<p>The Administrator selects the individual driver within an Intune driver update profile. Then, Autopatch creates an Intune driver update profile per deployment ring. Drivers can vary between deployment rings.</p><p>The drivers listed for selection represent only the drivers needed for the targeted clients, which are the Autopatch rings. Therefore, the drivers offered may vary between rings depending on the variety of device hardware in an organization.</p> |
| Automatic | We recommend using **Automatic** mode.<p>Automatic mode (default) is recommended for organizations with standard Original Equipment Manufacturer (OEM) devices where no recent driver or hardware issues occurred due to Windows Updates.</p><p>Automatic mode ensures the most secure drivers are installed using Autopatch deployment ring rollout. You can also choose to deploy additional drivers from the **Other** tab to your deployment rings or Autopatch groups that are set to **Automatic**.</p> |
| Manual | When you use **Manual** mode, no drivers are installed in your environment without your explicit approval. You can also choose to deploy additional drivers from the Other tab to your deployment rings or Autopatch groups that are set to Manual.<p>Manual mode turns off Windows Autopatch’s automatic driver deployment. Instead, the Administrator controls the driver deployment.</p><p>The Administrator selects the individual drivers to be deployed to their tenant. Then, the Administrator can choose to approve those drivers for deployment. Drivers approved can vary between deployment rings.</p> |
## Set driver and firmware updates to Automatic or Self-managed mode
> [!NOTE]
> In both Automatic and Manual modes, the drivers listed for selection represent only the drivers needed for the targeted clients, which are the Autopatch deployment rings. Therefore, the drivers offered may vary between rings depending on the variety of device hardware in an organization.
**To set driver and firmware updates to Automatic or Self-managed mode:**
#### Set driver and firmware updates to Automatic or Manual mode
**To set driver and firmware updates to Automatic or Manual mode:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Navigate to **Devices** > **Windows Autopatch** > **Release management** > **Release settings**.
1. In the **Windows Driver Updates** section, read and accept the agreement.
1. Select either **Automatic** or **Self-managed**.
1. Navigate to **Devices** > **Manage Updates** > **Windows Updates** > **Driver Updates** tab.
1. Select the groups you’d like to modify. Find the Driver update settings section, then select Edit.
1. Set the policy to be **Automatic** or **Manual** for each deployment ring within the previously selected group.
1. If you select **Automatic**, you can choose a **Deferral period** in days from the dropdown menu.
2. If you select **Manual**, the deferral day setting can’t be set and displays **Not applicable**.
1. Select **Review + Save** to review all changes made.
1. Once the review is done, select **Save** to commit your changes.
## View driver and firmware policies created by Windows Autopatch
##### Choose the deferral period for driver and firmware updates for Automatic deployment rings
**To view driver and firmware policies created by Windows Autopatch:**
For deployment rings set to **Automatic**, you can choose the deferral period for driver and firmware updates. The deferral period is the number of days that you must wait to deploy after a driver becomes available. By default, these deferral values match the values you set for your Windows quality updates.
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Navigate to **Devices** > **Driver updates for Windows 10 and later**.
1. Windows Autopatch creates four policies. The policy names begin with **Windows Autopatch - Driver Update Policy** and end with the name of the deployment ring to which they're targeted in brackets. For example, **Windows Autopatch - Driver Update Policy [Test]**.
The deferral period allows you to delay the installation of driver and firmware updates on the devices in the specified deployment ring in case you want to test the update on a smaller group of devices first or avoid potential disruptions during a busy period.
The `CreateDriverUpdatePolicy` is created for the Test, First, Fast, and Broad deployment rings. The policy settings are defined in the following table:
The deferral period can be set from 0 to 14 days, and it can be different for each deployment ring.
| Policy name | DisplayName | Description | Approval Type | DeploymentDeferralInDays |
| ----- | ----- | ----- | ----- | ----- |
| `CreateDriverUpdatePolicy` | Windows Autopatch - Driver Update Policy [**Test**] | Driver Update Policy for device **Test** group | Automatic | `0` |
| `CreateDriverUpdatePolicy`| Windows Autopatch - Driver Update Policy [**First**] | Driver Update Policy for device **First** group | Automatic | `1` |
| `CreateDriverUpdatePolicy` |Windows Autopatch - Driver Update Policy [**Fast**] | Driver Update Policy for device **Fast** group | Automatic | `6` |
| `CreateDriverUpdatePolicy` | Windows Autopatch - Driver Update Policy [**Broad**] | Driver Update Policy for device **Broad** group | Automatic | `9` |
> [!NOTE]
> The deferral period only applies to automatically approved driver and firmware updates. An admin must specify the date to start offering a driver with any manual approval.
## Feedback and support
### Recommended driver and firmware updates across managed devices
If you need support with this feature, and have enrolled your tenant into Windows Autopatch, [submit a support request](../operate/windows-autopatch-support-request.md).
#### Recommended drivers and firmware
Recommended drivers are the best match for the 'required' driver updates that Windows Update can identify for a device. To be a recommended update, the OEM or driver publisher must mark the update as required and the update must be the most recent update version marked as required. These updates are the same ones available through Windows Update and are almost always the most current update version for a driver.
When an OEM releases a newer update version that qualifies to be the new recommended driver, it replaces the previous update as the recommended driver update. If the older update version is still applicable to a device in the policy, it's moved to the **Other drivers** tab. If the older version was previously approved, it remains approved.
##### Approve and deploy recommended drivers
**To approve and deploy recommended drivers:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), navigate to **Devices** > **Manage updates** > **Windows updates** > **Driver updates**.
1. Select **Manage drivers for Autopatch groups** or select one of the **Drivers to review** links.
1. Select the driver or drivers you’d like to manage.
1. Select **Manage**. You can either:
1. Approve for all policies
2. Decline for all unreviewed policies
3. Manage for individual policies
1. In the **Approve for all policies** dropdown, select the date to make the driver available through Windows Update.
1. In the **Manage for individual policies** dropdown, select the policies to approve or decline the driver.
1. Select **Save**.
### Extensions and Plug and play driver updates
Extensions and Plug and play driver updates might not require admin approval.
| Driver update | Description |
| ----- | ----- |
| Extensions | Windows Autopatch doesn't manage extension drivers. They're easily identified by the term 'extension' in the name. Extensions are typically minor updates to a base driver package that can enhance, modify, or filter the functionality provided by the base driver. They play a crucial role in facilitating effective communication between the operating system and the hardware. If the device hasn't received drivers from Windows Update for some time, the device might have multiple extension drivers offered during the first scan. For more information, see [Why do my devices have driver updates installed that didn't pass through an updates policy?](/mem/intune/protect/windows-driver-updates-overview#why-do-my-devices-have-driver-updates-installed-that-didnt-pass-through-an-updates-policy). |
| Plug and play | When Windows detects a hardware or software component (such as, but not limited to, a mouse, keyboard, or webcam) without an existing driver, it automatically downloads and installs the latest driver to ensure the component functions properly to keep the end-user productive. After the initial installation, the driver becomes manageable. Any additional updates require approval before being offered to the device. |
### Other drivers and firmware
Other driver updates are updates available from the original equipment manufacturer (OEM) aside from the current recommended driver update. These updates remain in the policy if they're newer than the driver version that is currently installed on at least one device with the policy.
These updates can include:
- A previously recommended update is superseded by a newer update version
- Firmware updates
- Optional driver updates, or updates that the OEM doesn't intend to be installed on all devices by default
#### Approve and deploy other drivers
**To approve and deploy other drivers:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431), navigate to **Devices** > **Manage updates** > **Windows update** > **Driver Updates**.
1. Select **Manage drivers for Autopatch groups** or select one of the **Drivers to review** links.
1. Select **Other drivers** tab. You can either:
1. Select the driver or drivers you’d like to manage.
1. Select **Manage**. You can either:
1. Approve for all policies
2. Decline for all unreviewed policies
3. Manage for individual policies
1. In the **Approve for all policies** dropdown, select the date to make the driver available through Windows Update.
1. In the **Manage for individual policies** dropdown, select the policies to approve or decline the driver.
1. Select **Save**.

218
windows/deployment/windows-autopatch/manage/windows-autopatch-manage-windows-feature-update-releases.md
View File

@ -1,218 +0,0 @@
---
title: Manage Windows feature update releases
description: This article explains how you can manage Windows feature updates with Autopatch groups
ms.date: 07/08/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
ms.localizationpriority: medium
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.reviewer: andredm7
ms.collection:
- highpri
- tier1
---
# Manage Windows feature update releases
You can create custom releases for Windows feature update deployments in Windows Autopatch.
## Before you begin
Before you start managing custom Windows feature update releases, consider the following:
- If you're planning on using either the [Default or Custom Autopatch groups](../deploy/windows-autopatch-groups-overview.md#key-concepts) ensure:
- The Default Autopatch group has all deployment rings and deployment cadences you need.
- You have created all your Custom Autopatch groups prior to creating custom releases.
- Review [Windows feature update prerequisites](/mem/intune/protect/windows-10-feature-updates#prerequisites).
- Review the [Windows feature updates policy limitations](/mem/intune/protect/windows-10-feature-updates#limitations-for-feature-updates-for-windows-10-and-later-policy).
## About the auto-populate automation for release phases
By default, the deployment rings of each Autopatch group will be sequentially assigned to a phase. For example, the first deployment ring of each Autopatch group is assigned to Phase 1, and the second deployment ring of each Autopatch group is assigned to Phase 2, etc.
The following table explains the auto-populating assignment of your deployments rights if you have two Autopatch groups. One Autopatch group is named Finance and the other is named Marketing; each Autopatch group has four (Finance) and five (Marketing) deployment rings respectively.
| Phases | Finance | Marketing
| ----- | ----- | ----- |
| Phase 1 | Test | Test |
| Phase 2 | Ring1 | Ring1 |
| Phase 3 | Ring2 | Ring2 |
| Phase 4 | Last | Ring3 |
If the Autopatch groups are edited after a release is created (Active status), the changes to the Autopatch group won't be reflected unless you create a new custom release.
If you wish to change the auto-populating assignment of your deployment rings to release phases, you can do so by adding, removing, or editing the auto-populated phases.
### More information about the completion date of a phase
The goal completion date of a phase is calculated using the following formula:
`<First Deployment Date> + (<Number of gradual rollout groups> - 1) * Days in between groups (7) + Deadline for feature updates (5 days) + Grace Period (2 days).`
This formula is only applicable for **Deadline-driven** not for Scheduled-driven deployment cadences. For more information, see [Customize Windows Update settings](../operate/windows-autopatch-groups-windows-update.md).
> [!IMPORTANT]
> By default, both the **Deadline for feature updates** and the **Grace period** values are set by Windows Autopatch in every [Update rings for Windows 10 and later policy](/mem/intune/protect/windows-10-update-rings) created by Autopatch groups.
### How to use the Windows feature update blade
Use the Windows feature update blade to check in the overall status of the [default release](../operate/windows-autopatch-groups-windows-feature-update-overview.md#default-release) and the custom ones you create.
**To access the Windows feature update blade:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** from the left navigation menu.
1. Under the **Windows Autopatch** section, select **Release management**.
1. In the **Release management** blade, under the **Release schedule** tab, select **Windows feature updates**.
1. In the **Windows feature updates** blade, you can see all the information about the releases. The columns are described in the following table:
| Status | Description |
| ----- | ----- |
| Release name | Name of the release |
| Version to deploy | Version to deploy for the applicable release or phase |
| Status | Status of the applicable release or phase:<ul><li>Scheduled</li><li>Active</li><li>Inactive</li><li>Paused</li><li>Canceled</li></ul> |
| First deployment |<ul><li>The date the deployment for the applicable release or phase will begin.</li><li>Feature update policy for Windows 10 and later is created 24 hours prior to the first deployment date. The service automation runs twice a day at 4:00AM and 4:00PM (UTC).</li><li>Not all devices within a phase will be offered the feature update on the same date when using gradual rollout.</li></ul> |
| Goal completion date | The date the devices within the release or phases are expected to finish updating. The completion date is calculated using the following formula:<p>`<First deployment date> + (<Number of gradual rollout groups> - 1) * Days in between groups (7) + Deadline for feature updates (5) + Grace Period (2)`</p> |
#### About release and phase statuses
##### Release statuses
A release is made of one or more phases. The release status is based on the calculation and consolidation of each phase status.
The release statuses are described in the following table:
| Release status | Definition | Options |
| ----- | ----- | ----- |
| Scheduled | Release is scheduled and not all phases have yet created its Windows feature update policies |<ul><li>Releases with the **Scheduled status** can't be canceled but can have its deployment cadence edited as not all phases have yet created its Windows feature update policies.</li><li>Autopatch groups and its deployment rings that belong to a **Scheduled** release can't be assigned to another release.</li></ul> |
| Active | All phases in the release are active. This means all phases have reached their first deployment date, which created the Windows feature update policies. |<ul><li>Release can be paused but can't be edited or canceled since the Windows feature update policy was already created for its phases.</li><li>Autopatch groups and their deployment rings can be assigned to another release.</li></ul> |
| Inactive | All the Autopatch groups within the release have been assigned to a new release. As a result, the Windows feature update policies were unassigned from all phases from within the release. |<ul><li>Release can be viewed as a historical record.</li><li>Releases can't be deleted, edited, or canceled.</li></ul> |
| Paused | All phases in the release are paused. The release will remain paused until you resume it. | <ul><li>Releases with Paused status can't be edited or canceled since the Windows feature update policy was already created for its phases.</li><li>Release can be resumed.</li></ul> |
| Canceled | All phases in the release are canceled. | <ul><li>Releases with Canceled status can't be edited or canceled since the Windows feature update policy wasn't created for its phases.</li><li>Canceled release can't be deleted.</li></ul> |
##### Phase statuses
A phase is made of one or more Autopatch group deployment rings. Each phase reports its status to its release.
> [!IMPORTANT]
> The determining factor that makes a phase status transition from **Scheduled** to **Active** is when the service automatically creates the Windows feature update policy for each Autopatch group deployment ring. Additionally, the phase status transition from **Active** to **Inactive** occurs when Windows feature update policies are unassigned from the Autopatch groups that belong to a phase. This can happen when an Autopatch group and its deployment rings are re-used as part of a new release.
| Phase status | Definition |
| ----- | ----- |
| Scheduled | The phase is scheduled but hasn't reached its first deployment date yet. The Windows feature update policy hasn't been created for the respective phase yet. |
| Active | The first deployment date has been reached. The Windows feature update policy has been created for the respective phase. |
| Inactive | All Autopatch groups within the phase were re-assigned to a new release. All Windows feature update policies were unassigned from the Autopatch groups. |
| Paused | Phase is paused. You must resume the phase. |
| Canceled | Phase is canceled. All Autopatch groups within the phase can be used with a new release. A phase that's canceled can't be deleted. |
#### Details about Windows feature update policies
Windows Autopatch creates one Windows feature update policy per phase using the following naming convention:
`Windows Autopatch - DSS policy - <Release Name> - Phase <Phase Number>`
These policies can be viewed in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
The following table is an example of the Windows feature update policies that were created for phases within a release:
| Policy name | Feature update version | Rollout options | First deployment date| Final deployment date availability | Day between groups | Support end date |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Windows Autopatch - DSS Policy - My feature update release - Phase 1 | Windows 10 21H2 | Make update available as soon as possible | April 24, 2023 | April 24, 2023 | N/A | June 11, 2024 |
| Windows Autopatch - DSS Policy - My feature update release - Phase 2 | Windows 10 21H2 | Make update available as soon as possible | June 26, 2023 | July 17, 2023 | 7 | June 11, 2024 |
| Windows Autopatch - DSS Policy - My feature update release - Phase 3 | Windows 10 21H2 | Make update available as soon as possible | July 24, 2023 | August 14, 2023 | 7 | June 11, 2024 |
| Windows Autopatch - DSS Policy - My feature update release - Phase 4 | Windows 10 21H2 | Make update available as soon as possible | August 28, 2023 | September 10, 2023 | 7 | June 11, 2024 |
| Windows Autopatch - DSS Policy - My feature update release - Phase 5 | Windows 10 21H2 | Make update available as soon as possible | September 25, 2023 | October 16, 2023 | 7 | June 11, 2024 |
## Create a custom release
**To create a custom release:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** from the left navigation menu.
1. Under the **Windows Autopatch** section, select **Release management**.
1. In the **Release management** blade, select **Release schedule**, then **Windows feature updates**.
1. In the **Windows feature updates** blade, select **New release**.
1. In the **Basics** page:
1. Enter a **Name** for the custom release.
2. Select the **Version** to deploy.
3. Enter a **Description** for the custom release.
4. Select **Next**.
1. In the **Autopatch groups** page, choose one or more existing Autopatch groups you want to include in the custom release, then select Next.
1. You can't choose Autopatch groups that are already part of an existing custom release. Select **Autopatch groups assigned to other releases** to review existing assignments.
1. In the Release phases page, review the number of auto-populated phases. You can Edit, Delete and Add phase based on your needs. Once you're ready, select **Next**. **Before you proceed to the next step**, all deployment rings must be assigned to a phase, and all phases must have deployment rings assigned.
1. In the **Release schedule** page, choose **First deployment date**, and the number of **Gradual rollout groups**, then select **Next**. **You can only select the next day**, not the current day, as the first deployment date. The service creates feature update policy for Windows 10 and later twice a day at 4:00AM and 4:00PM (UTC) and can't guarantee that the release will start at the current day given the UTC variance across the globe.
1. The **Goal completion date** only applies to the [Deadline-driven deployment cadence type](../operate/windows-autopatch-groups-windows-update.md#deadline-driven). The Deadline-drive deployment cadence type can be specified when you configure the Windows Updates settings during the Autopatch group creation/editing flow.
2. Additionally, the formula for the goal completion date is `<First Deployment Date> + (<Number of gradual rollout groups> - 1) * Days in between groups (7) + Deadline for feature updates (5 days) + Grace Period (2 days)`.
1. In the **Review + create** page, review all settings. Once you're ready, select **Create**.
> [!NOTE]
> Custom releases can't be deleted from the Windows feature updates release management blade. The custom release record serves as a historical record for auditing purposes when needed.
## Edit a release
> [!NOTE]
> Only custom releases that have the **Scheduled** status can be edited. A release phase can only be edited prior to reaching its first deployment date. Additionally, you can only edit the deployment dates when editing a release.
**To edit a custom release:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** from the left navigation menu.
1. Under the **Windows Autopatch** section, select **Release management**.
1. In the **Release schedule** tab, select **Windows feature updates**.
1. In the **Windows feature updates** blade, select the **horizontal ellipses (…)** > Edit to customize your gradual rollout of your feature updates release, then select **Save**.
1. Only the release schedule can be customized when using the edit function. You can't add or remove Autopatch groups or modify the phase order when editing a release.
1. Select **Review + Create**.
1. Select **Apply** to save your changes.
## Pause and resume a release
> [!CAUTION]
> You should only pause and resume [Windows quality](../operate/windows-autopatch-groups-windows-quality-update-overview.md#pause-and-resume-a-release) and [Windows feature updates](../operate/windows-autopatch-groups-windows-feature-update-overview.md) on Windows Autopatch managed devices using the Windows Autopatch Release management blade. Do **not** use the Microsoft Intune end-user experience flows to pause or resume Windows Autopatch managed devices.
> [!IMPORTANT]
> Pausing or resuming an update can take up to eight hours to be applied to devices. Windows Autopatch uses Microsoft Intune as its device management solution and that's the average frequency Windows devices take to communicate back to Microsoft Intune with new instructions to pause, resume or rollback updates. For more information, see [how long does it take for devices to get a policy, profile, or app after they are assigned from Microsoft Intune](/mem/intune/configuration/device-profile-troubleshoot#how-long-does-it-take-for-devices-to-get-a-policy-profile-or-app-after-they-are-assigned).
**To pause or resume a release:**
> [!NOTE]
> If you've paused an update, the specified release will have the **Paused** status. The Windows Autopatch service can't overwrite IT admin's pause. You must select **Resume** to resume the update. The **Paused by Service Pause** status **only** applies to Windows quality updates. Windows Autopatch doesn't pause Windows feature updates on your behalf.
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** from the left navigation menu.
1. Under the **Windows Autopatch** section, select **Release management**.
1. In the **Release schedule** tab, select **Windows feature updates**.
1. In the **Windows feature updates** blade, select the **horizontal ellipses (…)** > **Pause** or **Resume** to pause or resume your feature updates release.
1. Select a reason from the dropdown menu.
1. Optional. Enter details about why you're pausing or resuming the selected update.
1. If you're resuming an update, you can select one or more deployment rings.
1. Select **Pause deployment** or **Resume deployment** to save your changes.
## Cancel a release
> [!IMPORTANT]
> You can only cancel a release under the Scheduled status. You cannot cancel a release under the **Active**, **Inactive** or **Paused** statuses.
**To cancel a release:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** from the left navigation menu.
1. Under the **Windows Autopatch** section, select **Release management**.
1. In the **Release schedule** tab, select **Windows feature updates**.
1. In the **Windows feature updates** blade, select the **horizontal ellipses (…)** > **Cancel** to cancel your feature updates release.
1. Select a reason for cancellation from the dropdown menu.
1. Optional. Enter details about why you're pausing or resuming the selected update.
1. Select **Cancel deployment** to save your changes.
## Roll back a release
> [!CAUTION]
> Do **not** use Microsoft Intune's end-user flows to rollback Windows feature update deployments for Windows Autopatch managed devices. If you need assistance with rolling back deployments, [submit a support request](../operate/windows-autopatch-support-request.md).
Windows Autopatch **doesn't** support the rollback of Windows feature updates through its end-user experience flows.
## Contact support
If you're experiencing issues related to Windows feature update deployments, [submit a support request](../operate/windows-autopatch-support-request.md).

37
windows/deployment/windows-autopatch/manage/windows-autopatch-microsoft-365-apps-enterprise.md
View File

@ -1,7 +1,7 @@
---
title: Microsoft 365 Apps for enterprise
description: This article explains how Windows Autopatch manages Microsoft 365 Apps for enterprise updates
ms.date: 10/27/2023
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
@ -17,8 +17,13 @@ ms.collection:
# Microsoft 365 Apps for enterprise
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
## Service level objective
> [!IMPORTANT]
> To update Microsoft 365 Apps for enterprise, you must [create at least one Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#create-an-autopatch-group) first and **Microsoft 365 app update setting** must be set to [**Allow**](#allow-or-block-microsoft-365-app-updates). For more information on workloads supported by Windows Autopatch groups, see [Software update workloads](../deploy/windows-autopatch-groups-overview.md#software-update-workloads).
Windows Autopatch aims to keep at least 90% of eligible devices on a [supported version](/deployoffice/overview-update-channels#support-duration-for-monthly-enterprise-channel) of the Monthly Enterprise Channel (MEC) for the:
- [Enterprise Standard Suite](/deployoffice/about-microsoft-365-apps). The Enterprise Standard Suite includes Access, Excel, OneNote, Outlook, PowerPoint, and Word.
@ -27,7 +32,7 @@ Windows Autopatch aims to keep at least 90% of eligible devices on a [supported
Microsoft 365 Apps deployed on the [Monthly Enterprise Channel](/deployoffice/overview-update-channels#monthly-enterprise-channel-overview) are supported for two months.
> [!NOTE]
> [Microsoft Teams](../operate/windows-autopatch-teams.md) uses a different update channel from the rest of Microsoft 365 Apps.
> [Microsoft Teams](../manage/windows-autopatch-teams.md) uses a different update channel from the rest of Microsoft 365 Apps.
## Device eligibility
@ -36,14 +41,14 @@ For a device to be eligible for Microsoft 365 Apps for enterprise updates (both
- The device must be turned on and have an internet connection.
- The device must be able to access the [required network endpoints](../prepare/windows-autopatch-configure-network.md#required-microsoft-product-endpoints) to reach the Office Content Delivery Network (CDN).
- There are no policy conflicts between Microsoft Autopatch policies and customer policies.
- The device must have checked into the Intune service in the last five days.
- The device must check into the Intune service in the last five days.
- If Microsoft 365 Apps are running, the apps must close for the update process to complete.
## Update release schedule
All devices registered for Windows Autopatch 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 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 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 downloads, there's a seven day [update deadline](../references/windows-autopatch-microsoft-365-policies.md) 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 downloads, there's a seven day [update deadline](../manage/windows-autopatch-microsoft-365-policies.md) that specifies how long the user has until the user must apply the update.
## Deployment rings
@ -63,7 +68,7 @@ Windows Autopatch configures the following end user experiences:
Updates are only applied when Microsoft 365 Apps aren't running. Therefore, [end user notifications for Microsoft 365 Apps](/deployoffice/updates/end-user-update-notifications-microsoft-365-apps) usually appear when:
- The user is working in a Microsoft 365 App, such as Microsoft Outlook, and hasn't closed it in several days.
- The user is working in a Microsoft 365 App, such as Microsoft Outlook, and didn't closed it in several days.
- The update [deadline arrives](/deployoffice/updates/end-user-update-notifications-microsoft-365-apps#notifications-your-users-see-when-you-set-an-update-deadline-for-microsoft-365-apps) and the updates still aren't applied.
### Office client app configuration
@ -74,7 +79,7 @@ To ensure that users are receiving automatic updates, Windows Autopatch prevents
Windows Autopatch doesn't allow you to pause or roll back an update in the Microsoft Intune admin center.
[Submit a support request](../operate/windows-autopatch-support-request.md) to the Windows Autopatch Service Engineering Team to pause or roll back an update when needed.
[Submit a support request](../manage/windows-autopatch-support-request.md) to the Windows Autopatch Service Engineering Team to pause or roll back an update when needed.
> [!NOTE]
> Updates are bundled together into a single release in the [Monthly Enterprise Channel](/deployoffice/overview-update-channels#monthly-enterprise-channel-overview). Therefore, we can't roll back only a portion of the update for Microsoft 365 Apps for enterprise.
@ -94,19 +99,19 @@ For organizations seeking greater control, you can allow or block Microsoft 365
**To allow or block Microsoft 365 App updates:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
2. Navigate to the **Devices** > **Release Management** > **Release settings**.
3. Go to the **Microsoft 365 apps updates** section. By default, the **Allow/Block** toggle is set to **Allow**.
4. Turn off the **Allow** toggle to opt out of Microsoft 365 App update policies. You'll see the notification: *Update in process. This setting will be unavailable until the update is complete.*
5. Once the update is complete, you'll receive the notification: *This setting is updated.*
2. Navigate to the **Tenant administration** > **Windows Autopatch** > **Autopatch groups** > **Update settings**.
3. Go to the **Microsoft 365 apps updates** section. By default, the **Allow/Block** toggle is set to **Block**.
4. Turn off the **Allow** toggle to opt out of Microsoft 365 App update policies. You see the notification: *Update in process. This setting will be unavailable until the update is complete.*
5. Once the update is complete, you receive the notification: *This setting is updated.*
> [!NOTE]
> If the notification: *This setting couldn't be updated. Please try again or submit a support request.* appears, use the following steps:<ol><li>Refresh your page.</li><li>Please repeat the same steps in To block Windows Autopatch Microsoft 365 apps updates.</li><li>If the issue persists, [submit a support request](../operate/windows-autopatch-support-request.md).</li>
> If the notification: *This setting couldn't be updated. Please try again or submit a support request.* appears, use the following steps:<ol><li>Refresh your page.</li><li>Please repeat the same steps in To block Microsoft 365 apps updates.</li><li>If the issue persists, [submit a support request](../manage/windows-autopatch-support-request.md).</li>
**To verify if the Microsoft 365 App update setting is set to Allow:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
2. Navigate to **Devices** > **Configuration profiles** > **Profiles**.
3. The following **five** profiles should be discoverable from the list of profiles:
3. The following profiles should be discoverable from the list of profiles:
1. Windows Autopatch - Office Configuration
2. Windows Autopatch - Office Update Configuration [Test]
3. Windows Autopatch - Office Update Configuration [First]
@ -117,7 +122,7 @@ For organizations seeking greater control, you can allow or block Microsoft 365
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
2. Navigate to **Devices** > **Configuration profiles** > **Profiles**.
3. The following **five** profiles should be removed from your list of profiles and no longer visible/active. Use the Search with the keywords "Office Configuration". The result should return *0 profiles filtered*.
3. The following profiles should be removed from your list of profiles and no longer visible/active. Use the Search with the keywords "Office Configuration". The result should return *0 profiles filtered*.
1. Windows Autopatch - Office Configuration
2. Windows Autopatch - Office Update Configuration [Test]
3. Windows Autopatch - Office Update Configuration [First]
@ -128,10 +133,8 @@ For organizations seeking greater control, you can allow or block Microsoft 365
[Servicing profiles](/deployoffice/admincenter/servicing-profile) is a feature in the [Microsoft 365 Apps admin center](https://config.office.com/) that provides controlled update management of monthly Office updates, including controls for user and device targeting, scheduling, rollback, and reporting.
A [service profile](/deployoffice/admincenter/servicing-profile#compatibility-with-other-management-tools) takes precedence over other policies, such as a Microsoft Intune policy or the Office Deployment Tool. The servicing profile affects all devices that meet the [device eligibility requirements](#device-eligibility) regardless of existing management tools in your environment. So, if you're targeting a managed device with a servicing profile it's ineligible for Microsoft 365 App update management.However, the device may still be eligible for other managed updates.
A [service profile](/deployoffice/admincenter/servicing-profile#compatibility-with-other-management-tools) takes precedence over other policies, such as a Microsoft Intune policy or the Office Deployment Tool. The servicing profile affects all devices that meet the [device eligibility requirements](#device-eligibility) regardless of existing management tools in your environment. So, if you're targeting a managed device with a servicing profile it's ineligible for Microsoft 365 App update management. However, the device might still be eligible for other managed updates.
## Incidents and outages
If devices in your tenant aren't meeting the [service level objective](#service-level-objective) for Microsoft 365 Apps for enterprise updates, an incident is raised. The Windows Autopatch Service Engineering Team will work to bring the devices back into compliance.
If you're experiencing issues related to Microsoft 365 Apps for enterprise updates, [submit a support request](../operate/windows-autopatch-support-request.md).
If you're experiencing issues related to Microsoft 365 Apps for enterprise updates, [submit a support request](../manage/windows-autopatch-support-request.md).

4
windows/deployment/windows-autopatch/manage/windows-autopatch-microsoft-365-policies.md
View File

@ -1,7 +1,7 @@
---
title: Microsoft 365 Apps for enterprise update policies
description: This article explains the Microsoft 365 Apps for enterprise policies in Windows Autopatch
ms.date: 07/08/2024
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: concept-article
@ -16,6 +16,8 @@ ms.collection:
# Microsoft 365 Apps for enterprise update policies
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
## Conflicting and unsupported policies
Deploying any of the following policies to a managed device makes that device ineligible for management since the device prevents us from delivering the service as designed.

35
windows/deployment/windows-autopatch/manage/windows-autopatch-release-schedule.md Normal file
View File

@ -0,0 +1,35 @@
---
title: Manage the release schedule
description: How to manage the release schedule
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
ms.localizationpriority: medium
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.reviewer: andredm7
ms.collection:
- highpri
- tier1
---
# Manage the Release schedule
[!INCLUDE [windows-autopatch-applies-to-all-licenses](../includes/windows-autopatch-applies-to-all-licenses.md)]
Windows Autopatch provides a unique update experience and a single view for all your current quality, feature, and driver and firmware releases. This view:
- Consolidates all your applicable policies into a view consolidated by releases
- Provides an all-up summary of the current release applicable to your tenant
When you select a release, Windows Autopatch provides a list view of associated policies and metrics including:
- Start and end dates
- percentage complete
These metrics are a summary of the individual workload views that should be used to manage your updates.
> [!NOTE]
> **The device count metric is only available if you have Windows Enterprise E3+ or F3 licenses (included in Microsoft 365 F3, E3, or E5) licenses and have [activated Windows Autopatch features](../overview/windows-autopatch-overview.md#windows-enterprise-e3-and-f3-licenses).**<p>[Feature activation](../prepare/windows-autopatch-feature-activation.md) is optional and at no additional cost to you if you have Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5) licenses.</p><p>For more information, see [Licenses and entitlements](../prepare/windows-autopatch-prerequisites.md#licenses-and-entitlements). If you choose not to go through feature activation, you can still use the Windows Autopatch service for the features included in [Business premium and A3+ licenses](../overview/windows-autopatch-overview.md#business-premium-and-a3-licenses).</p>

16
windows/deployment/windows-autopatch/manage/windows-autopatch-support-request.md
View File

@ -1,7 +1,7 @@
---
title: Submit a support request
description: Details how to contact the Windows Autopatch Service Engineering Team and submit support requests
ms.date: 09/06/2023
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
@ -17,6 +17,8 @@ ms.collection:
# Submit a support request
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
> [!IMPORTANT]
> Make sure you've [added and verified your admin contacts](../deploy/windows-autopatch-admin-contacts.md). The Windows Autopatch Service Engineering Team will contact these individuals for assistance with remediating issues.
@ -29,7 +31,7 @@ Support requests are triaged and responded to as they're received.
1. Sign into the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431) and navigate to the **Tenant administration** menu.
1. In the **Windows Autopatch** section, select **Support requests**.
1. In the **Support requests** section, select **+ New support request**.
1. Enter your question(s) and/or a description of the problem.
1. Enter your questions and/or a description of the problem.
1. Review all the information you provided for accuracy.
1. When you're ready, select **Create**.
@ -44,12 +46,12 @@ Depending on your support contract, the following severity options are available
| Support contract | Severity options |
| ----- | ----- |
| Premier | Severity A, B or C |
| Unified | Critical or non-critical |
| Premier | Severity A, B, or C |
| Unified | Critical or noncritical |
## Manage an active support request
The primary contact for the support request will receive email notifications when a case is created, assigned to a service engineer to investigate, and mitigated. If, at any point, you have a question about the case, the best way to get in touch is to reply directly to one of those emails. If we have questions about your request or need more details, we'll email the primary contact listed on the support requests.
The primary contact for the support request receives email notifications when a case is created, assigned to a service engineer to investigate, and mitigated. If, at any point, you have a question about the case, the best way to get in touch is to reply directly to one of those emails. If we have questions about your request or need more details, we email the primary contact listed on the support requests.
## View all your active support requests
@ -75,7 +77,7 @@ You can edit support request details, for example, updating the primary case con
1. Update the editable information, add attachments to the case, or add a note for the Windows Autopatch Service Engineering Team.
1. Select **Save**.
Once a support request is mitigated, it can no longer be edited. If a request has been mitigated for less than 24 hours, you'll see the option to reactivate instead of edit. Once reactivated, you can again edit the request.
Once a support request is mitigated, it can no longer be edited. If a request was mitigated in less than 24 hours, you can reactivate instead of edit. Once reactivated, you can again edit the request.
## Microsoft FastTrack
@ -83,4 +85,4 @@ Once a support request is mitigated, it can no longer be edited. If a request ha
Customers who need help with Microsoft 365 workloads can sign in to [Microsoft FastTrack](https://fasttrack.microsoft.com/) with a valid Azure ID and submit a Request for Assistance.
Contact your Microsoft account team if you need additional assistance.
Contact your Microsoft account team if you need additional assistance.

12
windows/deployment/windows-autopatch/manage/windows-autopatch-teams.md
View File

@ -1,7 +1,7 @@
---
title: Microsoft Teams
description: This article explains how Microsoft Teams updates are managed in Windows Autopatch
ms.date: 09/15/2023
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
@ -17,6 +17,8 @@ ms.collection:
# Microsoft Teams
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
Windows Autopatch uses the [standard automatic update channel](/microsoftteams/teams-client-update#can-admins-deploy-updates-instead-of-teams-auto-updating) for Microsoft Teams.
## Device eligibility
@ -30,13 +32,13 @@ For a device to be eligible for automated Teams updates as a part of Windows Aut
## Update release schedule
The Teams desktop client updates are released once a month for all users, and twice a month for members of the Technology Adoption Program (TAP).
The Teams desktop client updates are released once a month for all users, and twice a month for members of the [Technology Adoption Program (TAP)](https://developer.microsoft.com/microsoft-365/tap).
Updates undergo vigorous internal testing and are first released to members of TAP for validation. The update usually takes place on a Monday. If a critical update is needed, Teams will bypass this schedule and release the update as soon as it's available.
Updates undergo vigorous internal testing and are first released to members of [Technology Adoption Program (TAP)](https://developer.microsoft.com/microsoft-365/tap) for validation. The update usually takes place on a Monday. If a critical update is needed, Teams bypasses this schedule and releases the update as soon as it's available.
## End user experience
Teams will check for updates every few hours behind the scenes, download the updates, and then will wait for the computer to be idle for at least 40 minutes before automatically installing the update.
Teams checks for updates every few hours behind the scenes, download the updates, and then waits for the computer to be idle for at least 40 minutes before automatically installing the update.
When an update is available, the following are required to be able to download the update:
@ -47,7 +49,7 @@ When an update is available, the following are required to be able to download t
> [!NOTE]
> If a user is on a version of Teams that is out of date, Teams will force the user to update prior to allowing them to use the application.
## Pausing and resuming updates
## Pause and resume updates
Windows Autopatch can't pause or resume Teams updates.

63
windows/deployment/windows-autopatch/manage/windows-autopatch-troubleshoot-programmatic-controls.md Normal file
View File

@ -0,0 +1,63 @@
---
title: Troubleshoot programmatic controls
titleSuffix: Windows Autopatch
description: Solutions to commonly encountered problems when using Windows Autopatch API.
ms.service: windows-client
ms.subservice: autopatch
ms.topic: troubleshooting
ms.author: tiaraquan
author: tiaraquan
manager: aaroncz
ms.collection:
- tier1
ms.localizationpriority: medium
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
ms.date: 09/16/2024
---
# Troubleshoot programmatic controls
This troubleshooting guide addresses the most common issues that IT administrators face when using Windows Autopatch API. For a general troubleshooting guide for Windows Update, see [Windows Update troubleshooting](/troubleshoot/windows-client/deployment/windows-update-issues-troubleshooting?toc=/windows/deployment/toc.json&bc=/windows/deployment/breadcrumb/toc.json).
## The device isn't receiving an update that I deployed
- Check that the device doesn't have updates of the relevant category paused. See [Pause feature updates](/windows/deployment/update/waas-configure-wufb) and [Pause quality updates](/windows/deployment/update/waas-configure-wufb).
- **Feature updates only**: The device might have a safeguard hold applied for the given feature update version. For more about safeguard holds, see [Safeguard holds](/windows/deployment/update/safeguard-holds) and [Opt out of safeguard holds](/windows/deployment/update/safeguard-opt-out).
- Check that the deployment to which the device is assigned has the state *offering*. Deployments that have the states *paused* or *scheduled* doesn't deploy content to devices.
- Check that the device was scanned for updates and is scanning the Windows Update service. To learn more about scanning for updates, see [Scanning updates](/windows/deployment/update/how-windows-update-works#scanning-updates).
- **Feature updates only**: Check that the device is successfully enrolled in feature update management. A device that is successfully enrolled will be represented by a Microsoft Entra device resource with an update management enrollment for feature updates and have no Microsoft Entra device registration errors.
- **Expedited quality updates only**: Check that the device has the Update Health Tools installed (available for Windows 10 version 1809 or later in the update described in [KB 4023057 - Update for Windows 10 Update Service components](https://support.microsoft.com/topic/kb4023057-update-for-windows-10-update-service-components-fccad0ca-dc10-2e46-9ed1-7e392450fb3a), or a more recent quality update). The Update Health Tools are required for a device to receive an expedited quality update. On a device, the program can be located at **C:\\Program Files\\Microsoft Update Health Tools**. You can verify its presence by reviewing **Add or Remove Programs** or using the following PowerShell script: `Get-WmiObject -Class Win32_Product | Where-Object {$_.Name -match "Microsoft Update Health Tools"}`.
## The device is receiving an update that I didn't deploy
- Check that the device is scanning the Windows Update service and not a different endpoint. If the device is scanning for updates from a WSUS endpoint, for example, it might receive different updates. To learn more about scanning for updates, see [Scanning updates](/windows/deployment/update/how-windows-update-works#scanning-updates).
- **Feature updates only**: Check that the device is successfully enrolled in feature update management. A device that isn't successfully enrolled might receive different updates according to its feature update deferral period, for example. A device that is successfully enrolled will be represented by a Microsoft Entra device resource with an update management enrollment for feature updates and have no Microsoft Entra device registration errors.
### The device installed a newer update than the expedited update I deployed
There are some scenarios when a deployment to expedite an update results in the installation of a more recent update than specified in policy. This result occurs when the newer update includes and surpasses the specified update, and that newer update is available before a device checks in to install the update that's specified in the expedited update policy.
Installing the most recent quality update reduces disruptions to the device and user while applying the benefits of the intended update. This avoids having to install multiple updates, which each might require separate reboots.
A more recent update is deployed when the following conditions are met:
- The device isn't targeted with a deferral policy that blocks installation of a more recent update. In this case, the most recently available update that isn't deferred is the update that might install.
- During the process to expedite an update, the device runs a new scan that detects the newer update. This can occur due to the timing of:
- When the device restarts to complete installation
- When the device runs its daily scan
- When a new update becomes available
When a scan identifies a newer update, Windows Update attempts to stop installation of the original update, cancel the restart, and then starts the download and installation of the more recent update.
While expedite update deployments override an update deferral for the update version that's specified, they don't override deferrals that are in place for any other update version.
<!--Using include for Update Health Tools log location-->
[!INCLUDE [Windows Autopatch Update Health Tools](../includes/windows-autopatch-update-health-tools-logs.md)]
## Policy considerations for drivers
<!--Using include for Policy considerations for drivers-->
[!INCLUDE [Windows Autopatch driver policy considerations](../includes/windows-autopatch-driver-policy-considerations.md)]

68
windows/deployment/windows-autopatch/manage/windows-autopatch-update-rings.md Normal file
View File

@ -0,0 +1,68 @@
---
title: Manage Update rings
description: How to manage update rings
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
ms.localizationpriority: medium
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.reviewer: andredm7
ms.collection:
- highpri
- tier1
---
# Manage Update rings
[!INCLUDE [windows-autopatch-applies-to-all-licenses](../includes/windows-autopatch-applies-to-all-licenses.md)]
You can manage Update rings for Windows 10 and later devices with Windows Autopatch. Using Update rings, you can control when and how updates are installed on your devices. For more information, see [Configure Update rings for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-update-rings).
## Import Update rings for Windows 10 and later
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
You can import your organization’s existing Intune Update rings for Windows 10 and later into Windows Autopatch. Importing your organization’s Update rings provides the benefits of the Windows Autopatch's reporting and device readiness without the need to redeploy, or change your organization’s existing update rings.
Imported rings automatically register all targeted devices into Windows Autopatch. For more information about device registration, see the [device registration workflow diagram](../deploy/windows-autopatch-register-devices.md#detailed-device-registration-workflow-diagram).
> [!NOTE]
> Devices which are registered as part of an imported ring, might take up to 72 hours after the devices have received the latest version of the policy, to be reflected in Windows Autopatch devices blade and reporting. For more information about reporting, see [Windows quality and feature update reports overview](../monitor/windows-autopatch-windows-quality-and-feature-update-reports-overview.md).
> [!NOTE]
> Device registration failures don't affect your existing update schedule or targeting. However, devices that fail to register might affect Windows Autopatch's ability to provide reporting and insights. Any conflicts should be resolved as needed. For additional assistance, [submit a support request](../manage/windows-autopatch-support-request.md).
### To import Update rings for Windows 10 and later
**To import Update rings for Windows 10 and later:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
2. Select **Devices** from the left navigation menu.
3. Under the **Manage updates** section, select **Windows updates**.
4. In the **Windows updates** blade, go to the **Update rings** tab.
5. Select **Enroll policies**.
6. Select the existing rings you would like to import.
7. Select **Import**.
### Remove an imported Update ring for Windows 10 and later
**To remove an Imported Update rings for Windows 10 and later:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
2. Select **Devices** from the left navigation menu.
3. Under the **Manage updates** section, select **Windows updates**.
4. In the **Windows updates** blade, go to the **Update rings**.
5. Select the Update rings for Windows 10 and later you would like to remove.
6. Select the **horizontal ellipses (...)** and select **Remove**.
### Known limitations
The following Windows Autopatch features aren't available with imported Intune Update rings:
- [Autopatch groups](../deploy/windows-autopatch-groups-overview.md) and [features dependent on Autopatch groups](../deploy/windows-autopatch-groups-overview.md#supported-configurations)
- [Moving devices in between deployment rings in devices](../deploy/windows-autopatch-register-devices.md#move-devices-in-between-deployment-rings)
- [Automated deployment ring remediation functions](../deploy/windows-autopatch-device-registration-overview.md#automated-deployment-ring-remediation-functions)
- [Policy health and remediation](../monitor/windows-autopatch-policy-health-and-remediation.md)

223
windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-overview.md
View File

@ -1,7 +1,7 @@
---
title: Windows feature updates overview
description: This article explains how Windows feature updates are managed with Autopatch groups
ms.date: 07/08/2024
description: This article explains how Windows feature updates are managed
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: overview
@ -15,158 +15,129 @@ ms.collection:
- tier1
---
# Windows feature updates overview
# Windows feature update
Microsoft provides robust mobile device management (MDM) solutions such as Microsoft Intune, Windows Update for Business, Configuration Manager etc. However, the administration of these solutions to keep Windows devices up to date with the latest Windows feature releases rests on your organization's IT admins. The Windows feature update process is considered one of the most expensive and time consuming tasks for IT since it requires incremental rollout and validation.
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
Windows feature updates consist of:
Windows Autopatch provides tools to assist with the controlled roll out of annual Windows feature updates. These policies provide tools to allow version targeting, phased releases, and even Windows 10 to Windows 11 update options. For more information about how to configure feature update profiles, see [Feature updates for Windows 10 and later policy in Intune](/mem/intune/protect/windows-10-feature-updates).
- Keeping Windows devices protected against behavioral issues.
- Providing new features to boost end-user productivity.
## Multi-phase feature update
Windows Autopatch makes it easier and less expensive for you to keep your Windows devices up to date. You can focus on running your core businesses while Windows Autopatch runs update management on your behalf.
Multi-phase feature update allows you to create customizable feature update deployments using multiple phases for your [existing Autopatch groups](../manage/windows-autopatch-manage-autopatch-groups.md). These phased releases can be tailored to meet your organizational unique needs.
## Service level objective
### Release statuses
Windows Autopatch's service level objective for Windows feature updates aims to keep **95%** of eligible devices on the targeted Windows OS version [currently serviced](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2) for its default and global releases maintained by the service, and custom releases created and managed by you.
A release is made of one or more phases. The release status is based on the calculation and consolidation of each phase status.
## Device eligibility criteria
The release statuses are described in the following table:
Windows Autopatch's device eligibility criteria for Windows feature updates aligns with [Windows Update for Business and Microsoft Intune's device eligibility criteria](/mem/intune/protect/windows-10-feature-updates#prerequisites).
| Release status | Definition | Options |
| ----- | ----- | ----- |
| Scheduled | Release is scheduled and not all phases created its Windows feature update policies |<ul><li>Releases with the **Scheduled status** can't be canceled but can have its deployment cadence edited as not all phases created its Windows feature update policies.</li><li>Autopatch groups and its deployment rings that belong to a **Scheduled** release can't be assigned to another release.</li></ul> |
| Active | All phases in the release are active. All phases reached their first deployment date, which created the Windows feature update policies. |<ul><li>Release can be paused but can't be edited or canceled since the Windows feature update policy was already created for its phases.</li><li>Autopatch groups and their deployment rings can be assigned to another release.</li></ul> |
| Inactive | All the Autopatch groups within the release are assigned to a new release. As a result, the Windows feature update policies were unassigned from all phases from within the release. |<ul><li>Release can be viewed as a historical record.</li><li>Releases can't be deleted, edited, or canceled.</li></ul> |
| Paused | All phases in the release are paused. The release remains paused until you resume it. | <ul><li>Releases with the Paused status can't be edited or canceled since the Windows feature update policy was already created for its phases.</li><li>Release can be resumed.</li></ul> |
| Canceled | All phases in the release are canceled. | <ul><li>Releases with the Canceled status can't be edited or canceled since the Windows feature update policy wasn't created for its phases.</li><li>Canceled release can't be deleted.</li></ul> |
#### Phase statuses
A phase is made of one or more [Autopatch group deployment rings](../deploy/windows-autopatch-groups-overview.md#autopatch-group-deployment-rings). Each phase reports its status to its release.
> [!IMPORTANT]
> Windows Autopatch supports registering [Windows 10 Long-Term Servicing Channel (LTSC)](/windows/whats-new/ltsc/) devices that are being currently serviced by the [Windows LTSC](/windows/release-health/release-information). The service only supports managing the [Windows quality updates](../operate/windows-autopatch-windows-quality-update-overview.md) workload for devices currently serviced by the LTSC. Windows Update for Business service and Windows Autopatch don't offer Windows feature updates for devices that are part of the LTSC. You must either use [LTSC media](https://www.microsoft.com/evalcenter/evaluate-windows-10-enterprise) or the [Configuration Manager operating system deployment capabilities to perform an in-place upgrade](/mem/configmgr/osd/deploy-use/upgrade-windows-to-the-latest-version) for Windows devices that are part of the LTSC.
> The determining factor that makes a phase status transition from **Scheduled** to **Active** is when the service automatically creates the Windows feature update policy for each Autopatch group deployment ring. Additionally, the phase status transition from **Active** to **Inactive** occurs when Windows feature update policies are unassigned from the Autopatch groups that belong to a phase. This can happen when an Autopatch group and its deployment rings are re-used as part of a new release.
## Key benefits
- Windows Autopatch makes it easier and less expensive for you to keep your Windows devices up to date. You can focus on running your core businesses while Windows Autopatch runs update management on your behalf.
- You're in control of telling Windows Autopatch when your organization is ready to move to the next Windows OS version.
- Combined with custom releases, Autopatch Groups gives your organization great control and flexibility to help you plan your gradual rollout in a way that works for your organization.
- Simplified end-user experience with rich controls for gradual rollouts, deployment cadence and speed.
- No need to manually modify the default Windows feature update policies (default release) to be on the Windows OS version your organization is currently ready for.
- Allows for scenarios where you can deploy a single release across several Autopatch groups and its deployment rings.
## Key concepts
- A release is made of one or more deployment phases and contains the required OS version to be gradually rolled out throughout its deployment phases.
- A phase (deployment phase) is made of one or more Autopatch group deployment rings. A phase:
- Works as an additional layer of deployment cadence settings that can be defined by IT admins (only for Windows feature updates) on top of Autopatch group deployment rings (Windows update rings policies).
- Deploys Windows feature updates across one or more Autopatch groups.
- There are three types of releases:
- Default
- Global
- Custom
### Default release
Windows Autopatch's default Windows feature update release is a service-driven release that enforces the minimum Windows OS version currently serviced by the Windows servicing channels for the deployment rings in the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group).
> [!TIP]
> Windows Autopatch allows you to [create custom Windows feature update releases](../operate/windows-autopatch-groups-manage-windows-feature-update-release.md#create-a-custom-release).
When devices are registered by manually adding them to the Windows Autopatch Device Registration Microsoft Entra ID assigned group, devices are assigned to deployment rings as part of the default Autopatch group. Each deployment ring has its own Windows feature update policy assigned to them. This is intended to minimize unexpected Windows OS upgrades once new devices register with the service.
The policies:
- Contain the minimum Windows 10 version currently serviced by the [Windows servicing channels](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2). The current minimum Windows OS version is **Windows 10 21H2**.
- Set a bare minimum Windows OS version required by the service once devices are registered with the service.
If the device is registered with Windows Autopatch, and the device is:
- Below the service's currently targeted Windows feature update, that device will be automatically upgraded to the service's target version when the device meets the [device eligibility criteria](#device-eligibility-criteria).
- On, or above the currently targeted Windows feature update version, there won't be any Windows OS upgrades available to that device.
#### Policy configuration for the default release
If your tenant is enrolled with Windows Autopatch, you can see the following default policies created by the service in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431):
| Policy name | Phase mapping | Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Windows Autopatch - DSS Policy [Test] | Phase 1 | Windows 10 21H2 | Make update available as soon as possible | May 9, 2023 | N/A | N/A | June 11, 2024 |
| Windows Autopatch - DSS Policy [First] | Phase 2 | Windows 10 21H2 | Make update available as soon as possible | May 16, 2023 | N/A | N/A | June 11, 2024 |
| Windows Autopatch - DSS Policy [Fast] | Phase 3 | Windows 10 21H2 | Make update available as soon as possible | May 23, 2023 | N/A | N/A | June 11, 2024 |
| Windows Autopatch - DSS Policy [Broad] | Phase 4 | Windows 10 21H2 | Make update available as soon as possible | May 30, 2023 | N/A | N/A | June 11, 2024 |
> [!NOTE]
> Gradual rollout settings aren't configured in the default Windows Update feature policy. If the date of the final group availability is changed to a past date, all remaining devices are offered the update as soon as possible. For more information, see [rollout options for Windows Updates in Microsoft Intune](/mem/intune/protect/windows-update-rollout-options#make-updates-available-gradually).
### Global release
Windows Autopatch's global Windows feature update release is a service-driven release. Like the [default release](#default-release), the Global release enforces the [minimum Windows OS version currently serviced by the Windows servicing channels](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2).
There are two scenarios that the Global release is used:
| Scenario | Description |
| Phase status | Definition |
| ----- | ----- |
| Scenario #1 | You assign Microsoft Entra groups to be used with the deployment ring (Last) or you add additional deployment rings when you customize the [Default Autopatch group](../manage/windows-autopatch-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group).<p>A global Windows feature update policy is automatically assigned behind the scenes to the newly added deployment rings or when you assigned Microsoft Entra groups to the deployment ring (Last) in the Default Autopatch group.</p> |
| Scenario #2 | You create new [Custom Autopatch groups](../manage/windows-autopatch-manage-autopatch-groups.md#create-a-custom-autopatch-group).<p>The global Windows feature policy is automatically assigned behind the scenes to all deployment rings as part of the Custom Autopatch groups you create.</p> |
| Scheduled | The phase is scheduled but didn't reach its first deployment date yet. The Windows feature update policy wasn't created for the respective phase yet. |
| Active | The first deployment date reached. The Windows feature update policy was created for the respective phase. |
| Inactive | All Autopatch groups within the phase are reassigned to a new release. All Windows feature update policies were unassigned from the Autopatch groups. |
| Paused | Phase is paused. You must resume the phase. |
| Canceled | Phase is canceled. All Autopatch groups within the phase can be used with a new release. A phase that is canceled can't be deleted. |
#### Phase policy configuration
For more information about Windows feature update policies that are created for phases within a release, see [Windows feature update policies](../manage/windows-autopatch-windows-feature-update-policies.md).
## Create a custom release
**To create a custom release:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** from the left navigation menu.
1. Under the **Manage updates** section, select **Windows updates**.
1. In the **Windows updates** blade, select the **Feature updates** tab.
1. Select **Create Autopatch multi-phase release**.
1. In the **Basics** page:
1. Enter a **Name** for the custom release.
2. Select the **Version** to deploy.
3. Enter a **Description** for the custom release.
4. Select **Next**.
1. In the **Autopatch groups** page, choose one or more existing Autopatch groups you want to include in the custom release, then select Next.
1. You can't choose Autopatch groups that are already part of an existing custom release. Select **Autopatch groups assigned to other releases** to review existing assignments.
1. In the Release phases page, review the number of autopopulated phases. You can Edit, Delete, and Add a phase based on your needs. Once you're ready, select **Next**. **Before you proceed to the next step**, all deployment rings must be assigned to a phase, and all phases must have deployment rings assigned.
1. In the **Release schedule** page, choose **First deployment date**, and the number of **Gradual rollout groups**, then select **Next**. **You can only select the next day**, not the current day, as the first deployment date. The service creates feature update policy for Windows 10 and later twice a day at 4:00AM and 4:00PM (UTC) and can't guarantee that the release starts on the current day given the UTC variance across the globe.
1. The **Goal completion date** only applies to the [Deadline-driven deployment cadence type](../operate/windows-autopatch-groups-windows-update.md#deadline-driven). The Deadline-drive deployment cadence type can be specified when you configure the Windows Updates settings during the Autopatch group creation/editing flow.
2. Additionally, the formula for the goal completion date is `<First Deployment Date> + (<Number of gradual rollout groups> - 1) * Days in between groups (7) + Deadline for feature updates (5 days) + Grace Period (2 days)`.
1. In the **Review + create** page, review all settings. Once you're ready, select **Create**.
> [!NOTE]
> Global releases don't show up in the Windows feature updates release management blade.
> Custom releases can't be deleted from the Feature updates tab in the Windows updates blade. The custom release record serves as a historical record for auditing purposes when needed.
#### Policy configuration values
See the following table on how Windows Autopatch configures the values for its global Windows feature update policy. If your tenant is enrolled with Windows Autopatch, you can see the following default policies created by the service in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431):
| Policy name | Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Windows Autopatch - Global DSS Policy [Test] | Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024 |
## Edit a custom release
> [!NOTE]
> Gradual rollout settings aren't configured in the default Windows Update feature policy. If the date of the final group availability is changed to be a past date, all remaining devices are offered the update as soon as possible. For more information, see [rollout options for Windows Updates in Microsoft Intune](/mem/intune/protect/windows-update-rollout-options#make-updates-available-gradually).
> Only custom releases that have the **Scheduled** status can be edited. A release phase can only be edited prior to reaching its first deployment date. Additionally, you can only edit the deployment dates when editing a release.
### Differences between the default and global Windows feature update policies
**To edit a custom release:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** from the left navigation menu.
1. Under the **Manage updates** section, select **Windows updates**.
1. In the **Windows update** blade, select the **Feature updates** tab.
1. In the **Feature updates** tab, select the **horizontal ellipses (…)** > Edit to customize your gradual rollout of your feature updates release, then select **Save**.
1. Only the release schedule can be customized when using the edit function. You can't add or remove Autopatch groups or modify the phase order when editing a release.
1. Select **Review + Create**.
1. Select **Apply** to save your changes.
## Cancel a release
> [!IMPORTANT]
> Once you create a custom Windows feature update release, both the global and the default Windows feature update policies are unassigned from Autopatch group's deployment rings behind the scenes.
> You can only cancel a release under the **Scheduled** status. You cannot cancel a release under the **Active**, **Inactive, or **Paused** statuses.
The differences in between the global and the default Windows feature update policy values are:
**To cancel a release:**
| Default Windows feature update policy | Global Windows feature update policy |
| ----- | ----- |
| <ul><li>Set by default with the Default Autopatch group and assigned to Test, Ring1, Ring2, Ring3. The default policy isn't automatically assigned to the Last ring in the Default Autopatch group.</li><li>The Windows Autopatch service keeps its minimum Windows OS version updated following the recommendation of minimum Windows OS version [currently serviced by the Windows servicing channels](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2).</li></ul> | <ul><li>Set by default and assigned to all new deployment rings added as part of the Default Autopatch group customization.</li><li>Set by default and assigned to all deployment rings created as part of Custom Autopatch groups.</li></ul> |
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** from the left navigation menu.
1. Under the **Manage updates** section, select **Windows updates**.
1. In the **Windows updates** blade, select the **Feature updates** tab.
1. In the **Feature updates** tab, select the **horizontal ellipses (…)** > **Cancel** to cancel your feature updates release.
1. Select a reason for cancellation from the dropdown menu.
1. Optional. Enter details about why you're pausing or resuming the selected update.
1. Select **Cancel deployment** to save your changes.
### Custom release
A custom release is the release that you create to tell Windows Autopatch how you want the service to manage Windows OS upgrades on your behalf.
Custom releases gives you flexibility to do Windows OS upgrades on your pace, but still relying on Windows Autopatch to give you insights of how your OS upgrades are going and additional deployment controls through the Windows feature updates release management experience.
When a custom release is created and assigned to Autopatch groups, either the default or global releases are unassigned to avoid feature update policy for Windows 10 and later conflicts.
For more information on how to create a custom release, see [Manage Windows feature update release](../operate/windows-autopatch-groups-manage-windows-feature-update-release.md#create-a-custom-release).
### About Windows Update rings policies
Feature update policies work with Windows Update rings policies. Windows Update rings policies are created for each deployment ring for the [Default or a Custom Autopatch group](../deploy/windows-autopatch-groups-overview.md#key-concepts) based on the deployment settings you define. The policy name convention is `Windows Autopatch Update Policy - <Autopatch group name> - <Deployment group name>`.
The following table details the default Windows Update rings policy values that affect either the default or custom Windows feature updates releases:
| Policy name | Microsoft Entra group assignment | Quality updates deferral in days | Feature updates deferral in days | Feature updates uninstall window in days | Deadline for quality updates in days | Deadline for feature updates in days | Grace period | Auto restart before deadline |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Windows Autopatch Update Policy - default - Test | Windows Autopatch - Test | 0 | 0 | 30 | 0 | 5 | 0 | Yes |
| Windows Autopatch Update Policy - default - Ring1 | Windows Autopatch - Ring1 | 1 | 0 | 30 | 2 | 5 |2 | Yes |
| Windows Autopatch Update Policy - default - Ring2 | Windows Autopatch - Ring2 | 6 | 0 | 30 | 2 | 5 | 2 | Yes |
| Windows Autopatch Update Policy - default - Ring3 | Windows Autopatch - Ring3 | 9 | 0 | 30 | 5 | 5 | 2 | Yes |
| Windows Autopatch Update Policy - default - Last | Windows Autopatch - Last | 11 | 0 | 30 | 3 | 5 | 2 | Yes |
## Pause and resume a release
> [!IMPORTANT]
> When you create a custom Windows feature update release, new Windows feature update policies are:<ul><li>Created corresponding to the settings you defined while creating the release.</li><li>Assigned to the Autopatch group's deployment rings you select to be included in the release.</li></ul>
> **Pausing or resuming an update can take up to eight hours to be applied to devices**. Windows Autopatch uses Microsoft Intune as its device management solution and that's the average frequency Windows devices take to communicate back to Microsoft Intune with new instructions to pause, resume or rollback updates. For more information, see [how long does it take for devices to get a policy, profile, or app after they are assigned from Microsoft Intune](/mem/intune/configuration/device-profile-troubleshoot#how-long-does-it-take-for-devices-to-get-a-policy-profile-or-app-after-they-are-assigned).
## Common ways to manage releases
**To pause and resume a release:**
### Use case #1
> [!IMPORTANT]
> **You can only pause an Autopatch group if you have Windows Enterprise E3+ or F3 licenses (included in Microsoft 365 F3, E3, or E5) licenses and have [activated Windows Autopatch features](../overview/windows-autopatch-overview.md#windows-enterprise-e3-and-f3-licenses).**<p>[Feature activation](../prepare/windows-autopatch-feature-activation.md) is optional and at no additional cost to you if you have Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5) licenses.</p><p>For more information, see [Licenses and entitlements](../prepare/windows-autopatch-prerequisites.md#licenses-and-entitlements). If you choose not to go through feature activation, you can still use the Windows Autopatch service for the features included in [Business premium and A3+ licenses](../overview/windows-autopatch-overview.md#business-premium-and-a3-licenses).</p>
| Scenario | Solution |
| ----- | ----- |
| You're working as the IT admin at Contoso Ltd., and you need to gradually rollout of Windows 11's latest version to several business units across your organization. | Custom Windows feature update releases deliver OS upgrades horizontally, through phases, to one or more Autopatch groups.<br>Phases:<ul><li>Set your organization's deployment cadence.</li><li>Work like deployment rings on top of Autopatch group's deployment rings. Phases group one or more deployment rings across one or more Autopatch groups.</li></ul><br>See the following visual for a representation of Phases with custom releases. |
> [!NOTE]
> If you pause an update, the specified release has the **Paused** status. The Windows Autopatch service can't overwrite IT admin's pause. You must select **Resume** to resume the update. [The **Paused by Service Pause** status **only** applies to Windows quality updates](../manage/windows-autopatch-windows-quality-update-overview.md#pause-and-resume-a-release). Windows Autopatch doesn't pause Windows feature updates on your behalf.
:::image type="content" source="../media/autopatch-groups-manage-feature-release-case-1.png" alt-text="Manage Windows feature update release use case one" lightbox="../media/autopatch-groups-manage-feature-release-case-1.png":::
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** from the left navigation menu.
1. Under the **Manage updates** section, select **Windows updates**.
1. In the **Windows updates** blade, select the **Feature updates** tab.
1. In the **Feature updates** tab, select the **horizontal ellipses (…)** > **Pause** or **Resume** to pause or resume your feature updates release.
1. Select a reason from the dropdown menu.
1. Optional. Enter details about why you're pausing or resuming the selected update.
1. If you're resuming an update, you can select one or more deployment rings.
1. Select **Pause deployment** or **Resume deployment** to save your changes.
### Use case #2
## Roll back a release
| Scenario | Solution |
| ----- | ----- |
| You're working as the IT admin at Contoso Ltd. and your organization isn't ready to upgrade its devices to either Windows 11 or the newest Windows 10 OS versions due to conflicting project priorities within your organization.<p>However, you want to keep Windows Autopatch managed devices supported and receiving monthly updates that are critical to security and the health of the Windows ecosystem.</p> | Default Windows feature update releases deliver the minimum Windows OS upgrade vertically to each Windows Autopatch group (either [Default](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group) or [Custom](../deploy/windows-autopatch-groups-overview.md#about-custom-autopatch-groups)). The Default Windows Autopatch group is pre-configured with the [default Windows feature update release](#default-release) and no additional configuration is required from IT admins as Autopatch manages the default release on your behalf.<p>If you decide to edit the default Windows Autopatch group to add additional deployment rings, these rings receive a [global Windows feature update policy](#global-release) set to offer the minimum Windows OS version [currently serviced](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2) to devices. Every custom Autopatch group you create gets a [global Windows feature update policy](#global-release) that enforces the minimum Windows OS version [currently serviced](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2).</p><p>See the following visual for a representation of default releases.</p>|
:::image type="content" source="../media/autopatch-groups-manage-feature-release-case-2.png" alt-text="Manage Windows feature update release use case two" lightbox="../media/autopatch-groups-manage-feature-release-case-2.png":::
Windows Autopatch doesn't support the rollback of Windows feature updates through its end-user experience flows.

111
windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-policies.md Normal file
View File

@ -0,0 +1,111 @@
---
title: Windows feature updates policies
description: This article describes Windows feature update policies used in Windows Autopatch
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
ms.localizationpriority: medium
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.reviewer: andredm7
ms.collection:
- highpri
- tier1
---
# Windows feature update policies
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
## Windows feature updates for Windows 10 and later
These policies control the minimum target version of Windows that a device is meant to accept. Throughout the rest of the article, these policies are referred to as DSS policies. There are four of these policies in your tenant with the following naming convention:
**`Modern Workplace DSS Policy [ring name]`**
### Windows feature update deployment settings
| Setting name | Test | First | Fast | Broad |
| ----- | ----- | ----- | ----- | ----- |
| Name | Current targeted version of Windows | Current targeted version of Windows | Current targeted version of Windows | Current targeted version of Windows |
| Rollout options | Immediate start | Immediate start | Immediate start | Immediate start |
### Windows feature update policy assignments
| Setting name | Test | First | Fast | Broad |
| ----- | ----- | ----- | ----- | ----- |
| Included groups | Modern Workplace Devices-Windows Autopatch-Test | Modern Workplace Devices-Windows Autopatch-First | Modern Workplace Devices-Windows Autopatch-Fast | Modern Workplace Devices-Windows Autopatch-Broad |
## Default release policy configuration
You can see the following default policies created by the service in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431):
| Policy name | Phase mapping | Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Windows Autopatch - DSS Policy [Test] | Phase 1 | Windows 10 21H2 | Make update available as soon as possible | May 9, 2023 | N/A | N/A | June 11, 2024 |
| Windows Autopatch - DSS Policy [First] | Phase 2 | Windows 10 21H2 | Make update available as soon as possible | May 16, 2023 | N/A | N/A | June 11, 2024 |
| Windows Autopatch - DSS Policy [Fast] | Phase 3 | Windows 10 21H2 | Make update available as soon as possible | May 23, 2023 | N/A | N/A | June 11, 2024 |
| Windows Autopatch - DSS Policy [Broad] | Phase 4 | Windows 10 21H2 | Make update available as soon as possible | May 30, 2023 | N/A | N/A | June 11, 2024 |
> [!NOTE]
> Gradual rollout settings aren't configured in the default Windows Update feature policy. If the date of the final group availability is changed to a past date, all remaining devices are offered the update as soon as possible. For more information, see [rollout options for Windows Updates in Microsoft Intune](/mem/intune/protect/windows-update-rollout-options#make-updates-available-gradually).
## Global release policy configuration
Windows Autopatch configures the values for its global Windows feature update policy. See the following default policies created by the service in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431):
| Policy name | Feature update version | Rollout options | First deployment ring availability | Final deployment ring availability | Day between deployment rings | Support end date |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Windows Autopatch - Global DSS Policy [Test] | Windows 10 21H2 | Make update available as soon as possible | N/A | N/A | N/A | June 11, 2024 |
> [!NOTE]
> Gradual rollout settings aren't configured in the default Windows Update feature policy. If the date of the final group availability is changed to be a past date, all remaining devices are offered the update as soon as possible. For more information, see [rollout options for Windows Updates in Microsoft Intune](/mem/intune/protect/windows-update-rollout-options#make-updates-available-gradually).
### Difference between the default and global update policies
> [!IMPORTANT]
> Once you create a custom Windows feature update release, both the global and the default Windows feature update policies are unassigned from Autopatch group's deployment rings behind the scenes.
The differences in between the global and the default Windows feature update policy values are:
| Default Windows feature update policy | Global Windows feature update policy |
| ----- | ----- |
| <ul><li>Set by default with an Autopatch group and assigned to Test, Ring1, Ring2, Ring3. The default policy isn't automatically assigned to the Last ring in an Autopatch group.</li><li>The Windows Autopatch service keeps its minimum Windows OS version updated following the recommendation of minimum Windows OS version [currently serviced by the Windows servicing channels](/windows/release-health/release-information?msclkid=ee885719baa511ecb838e1a689da96d2).</li></ul> | <ul><li>Set by default and assigned to all new deployment rings added as part of an Autopatch group customization</li><li>Set by default and assigned to all deployment rings created as part of Autopatch groups.</li></ul> |
## Windows Update ring policies
Feature update policies work with Windows Update rings policies. Windows Update rings policies are created for each deployment ring for the [Autopatch group](../deploy/windows-autopatch-groups-overview.md#key-benefits) based on the deployment settings you define. The policy name convention is **`Windows Autopatch Update Policy - <Autopatch group name> - <Deployment group name>`**.
The following table details the default Windows Update rings policy values that affect either the default or custom Windows feature updates releases:
| Policy name | Microsoft Entra group assignment | Quality updates deferral in days | Feature updates deferral in days | Feature updates uninstall window in days | Deadline for quality updates in days | Deadline for feature updates in days | Grace period | Auto restart before deadline |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Windows Autopatch Update Policy - Default - Test | Windows Autopatch - Test | 0 | 0 | 30 | 0 | 5 | 0 | Yes |
| Windows Autopatch Update Policy - Default - Ring1 | Windows Autopatch - Ring1 | 1 | 0 | 30 | 2 | 5 |2 | Yes |
| Windows Autopatch Update Policy - Default - Ring2 | Windows Autopatch - Ring2 | 6 | 0 | 30 | 2 | 5 | 2 | Yes |
| Windows Autopatch Update Policy - Default - Ring3 | Windows Autopatch - Ring3 | 9 | 0 | 30 | 5 | 5 | 2 | Yes |
| Windows Autopatch Update Policy - Default - Last | Windows Autopatch - Last | 11 | 0 | 30 | 3 | 5 | 2 | Yes |
> [!IMPORTANT]
> When you create a custom Windows feature update release, new Windows feature update policies are:<ul><li>Created corresponding to the settings you defined while creating the release.</li><li>Assigned to the Autopatch group's deployment rings you select to be included in the release.</li></ul>
## Phase policy configuration
Windows Autopatch creates one Windows feature update policy per phase using the following naming convention:
**`Windows Autopatch - DSS policy - <Release Name> - Phase <Phase Number>`**
These policies can be viewed in the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
The following table is an example of the Windows feature update policies that were created for phases within a release:
| Policy name | Feature update version | Rollout options | First deployment date| Final deployment date availability | Day between groups | Support end date |
| ----- | ----- | ----- | ----- | ----- | ----- | ----- |
| Windows Autopatch - DSS Policy - My feature update release - Phase 1 | Windows 10 21H2 | Make update available as soon as possible | April 24, 2023 | April 24, 2023 | N/A | June 11, 2024 |
| Windows Autopatch - DSS Policy - My feature update release - Phase 2 | Windows 10 21H2 | Make update available as soon as possible | June 26, 2023 | July 17, 2023 | 7 | June 11, 2024 |
| Windows Autopatch - DSS Policy - My feature update release - Phase 3 | Windows 10 21H2 | Make update available as soon as possible | July 24, 2023 | August 14, 2023 | 7 | June 11, 2024 |
| Windows Autopatch - DSS Policy - My feature update release - Phase 4 | Windows 10 21H2 | Make update available as soon as possible | August 28, 2023 | September 10, 2023 | 7 | June 11, 2024 |
| Windows Autopatch - DSS Policy - My feature update release - Phase 5 | Windows 10 21H2 | Make update available as soon as possible | September 25, 2023 | October 16, 2023 | 7 | June 11, 2024 |

52
windows/deployment/update/deployment-service-feature-updates.md → windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-programmatic-controls.md
View File

@ -1,12 +1,12 @@
---
title: Deploy feature updates
titleSuffix: Windows Update for Business deployment service
description: Use Windows Update for Business deployment service to deploy feature updates to devices in your organization.
title: Programmatic controls for feature updates
titleSuffix: Windows Autopatch
description: Use programmatic controls to deploy feature updates to devices in your organization.
ms.service: windows-client
ms.subservice: itpro-updates
ms.topic: conceptual
ms.author: mstewart
author: mestew
ms.subservice: autopatch
ms.topic: how-to
ms.author: tiaraquan
author: tiaraquan
manager: aaroncz
ms.collection:
- tier1
@ -14,17 +14,21 @@ ms.localizationpriority: medium
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
ms.date: 08/29/2023
ms.date: 09/16/2024
---
# Deploy feature updates with Windows Update for Business deployment service
# Programmatic controls for Windows feature updates
[!INCLUDE [windows-autopatch-applies-to-all-licenses](../includes/windows-autopatch-applies-to-all-licenses.md)]
<!--7512398-->
The Windows Update for Business deployment service is used to approve and schedule software updates. The deployment service exposes its capabilities through the [Microsoft Graph API](/graph/use-the-api). You can call the API directly, through a [Graph SDK](/graph/sdks/sdks-overview), or integrate them with a management tool such as [Microsoft Intune](/mem/intune).
Windows Autopatch programmatic controls are used to approve and schedule software updates through [Microsoft Graph API](/graph/use-the-api). You can call the API directly, through a [Graph SDK](/graph/sdks/sdks-overview), or integrate them with a management tool such as [Microsoft Intune](/mem/intune).
This article uses [Graph Explorer](/graph/graph-explorer/graph-explorer-overview) to walk through the entire process of deploying a feature update to clients. In this article, you will:
In this article, you will:
> [!div class="checklist"]
>
> * [Open Graph Explorer](#open-graph-explorer)
> * [Run queries to identify devices](#run-queries-to-identify-devices)
> * [Enroll devices](#enroll-devices)
@ -35,36 +39,35 @@ In this article, you will:
> * [Delete a deployment](#delete-a-deployment)
> * [Unenroll devices](#unenroll-devices)
## Prerequisites
All of the [prerequisites for the Windows Update for Business deployment service](deployment-service-prerequisites.md) must be met.
All of the [Windows Autopatch prerequisites](../prepare/windows-autopatch-prerequisites.md) must be met.
### Permissions
<!--Using include for Graph Explorer permissions-->
[!INCLUDE [Windows Update for Business deployment service permissions using Graph Explorer](./includes/wufb-deployment-graph-explorer-permissions.md)]
[!INCLUDE [Windows Autopatch permissions using Graph Explorer](../includes/windows-autopatch-graph-explorer-permissions.md)]
## Open Graph Explorer
<!--Using include for Graph Explorer sign in-->
[!INCLUDE [Graph Explorer sign in](./includes/wufb-deployment-graph-explorer.md)]
[!INCLUDE [Graph Explorer sign in](../includes/windows-autopatch-graph-explorer.md)]
## Run queries to identify devices
<!--Using include for Graph Explorer device queries-->
[!INCLUDE [Graph Explorer device queries](./includes/wufb-deployment-find-device-name-graph-explorer.md)]
[!INCLUDE [Graph Explorer device queries](../includes/windows-autopatch-find-device-name-graph-explorer.md)]
## Enroll devices
When you enroll devices into feature update management, the deployment service becomes the authority for feature updates coming from Windows Update.
As long as a device remains enrolled in feature update management through the deployment service, the device doesn't receive any other feature updates from Windows Update unless explicitly deployed using the deployment service. A device is offered the specified feature update if it hasn't already received the update. For example, if you deploy Windows 11 feature update version 22H2 to a device that's enrolled into feature update management and is currently on an older version of Windows 11, the device updates to version 22H2. If the device is already running version 22H2 or a later version, it stays on its current version.
When you enroll devices into feature update management, Windows Autopatch becomes the authority for feature updates coming from Windows Update.
As long as a device remains enrolled in feature update management through Windows Autopatch, the device doesn't receive any other feature updates from Windows Update unless explicitly deployed using Windows Autopatch. A device is offered the specified feature update if it hasn't already received the update. For example, if you deploy Windows 11 feature update version 22H2 to a device that's enrolled into feature update management and is currently on an older version of Windows 11, the device updates to version 22H2. If the device is already running version 22H2 or a later version, it stays on its current version.
> [!TIP]
> Windows Update for Business reports has a [workbook](wufb-reports-workbook.md#feature-updates-tab) that displays the current operating system version for devices. In the workbook, go to the **Feature updates** tab and in the **In Service feature update** tile, select the **View details** link to open the details flyout. The OS version and Microsoft Entra ID of devices can easily be exported into a .csv file or opened in [Azure Monitor Logs](/azure/azure-monitor/logs/log-query-overview) to help when creating a deployment audience.
> Windows Update for Business reports has a [workbook](/windows/deployment/update/wufb-reports-workbook#feature-updates-tab) that displays the current operating system version for devices. In the workbook, go to the **Feature updates** tab and in the **In Service feature update** tile, select the **View details** link to open the details flyout. The OS version and Microsoft Entra ID of devices can easily be exported into a .csv file or opened in [Azure Monitor Logs](/azure/azure-monitor/logs/log-query-overview) to help when creating a deployment audience.
<!--Using include for enrolling devices using Graph Explorer-->
[!INCLUDE [Graph Explorer enroll devices](./includes/wufb-deployment-enroll-device-graph-explorer.md)]
[!INCLUDE [Graph Explorer enroll devices](../includes/windows-autopatch-enroll-device-graph-explorer.md)]
## List catalog entries for feature updates
@ -99,7 +102,7 @@ When creating a deployment for a feature update, there are multiple options avai
- Deployment [start date](/graph/api/resources/windowsupdates-schedulesettings) of February 14, 2023 at 5 AM UTC
- [Gradual rollout](/graph/api/resources/windowsupdates-gradualrolloutsettings) at a rate of 100 devices every three days
- [Monitoring rule](/graph/api/resources/windowsupdates-monitoringrule) that will pause the deployment if five devices rollback the feature update
- [Monitoring rule](/graph/api/resources/windowsupdates-monitoringrule) that pauses the deployment if five devices rollback the feature update
- Default [safeguard hold](/graph/api/resources/windowsupdates-safeguardprofile) behavior of applying all applicable safeguards to devices in a deployment
- When safeguard holds aren't explicitly defined, the default safeguard hold behavior is applied automatically
@ -138,7 +141,8 @@ content-type: application/json
}
```
The response body will contain:
The response body contains:
- The new **Deployment ID**, `de910e12-3456-7890-abcd-ef1234567890` in the example
- The new **Audience ID**, `d39ad1ce-0123-4567-89ab-cdef01234567` in the example
- Any settings defined in the deployment request body
@ -228,7 +232,7 @@ GET https://graph.microsoft.com/beta/admin/windows/updates/deployments/de910e12-
## Add members to the deployment audience
The **Audience ID**, `d39ad1ce-0123-4567-89ab-cdef01234567`, was created when the deployment was created. The **Audience ID** is used to add members to the deployment audience. After the deployment audience is updated, Windows Update starts offering the update to the devices according to the deployment settings. As long as the deployment exists and the device is in the audience, the update will be offered.
The **Audience ID**, `d39ad1ce-0123-4567-89ab-cdef01234567`, was created when the deployment was created. The **Audience ID** is used to add members to the deployment audience. After the deployment audience is updated, Windows Update starts offering the update to the devices according to the deployment settings. As long as the deployment exists and the device is in the audience, the update is offered.
The following example adds three devices to the deployment audience using the **Microsoft Entra ID** for each device:
@ -282,7 +286,7 @@ content-type: application/json
## Delete a deployment
To remove the deployment completely, DELETE the deployment. Deleting the deployment will prevent the content from being offered to devices if they haven't already received it. To resume offering the content, a new approval will need to be created.
To remove the deployment completely, DELETE the deployment. Deleting the deployment prevents the content from being offered to devices if they haven't already received it. To resume offering the content, a new approval needs to be created.
The following example deletes the deployment with a **Deployment ID** of `de910e12-3456-7890-abcd-ef1234567890`:
@ -294,4 +298,4 @@ DELETE https://graph.microsoft.com/beta/admin/windows/updates/deployments/de910e
## Unenroll devices
<!--Using include for removing device enrollment-->
[!INCLUDE [Graph Explorer enroll devices](./includes/wufb-deployment-graph-unenroll.md)]
[!INCLUDE [Graph Explorer unenroll devices](../includes/windows-autopatch-graph-unenroll.md)]

12
windows/deployment/windows-autopatch/manage/windows-autopatch-windows-quality-update-communications.md
View File

@ -1,7 +1,7 @@
---
title: Windows quality update communications
description: This article explains Windows quality update communications
ms.date: 07/08/2024
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: concept-article
@ -17,6 +17,8 @@ ms.collection:
# Windows quality update communications
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
There are three categories of communication that are sent out during a Windows quality and feature update:
- [Standard communications](#standard-communications)
@ -35,7 +37,7 @@ Communications are posted to, as appropriate for the type of communication, to t
| Communication | Location | Timing | Description |
| ----- | ----- | ----- | ----- |
| Release schedule | <ul><li>Messages blade</li><li>Email sent to your specified [admin contacts](../deploy/windows-autopatch-admin-contacts.md)</li><ul> | At least seven days prior to the second Tuesday of the month| Notification of the planned release window for each ring. |
| Release schedule | <ul><li>Messages blade</li><li>Email sent to your specified [admin contacts](../deploy/windows-autopatch-admin-contacts.md)</li><ul> | At least seven days before the second Tuesday of the month| Notification of the planned release window for each ring. |
| Release start | Same as release schedule | The second Tuesday of every month. | Notification that the update is now being released into your environment. |
| Release summary | Same as release schedule | The fourth Tuesday of every month. | Informs you of the percentage of eligible devices that were patched during the release. |
@ -56,10 +58,10 @@ If you don't want to receive standard communications for Windows Updates release
The most common type of communication during a release is a customer advisory. Customer advisories are posted to both Message center and the Messages blade of the [Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431) shortly after Autopatch becomes aware of the new information.
There are some circumstances where Autopatch will need to change the release schedule based on new information.
There are some circumstances where Autopatch needs to change the release schedule based on new information.
For example, new threat intelligence may require us to expedite a release, or we may pause due to user experience concerns. If the schedule of a quality update is changed, paused, resumed, or expedited, we'll inform you as quickly as possible so that you can adapt to the new information.
For example, new threat intelligence might require us to expedite a release, or we might pause due to user experience concerns. If the schedule of a quality update is changed, paused, resumed, or expedited, we inform you as quickly as possible so that you can adapt to the new information.
## Incident communications
Despite the best intentions, every service should plan for failure and success. When there's an incident, timely and transparent communication is key to building and maintaining your trust. If insufficient numbers of devices have been updated to meet the service level objective, devices will experience an interruption to productivity, and an incident will be raised. Microsoft will update the status of the incident at least once every 24 hours.
Despite the best intentions, every service should plan for failure and success. When there's an incident, timely and transparent communication is key to building and maintaining your trust. If insufficient numbers of devices are updated to meet the service level objective, devices experience an interruption to productivity, and an incident are raised. Microsoft updates the status of the incident at least once every 24 hours.

41
windows/deployment/windows-autopatch/manage/windows-autopatch-windows-quality-update-end-user-exp.md
View File

@ -1,7 +1,7 @@
---
title: Windows quality update end user experience
description: This article explains the Windows quality update end user experience
ms.date: 07/08/2024
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: conceptual
@ -17,9 +17,11 @@ ms.collection:
# Windows quality update end user experience
[!INCLUDE [windows-autopatch-applies-to-all-licenses](../includes/windows-autopatch-applies-to-all-licenses.md)]
## User notifications
In this section we'll review what an end user would see in the following three scenarios:
In this section we review what an end user would see in the following three scenarios:
1. Typical update experience
2. Quality update deadline forces an update
@ -30,15 +32,15 @@ In this section we'll review what an end user would see in the following three s
### Typical update experience
The Windows quality update is published and devices in the Broad ring have a deferral period of nine days. Devices will wait nine days before downloading the latest quality update.
The Windows quality update is published and devices in the Broad ring have a deferral period of nine days. Devices wait nine days before downloading the latest quality update.
Once the deferral period has passed, the device will download the update and notify the end user that updates are ready to install. The end user can either:
In the following example, the user:
- Restart immediately to install the updates
- Schedule the installation, or
- Snooze the device will attempt to install outside of [active hours](/windows/client-management/mdm/policy-csp-update#activehoursstart).
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.
| Day | Description |
| --- | --- |
| Day 0 | The Windows quality update is published. |
| Day 7 | The deferral period expires.<p>Once the deferral period passes, the device downloads the update and notifies the end user that updates are ready to install.</p><p>The end user can either:<ul><li>Restart immediately to install the updates</li><li>Schedule the installation, or</li><li>Snooze the device attempts to install outside of active hours.</li></ul></p><p>In this example, the user schedules the restart and is notified 15 minutes before the scheduled restart time. The user can reschedule, if necessary, but isn't able to reschedule past the deadline.</p> |
| Day 10 | Windows quality update deadline. The end user must download the update and restart their device. |
:::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":::
@ -46,24 +48,27 @@ In the following example, the user schedules the restart and is notified 15 minu
In the following example, the user:
- Ignores the notification and selects snooze.
- Further notifications are received, which the user ignores.
- The device is unable to install the updates outside of active hours.
The deadline specified in the update policy is five days. Therefore, once this deadline is passed, the device will ignore the [active hours](/windows/client-management/mdm/policy-csp-update#activehoursstart) 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.
| Day | Description |
| --- | --- |
| Day 0 | The Windows quality update is published. |
| Day 7-9 | The deferral period expires.<p><ul><li>Ignores the notification and selects snooze.</li><li>Further notifications are received, which the user ignores.</li><li>The device is unable to install the updates outside of active hours.</li></ul></p> |
| Day 10 | Windows quality update deadline.<p>The deadline specified in the update policy is five days. Therefore, once this deadline is passed, the device ignores the [active hours](/windows/client-management/mdm/policy-csp-update#activehoursstart) 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.</p> |
:::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
In the following example, the user is on holiday and the device is offline beyond the quality update deadline. The user then returns to work and the device is turned back on.
In the following example, the user:
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.
| Day | Description |
| --- | --- |
| Day 0-13 | While the user is on holiday and the device is offline:<ul><li>The Windows quality update is published.</li><li>The deferral period expires.</li><li>The deadline expires.</li></ul> |
| Day 14 |<ul><li>Grace period starts. Since the deadline passed, the device is granted a two-day grace period to install the update and restart.</li><li>The user returns to work and the device is turned back on.</li></ul> |
| Day 15 | The user is notified of a pending installation and given the following options:<ul><li>Pick a time</li><li>Remind me later</li><li>Restart now</li></ul>|
| Day 16 | Grace period expires.<p>Once the two-day grace period expired, the user is forced to restart with a 15-minute warning notification.</p> |
:::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":::
## Minimize user disruption due to updates
Windows Autopatch understands the importance of not disrupting end users but also updating the devices quickly. To achieve this goal, updates are automatically downloaded and installed at an optimal time determined by the device. By default, [Active hours](/windows/client-management/mdm/policy-csp-update#activehoursstart) are configured dynamically based on device usage patterns. Device restarts occur outside of active hours until the deadline is reached.
Windows Autopatch understands the importance of not disrupting critical devices but also updating the devices quickly. If you wish to configure a specific installation time or [Active hours](/windows/client-management/mdm/policy-csp-update#activehoursstart), use the [Customize Windows Update settings](../operate/windows-autopatch-groups-windows-update.md), and select the [**ScheduledInstall**](../operate/windows-autopatch-groups-windows-update.md#scheduled-install) option. Using this option removes the deadline enforced for a device restart. Devices with this configuration will also **not** be counted towards the [service level objective](../operate/windows-autopatch-groups-windows-quality-update-overview.md#service-level-objective).

159
windows/deployment/windows-autopatch/manage/windows-autopatch-windows-quality-update-overview.md
View File

@ -1,7 +1,7 @@
---
title: Windows quality updates overview with Autopatch groups experience
description: This article explains how Windows quality updates are managed with Autopatch
ms.date: 05/24/2024
title: Windows quality updates overview
description: This article explains how Windows quality updates are managed
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: conceptual
@ -17,26 +17,19 @@ ms.collection:
# Windows quality updates
Windows Autopatch deploys the [Monthly security update releases](https://techcommunity.microsoft.com/t5/windows-it-pro-blog/windows-quality-updates-primer/ba-p/2569385) that are released on the second Tuesday of each month.
You can manage Windows quality update profiles for Windows 10 and later devices. You can expedite a specific Windows quality update using targeted policies.
To release updates to devices in a gradual manner, Windows Autopatch deploys a set of mobile device management (MDM) policies to each update deployment ring to control the rollout. There are three primary policies that are used to control Windows quality updates:
| Policy | Description |
| ----- | ----- |
| [Deferrals](/windows/client-management/mdm/policy-csp-update#update-deferqualityupdatesperiodindays) | Deferral policies delay the time the update is offered to the device by a specific number of days. The "offer" date for Windows quality updates is equal to the number of days specified in the deferral policy after the second Tuesday of each month. |
| [Deadlines](/windows/client-management/mdm/policy-csp-update#update-autorestartdeadlineperiodindays) | Before the deadline, users can schedule restarts or automatically scheduled outside of active hours. After the deadline passes, restarts will occur regardless of active hours and users won't be able to reschedule. The deadline for a specific device is set to be the specified number of days after the update is offered to the device. |
| [Grace periods](/windows/client-management/mdm/policy-csp-update#update-configuredeadlinegraceperiod) | This policy specifies a minimum number of days after an update is downloaded until the device is automatically restarted. This policy overrides the deadline policy so that if a user comes back from vacation, it prevents the device from forcing a restart to complete the update as soon as it comes online. |
For devices in the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md#about-the-default-autopatch-group), Windows Autopatch configures these policies differently across deployment rings to gradually release the update. Devices in the Test ring receive changes first and devices in the Last ring receive changes last. For more information about the Test and Last deployment rings, see [About the Test and Last deployment rings in Autopatch groups](../deploy/windows-autopatch-groups-overview.md#about-the-test-and-last-deployment-rings). With Windows Autopatch groups, you can also customize the [Default Deployment Group's deployment ring composition](../deploy/windows-autopatch-groups-overview.md#default-deployment-ring-composition) to add and/or remove deployment rings and can customize the update deployment cadences for each deployment ring. To learn more about customizing Windows Quality updates deployment cadence, see [Customize Windows Update settings](../operate/windows-autopatch-groups-windows-update.md).
> [!IMPORTANT]
> Deploying deferral, deadline, or grace period policies which conflict with Autopatch's policies will cause a device to be considered ineligible for management, it will still receive policies from Windows Autopatch that are not in conflict, but may not function as designed. These devices will be marked as ineligible in our device reporting and will not count towards our [service level objective](#service-level-objective).
For more information about how to expedite quality update for Windows 10 or later in Microsoft Intune, see [Use Intune to expedite Windows quality updates](/mem/intune/protect/windows-10-expedite-updates).
## Service level objective
Windows Autopatch aims to keep at least 95% of [Up to Date devices](../operate/windows-autopatch-groups-windows-quality-and-feature-update-reports-overview.md#up-to-date-devices) on the latest quality update. Autopatch uses the previously defined release schedule on a per ring basis with a five-day reporting period to calculate and evaluate the service level objective (SLO). The result of the service level objective is the column "% with the latest quality update" displayed in release management and reporting.
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
### Service level objective calculation
Windows Autopatch aims to keep at least 95% of [Up to Date devices](../monitor/windows-autopatch-windows-quality-and-feature-update-reports-overview.md#up-to-date-devices) on the latest quality update. Autopatch uses the previously defined release schedule on a per ring basis with a five-day reporting period to calculate and evaluate the service level objective (SLO). The result of the service level objective is the column "% with the latest quality update" displayed in the Windows updates blade and reporting.
## Service level objective calculation
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
There are two states a device can be in when calculating the service level objective (SLO):
@ -61,135 +54,41 @@ The service level objective for each of these states is calculated as:
> Targeted deployment ring refers to the deployment ring value of the device in question. If a device has a five day deferral with a two day deadline, and two day grace period, the SLO for the device would be calculated to `5 + 2 + 5 = 12`-day service level objective from the second Tuesday of the month. The five day reporting period is one established by Windows Autopatch to allow enough time for device check-in reporting and data evaluation within the service.
> [!IMPORTANT]
> Windows Autopatch supports registering [Windows 10 Long-Term Servicing Channel (LTSC)](/windows/whats-new/ltsc/) devices that are being currently serviced by the [Windows LTSC](/windows/release-health/release-information). The service only supports managing the [Windows quality updates](../operate/windows-autopatch-windows-quality-update-overview.md) workload for devices currently serviced by the LTSC. Windows Update for Business service and Windows Autopatch don't offer Windows feature updates for devices that are part of the LTSC. You must either use [LTSC media](https://www.microsoft.com/evalcenter/evaluate-windows-10-enterprise) or the [Configuration Manager operating system deployment capabilities to perform an in-place upgrade](/mem/configmgr/osd/deploy-use/upgrade-windows-to-the-latest-version) for Windows devices that are part of the LTSC.
> Windows Autopatch supports registering [Windows 10 Long-Term Servicing Channel (LTSC)](/windows/whats-new/ltsc/) devices that are being currently serviced by the [Windows LTSC](/windows/release-health/release-information). The service only supports managing the [Windows quality updates](../operate/windows-autopatch-windows-quality-update-overview.md) workload for devices currently serviced by the LTSC. Windows Update for Business service and Windows Autopatch don't offer Windows feature updates for devices that are part of the LTSC. You must either use [LTSC media](https://www.microsoft.com/evalcenter/evaluate-windows-10-enterprise) or the [Configuration Manager Operating System Deployment capabilities to perform an in-place upgrade](/windows/deployment/deploy-windows-cm/upgrade-to-windows-10-with-configuration-manager) for Windows devices that are part of the LTSC.
## Import Update rings for Windows 10 and later
## Out of Band releases
You can import your organization's existing Intune Update rings for Windows 10 and later into Windows Autopatch. Importing your organization's Update rings provides the benefits of the Windows Autopatch's reporting and device readiness without the need to redeploy, or change your organization's existing update rings.
Imported rings automatically register all targeted devices into Windows Autopatch. For more information about device registration, see the [device registration workflow diagram](../deploy/windows-autopatch-device-registration-overview.md#detailed-device-registration-workflow-diagram).
> [!NOTE]
> Devices which are registered as part of an imported ring, might take up to 72 hours after the devices have received the latest version of the policy, to be reflected in Windows Autopatch devices blade and reporting. For more information about reporting, see [Windows quality and feature update reports overview](../operate/windows-autopatch-groups-windows-quality-and-feature-update-reports-overview.md).
> [!NOTE]
> Device registration failures don't affect your existing update schedule or targeting. However, devices that fail to register might affect Windows Autopatch's ability to provide reporting and insights. Any conflicts should be resolved as needed. For additional assistance, [submit a support request](../operate/windows-autopatch-support-request.md).
### To import Update rings for Windows 10 and later
**To import Update rings for Windows 10 and later:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
2. Select **Devices** from the left navigation menu.
3. Under the **Windows Autopatch** section, select **Release management**.
4. In the **Release management** blade, go to the **Release schedule** tab and select **Windows quality updates**.
5. Select **Import Update rings for Windows 10 and later**.
6. Select the existing rings you would like to import.
7. Select **Import**.
### Remove an imported Update ring for Windows 10 and later
**To remove an Imported Update rings for Windows 10 and later:**
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
2. Select **Devices** from the left navigation menu.
3. Under the **Windows Autopatch** section, select **Release management**.
4. In the **Release management** blade, go to the **Release schedule** tab and select **Windows quality updates**.
5. Select the Update rings for Windows 10 and later you would like to remove.
6. Select the **horizontal ellipses (...)** and select **Remove**.
### Known limitations
The following Windows Autopatch features aren't available with imported Intune Update rings:
- Autopatch groups and features dependent on Autopatch groups
- Moving devices in between deployment rings in devices
- Automated deployment ring remediation functions
- Policy health and remediation
## Release management
> [!NOTE]
> To access the Release management blade, you must have the correct [role-based access control](../deploy/windows-autopatch-register-devices.md#built-in-roles-required-for-device-registration).
In the Release management blade, you can:
- Track the [Windows quality update schedule](#release-schedule).
- [Turn off expedited Windows quality updates](#turn-off-service-driven-expedited-quality-update-releases).
- Review release announcements and knowledge based articles for regular and [Out of Band (OOB) Windows quality updates](#out-of-band-releases).
### Release schedule
For each deployment ring, the **Release schedule** tab contains:
- The status of the update. Releases appear as **Active**. The update schedule is based on the values of the [Windows 10 Update Ring policies](/mem/intune/protect/windows-update-for-business-configure), which are configured on your behalf.
- The date the update is available.
- The target completion date of the update.
- In the **Release schedule** tab, you can either [**Pause** and/or **Resume**](#pause-and-resume-a-release) a Windows quality update release.
### Expedited releases
Threat and vulnerability information about a new revision of Windows becomes available on the second Tuesday of each month. Windows Autopatch assesses that information shortly afterwards. If the service determines that it's critical to security, it might be expedited. The quality update is also evaluated on an ongoing basis throughout the release and Windows Autopatch might choose to expedite at any time during the release.
When expediting a release, the regular goal of 95% of devices in 21 days no longer applies. Instead, Windows Autopatch greatly accelerates the release schedule of the release to update the environment more quickly. This approach requires an updated schedule for all devices outside of the Test ring since those devices are already getting the update quickly.
| Release type | Group | Deferral | Deadline | Grace period |
| ----- | ----- | ----- | ----- | ----- |
| Expedited release | All devices | 0 | 1 | 1 |
#### Turn off service-driven expedited quality update releases
Windows Autopatch provides the option to turn off of service-driven expedited quality updates.
By default, the service expedites quality updates as needed. For those organizations seeking greater control, you can disable expedited quality updates for Windows Autopatch-enrolled devices using Microsoft Intune.
**To turn off service-driven expedited quality updates:**
1. Go to **[Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431)** > **Devices**.
2. Under **Windows Autopatch** > **Release management**, go to the **Release settings** tab and turn off the **Expedited quality updates** setting.
> [!NOTE]
> Windows Autopatch doesn't allow customers to request expedited releases.
### Out of Band releases
[!INCLUDE [windows-autopatch-applies-to-all-licenses](../includes/windows-autopatch-applies-to-all-licenses.md)]
Windows Autopatch schedules and deploys required Out of Band (OOB) updates released outside of the normal schedule.
For the deployment rings that have passed quality updates deferral date, the OOB release schedule is expedited and deployed on the same day. For the deployment rings that have deferral upcoming, OOBs is released as per the set deferral dates.
For the deployment rings that pass quality updates deferral date, the OOB release schedule is expedited and deployed on the same day. For the deployment rings that have deferral upcoming, OOBs are released as per the set deferral dates.
**To view deployed Out of Band quality updates:**
1. Go to [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431) > **Devices** > **Windows Autopatch** > **Release management**.
2. Under the **Release Announcements** tab, you can view the knowledge base (KB) articles corresponding to deployed OOB and regular Windows quality updates. You can also view the schedules for OOB update releases in the Release Schedule tab.
> [!NOTE]
> Announcements and OOB update schedules will be **removed** from the Release announcements tab when the next quality update is released. Further, if quality updates are paused for a deployment ring, the OOB updates will also be paused.
### Pause and resume a release
> [!CAUTION]
> You should only pause and resume [Windows quality](#pause-and-resume-a-release) and [Windows feature updates](../operate/windows-autopatch-groups-manage-windows-feature-update-release.md#pause-and-resume-a-release) on Windows Autopatch managed devices using the Windows Autopatch Release management blade. Do **not** use the Microsoft Intune end-user experience flows to pause or resume Windows Autopatch managed devices.
## Pause and resume a release
The service-level pause is driven by the various software update deployment-related signals Windows Autopatch receives from Windows Update for Business, and several other product groups within Microsoft.
If Windows Autopatch detects a [significant issue with a release](../operate/windows-autopatch-groups-windows-quality-update-signals.md), we might decide to pause that release.
If Windows Autopatch detects a significant issue with a release, we might decide to pause that release.
> [!IMPORTANT]
> Pausing or resuming an update can take up to eight hours to be applied to devices. Windows Autopatch uses Microsoft Intune as its device management solution and that's the average frequency Windows devices take to communicate back to Microsoft Intune with new instructions to pause, resume or rollback updates.<p>For more information, see [how long does it take for devices to get a policy, profile, or app after they are assigned from Microsoft Intune](/mem/intune/configuration/device-profile-troubleshoot#how-long-does-it-take-for-devices-to-get-a-policy-profile-or-app-after-they-are-assigned).</p>
> **Pausing or resuming an update can take up to eight hours to be applied to devices**. Windows Autopatch uses Microsoft Intune as its device management solution and that's the average frequency Windows devices take to communicate back to Microsoft Intune with new instructions to pause, resume or rollback updates.<p>For more information, see [how long does it take for devices to get a policy, profile, or app after they are assigned from Microsoft Intune](/mem/intune/configuration/device-profile-troubleshoot#how-long-does-it-take-for-devices-to-get-a-policy-profile-or-app-after-they-are-assigned).</p>
**To pause or resume a Windows quality update:**
**To pause and resume a release:**
> [!IMPORTANT]
> **You can only pause an Autopatch group if you have Windows Enterprise E3+ or F3 licenses (included in Microsoft 365 F3, E3, or E5) licenses and have [activated Windows Autopatch features](../overview/windows-autopatch-overview.md#windows-enterprise-e3-and-f3-licenses).**<p>[Feature activation](../prepare/windows-autopatch-feature-activation.md) is optional and at no additional cost to you if you have Windows 10/11 Enterprise E3 or E5 (included in Microsoft 365 F3, E3, or E5) licenses.</p><p>For more information, see [Licenses and entitlements](../prepare/windows-autopatch-prerequisites.md#licenses-and-entitlements). If you choose not to go through feature activation, you can still use the Windows Autopatch service for the features included in [Business premium and A3+ licenses](../overview/windows-autopatch-overview.md#business-premium-and-a3-licenses).</p>
1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** from the left navigation menu.
1. Under the **Windows Autopatch** section, select **Release management**.
1. In the **Release management** blade, go to the **Release schedule** tab and select **Windows quality updates**.
1. Select the Autopatch group or deployment ring that you want to pause or resume. Select either: **Pause** or **Resume**. Alternatively, you can select the **horizontal ellipses (...)** of the Autopatch group or deployment ring you want to pause or resume. Select, **Pause** or **Resume** from the dropdown menu.
1. Optional. Enter the justification(s) about why you're pausing or resuming the selected update.
1. Under the **Manage updates** section, select **Windows updates**.
1. In the **Windows updates** blade, select the **Quality updates** tab.
1. Select the Autopatch group or deployment ring that you want to pause or resume. Select either: **Pause** or **Resume**. Alternatively, you can select the **horizontal ellipses (...)** of the Autopatch group or deployment ring you want to pause or resume. Select, **Pause, or **Resume** from the dropdown menu.
1. Optional. Enter the justification about why you're pausing or resuming the selected update.
1. Optional. Select **This pause is related to Windows Update**. When you select this checkbox, you must provide information about how the pause is related to Windows Update.
1. If you're resuming an update, you can select one or more Autopatch groups or deployment rings.
1. Select **Pause or Resume deployment**.
The three following statuses are associated with paused quality updates:
The following statuses are associated with paused quality updates:
| Status | Description |
| ----- | ------ |
@ -198,4 +97,6 @@ The three following statuses are associated with paused quality updates:
## Remediating Not ready and/or Not up to Date devices
To ensure your devices receive Windows quality updates, Windows Autopatch provides information on how you can [remediate Windows Autopatch device alerts](../operate/windows-autopatch-device-alerts.md).
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
To ensure your devices receive Windows quality updates, Windows Autopatch provides information on how you can [remediate Windows Autopatch device alerts](../monitor/windows-autopatch-device-alerts.md).

39
windows/deployment/update/deployment-service-expedited-updates.md → windows/deployment/windows-autopatch/manage/windows-autopatch-windows-quality-update-programmatic-controls.md
View File

@ -1,12 +1,12 @@
---
title: Deploy expedited updates
titleSuffix: Windows Update for Business deployment service
description: Learn how to use Windows Update for Business deployment service to deploy expedited updates to devices in your organization.
title: Programmatic controls for expedited Windows quality updates
titleSuffix: Windows Autopatch
description: Use programmatic controls to deploy expedited Windows quality updates to devices in your organization.
ms.service: windows-client
ms.subservice: itpro-updates
ms.topic: conceptual
ms.author: mstewart
author: mestew
ms.subservice: autopatch
ms.topic: how-to
ms.author: tiaraquan
author: tiaraquan
manager: aaroncz
ms.collection:
- tier1
@ -14,10 +14,10 @@ ms.localizationpriority: medium
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
ms.date: 04/05/2024
ms.date: 09/16/2024
---
# Deploy expedited updates with Windows Update for Business deployment service
# Programmatic controls for expedited Windows quality updates
<!--7512398-->
In this article, you will:
@ -32,7 +32,8 @@ In this article, you will:
## Prerequisites
All of the [prerequisites for the Windows Update for Business deployment service](deployment-service-prerequisites.md) must be met, including ensuring that the *Update Health Tools* is installed on the clients.
All of the [Windows Autopatch prerequisites](../prepare/windows-autopatch-prerequisites.md) must be met, including ensuring that the *Update Health Tools* is installed on the clients.
- The *Update Health Tools* are installed starting with [KB4023057](https://support.microsoft.com/kb/4023057). To confirm the presence of the Update Health Tools on a device, use one of the following methods:
- Run a [readiness test for expedited updates](#readiness-test-for-expediting-updates)
- Look for the folder **C:\Program Files\Microsoft Update Health Tools** or review *Add Remove Programs* for **Microsoft Update Health Tools**.
@ -41,21 +42,21 @@ All of the [prerequisites for the Windows Update for Business deployment service
### Permissions
<!--Using include for Graph Explorer permissions-->
[!INCLUDE [Windows Update for Business deployment service permissions using Graph Explorer](./includes/wufb-deployment-graph-explorer-permissions.md)]
[!INCLUDE [Windows Autopatch permissions using Graph Explorer](../includes/windows-autopatch-graph-explorer-permissions.md)]
## Open Graph Explorer
<!--Using include for Graph Explorer sign in-->
[!INCLUDE [Graph Explorer sign in](./includes/wufb-deployment-graph-explorer.md)]
[!INCLUDE [Graph Explorer sign in](../includes/windows-autopatch-graph-explorer.md)]
## Run queries to identify devices
<!--Using include for Graph Explorer device queries-->
[!INCLUDE [Graph Explorer device queries](./includes/wufb-deployment-find-device-name-graph-explorer.md)]
[!INCLUDE [Graph Explorer device queries](../includes/windows-autopatch-find-device-name-graph-explorer.md)]
## List catalog entries for expedited updates
Each update is associated with a unique [catalog entry](/graph/api/resources/windowsupdates-catalogentry). You can query the catalog to find updates that can be expedited. The `id` returned is the **Catalog ID** and is used to create a deployment. The following query lists all security and nonsecurity<!--8891502--> quality updates that can be deployed as expedited updates by the deployment service. Using `$top=2` and ordering by `ReleaseDateTimeshows` displays the most recent updates that can be deployed as expedited.
Each update is associated with a unique [catalog entry](/graph/api/resources/windowsupdates-catalogentry). You can query the catalog to find updates that can be expedited. The `id` returned is the **Catalog ID** and is used to create a deployment. The following query lists all security and nonsecurity<!--8891502--> quality updates that can be deployed as expedited updates by Windows Autopatch. Using `$top=2` and ordering by `ReleaseDateTimeshows` displays the most recent updates that can be deployed as expedited.
```msgraph-interactive
GET https://graph.microsoft.com/beta/admin/windows/updates/catalog/entries?$filter=isof('microsoft.graph.windowsUpdates.qualityUpdateCatalogEntry') and microsoft.graph.windowsUpdates.qualityUpdateCatalogEntry/isExpeditable eq true&$orderby=releaseDateTime desc&$top=2
@ -98,7 +99,7 @@ The following truncated response displays a **Catalog ID** of `e317aa8a0455ca60
}
```
The deployment service can display more information about updates that were released on or after January 2023. Using [product revision](/graph/api/resources/windowsupdates-productrevision) gives you additional information about the updates, such as the KB numbers, and the `MajorVersion.MinorVersion.BuildNumber.UpdateBuildRevision`. Windows 10 and 11 share the same major and minor versions, but have different build numbers.
Windows Autopatch can display more information about updates that were released on or after January 2023. Using [product revision](/graph/api/resources/windowsupdates-productrevision) gives you additional information about the updates, such as the KB numbers, and the `MajorVersion.MinorVersion.BuildNumber.UpdateBuildRevision`. Windows 10 and 11 share the same major and minor versions, but have different build numbers.
<!--8092737-->
Use the following to display the product revision information for the most recent quality update:
@ -106,7 +107,6 @@ Use the following to display the product revision information for the most recen
GET https://graph.microsoft.com/beta/admin/windows/updates/catalog/entries?$expand=microsoft.graph.windowsUpdates.qualityUpdateCatalogEntry/productRevisions&$orderby=releaseDateTime desc&$top=1
```
The following truncated response displays information about KB5029244 for Windows 10, version 22H2, and KB5029263 for Windows 11, version 22H2:
```json
@ -296,7 +296,6 @@ To verify the devices were added to the audience, run the following query using
To stop an expedited deployment, DELETE the deployment. Deleting the deployment will prevent the content from being offered to devices if they haven't already received it. To resume offering the content, a new approval will need to be created.
The following example deletes the deployment with a **Deployment ID** of `de910e12-3456-7890-abcd-ef1234567890`:
```msgraph-interactive
@ -305,7 +304,7 @@ DELETE https://graph.microsoft.com/beta/admin/windows/updates/deployments/de910e
## Readiness test for expediting updates
<!--8705528-->
You can verify the readiness of clients to receive expedited updates by using [isReadinessTest](/graph/api/resources/windowsupdates-expeditesettings). Create a deployment that specifies it's an expedite readiness test, then add members to the deployment audience. The service will check to see if the clients meet the prerequisites for expediting updates. The results of the test are displayed in the [Windows Update for Business reports workbook](wufb-reports-workbook.md#quality-updates-tab). Under the **Quality updates** tab, select the **Expedite status** tile, which opens a flyout with a **Readiness** tab with the readiness test results.
You can verify the readiness of clients to receive expedited updates by using [isReadinessTest](/graph/api/resources/windowsupdates-expeditesettings). Create a deployment that specifies it's an expedite readiness test, then add members to the deployment audience. The service will check to see if the clients meet the prerequisites for expediting updates. The results of the test are displayed in the [Windows Update for Business reports workbook](/windows/deployment/update/wufb-reports-workbook#quality-updates-tab). Under the **Quality updates** tab, select the **Expedite status** tile, which opens a flyout with a **Readiness** tab with the readiness test results.
```msgraph-interactive
POST https://graph.microsoft.com/beta/admin/windows/updates/deployments
@ -330,7 +329,7 @@ content-type: application/json
}
```
The truncated response displays that **isReadinessTest** is set to `true` and gives you a **DeploymentID** of `de910e12-3456-7890-abcd-ef1234567890`. You can then [add members to the deployment audience](#add-members-to-the-deployment-audience) to have the service check that the devices meet the preresquites then review the results in the [Windows Update for Business reports workbook](wufb-reports-workbook.md#quality-updates-tab).
The truncated response displays that **isReadinessTest** is set to `true` and gives you a **DeploymentID** of `de910e12-3456-7890-abcd-ef1234567890`. You can then [add members to the deployment audience](#add-members-to-the-deployment-audience) to have the service check that the devices meet the preresquites then review the results in the [Windows Update for Business reports workbook](/windows/deployment/update/wufb-reports-workbook#quality-updates-tab).
```json
"expedite": {
@ -347,4 +346,4 @@ The truncated response displays that **isReadinessTest** is set to `true` and gi
```
<!--Using include for Update Health Tools log location-->
[!INCLUDE [Windows Update for Business deployment service permissions using Graph Explorer](./includes/wufb-deployment-update-health-tools-logs.md)]
[!INCLUDE [Windows Autopatch Update Health Tools](../includes/windows-autopatch-update-health-tools-logs.md)]

75
windows/deployment/windows-autopatch/manage/windows-autopatch-windows-update-policies.md
View File

@ -1,7 +1,7 @@
---
title: Windows update policies
description: This article explains Windows update policies in Windows Autopatch
ms.date: 07/08/2024
title: Windows quality update policies
description: This article explains Windows quality update policies in Windows Autopatch
ms.date: 09/16/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: concept-article
@ -14,70 +14,9 @@ ms.collection:
- tier2
---
# Windows update policies
# Windows quality update policies
## Deployment rings for Windows 10 and later
The following policies contain settings that apply to both Windows quality and feature updates. After onboarding there will be four of these policies in your tenant with the following naming convention:
**Modern Workplace Update Policy [ring name] - [Windows Autopatch]**
### Windows 10 and later update settings
| Setting name | Test | First | Fast | Broad |
| ----- | ----- | ----- | ----- | ----- |
| Microsoft product updates | Allow | Allow | Allow | Allow |
| Windows drivers | Allow | Allow | Allow | Allow |
| Windows quality update deferral period | 0 | 1 | 6 | 9 |
| Windows feature update deferral period | 0 | 0 | 0 | 0 |
| Upgrade Windows 10 to latest Windows 11 release | No | No | No | No |
| Set Windows feature update uninstall period | 30 days | 30 days | 30 days | 30 days |
| Servicing channel | General availability | General availability | General availability | General availability |
### Windows 10 and later user experience settings
| Setting name | Test | First | Fast | Broad |
| ----- | ----- | ----- | ----- | ----- |
| Automatic update behavior | Reset to default | Reset to default | Reset to default | Reset to default |
| Restart checks | Allow | Allow | Allow | Allow |
| Option to pause updates | Disable | Disable | Disable | Disable |
| Option to check for Windows updates | Default | Default | Default | Default |
| Change notification update level | Default | Default | Default | Default |
| Deadline for Windows feature updates | 5 | 5 | 5 | 5 |
| Deadline for Windows quality updates | 0 | 2 | 2 | 5 |
| Grace period | 0 | 2 | 2 | 2 |
| Auto restart before deadline | Yes | Yes | Yes | Yes |
### Windows 10 and later assignments
| Setting name | Test | First | Fast | Broad |
| ----- | ----- | ----- | ----- | ----- |
| Included groups | Modern Workplace Devices-Windows Autopatch-Test | Modern Workplace Devices-Windows Autopatch-First | Modern Workplace Devices-Windows Autopatch-Fast | Modern Workplace Devices-Windows Autopatch-Broad |
| Excluded groups | None | None | None | None |
## Windows feature update policies
The service deploys policies using Microsoft Intune to control how Windows feature updates are deployed to devices.
### Windows feature updates for Windows 10 and later
These policies control the minimum target version of Windows that a device is meant to accept. Throughout the rest of the article, these policies are referred to as DSS policies. After onboarding, there will be four of these policies in your tenant with the following naming convention:
**Modern Workplace DSS Policy [ring name]**
#### Windows feature update deployment settings
| Setting name | Test | First | Fast | Broad |
| ----- | ----- | ----- | ----- | ----- |
| Name | Current targeted version of Windows | Current targeted version of Windows | Current targeted version of Windows | Current targeted version of Windows |
| Rollout options | Immediate start | Immediate start | Immediate start | Immediate start |
#### Windows feature update policy assignments
| Setting name | Test | First | Fast | Broad |
| ----- | ----- | ----- | ----- | ----- |
| Included groups | Modern Workplace Devices-Windows Autopatch-Test | Modern Workplace Devices-Windows Autopatch-First | Modern Workplace Devices-Windows Autopatch-Fast | Modern Workplace Devices-Windows Autopatch-Broad |
| Excluded groups | Modern Workplace - Windows 11 Pre-Release Test Devices | Modern Workplace - Windows 11 Pre-Release Test Devices | Modern Workplace - Windows 11 Pre-Release Test Devices | Modern Workplace - Windows 11 Pre-Release Test Devices |
[!INCLUDE [windows-autopatch-enterprise-e3-f3-licenses](../includes/windows-autopatch-enterprise-e3-f3-licenses.md)]
## Conflicting and unsupported policies
@ -89,8 +28,8 @@ Window Autopatch deploys mobile device management (MDM) policies to configure de
| Allowed policy | Policy CSP | Description |
| ----- | ----- | ----- |
| [Active hours start](/windows/client-management/mdm/policy-csp-update#update-activehoursstart) | Update/ActiveHoursStart | This policy controls the end of the protected window where devices won't restart.<p><p>Supported values are from zero through to 23, where zero is 12∶00AM, representing the hours of the day in local time on that device. This value can be no more than 12 hours after the time set in active hours start. |
| [Active hours end](/windows/client-management/mdm/policy-csp-update#update-activehoursend) | Update/ActiveHoursEnd | This policy controls the end of the protected window where devices won't restart.<p><p>Supported values are from zero through to 23, where zero is 12∶00AM, representing the hours of the day in local time on that device. This value can be no more than 12 hours after the time set in active hours start. |
| [Active hours start](/windows/client-management/mdm/policy-csp-update#update-activehoursstart) | Update/ActiveHoursStart | This policy controls the end of the protected window where devices don't restart.<p><p>Supported values are from zero through to 23, where zero is 12∶00AM, representing the hours of the day in local time on that device. This value can be no more than 12 hours after the time set in active hours start. |
| [Active hours end](/windows/client-management/mdm/policy-csp-update#update-activehoursend) | Update/ActiveHoursEnd | This policy controls the end of the protected window where devices don't restart.<p><p>Supported values are from zero through to 23, where zero is 12∶00AM, representing the hours of the day in local time on that device. This value can be no more than 12 hours after the time set in active hours start. |
| [Active hours max range](/windows/client-management/mdm/policy-csp-update#update-activehoursmaxrange) | Update/ActiveHoursMaxRange | Allows the IT admin to specify the max active hours range.<p><p>This value sets the maximum number of active hours from the start time. Supported values are from eight through to 18. |
### Group policy and other policy managers

Some files were not shown because too many files have changed in this diff Show More