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

Merge branch 'main' into patch-8

Browse Source
This commit is contained in:
Kevin Sheehan 2024-09-25 12:50:56 -04:00 committed by GitHub
commit 21de3f0cd7
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
25 changed files with 1233 additions and 348 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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)`

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

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

@ -3,7 +3,7 @@ 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: 09/16/2024
ms.date: 09/18/2024
ms.author: mstewart
author: mestew
ms.collection:
@ -58,7 +58,7 @@ For users signing in to new PCs with work or school accounts, the following expe
The update to Microsoft Copilot to offer enterprise data protection is rolling out now.
The shift to the Microsoft 365 app as the entry point for Microsoft Copilot will align with the annual Windows 11 feature update release. 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.
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.
> [!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.

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 -->

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

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

@ -118,13 +118,8 @@
href: monitor/windows-autopatch-reliability-report.md
- name: Windows feature and quality update device alerts
href: monitor/windows-autopatch-device-alerts.md
- name: Policy health
href:
items:
- name: Policy health and remediation
href: monitor/windows-autopatch-policy-health-and-remediation.md
- name: Resolve policy conflicts
href: monitor/windows-autopatch-resolve-policy-conflicts.md
- name: Policy health and remediation
href: monitor/windows-autopatch-policy-health-and-remediation.md
- name: Maintain the Windows Autopatch environment
href: monitor/windows-autopatch-maintain-environment.md
- name: References

28
windows/deployment/windows-autopatch/includes/windows-autopatch-required-graph-api-endpoints.md Normal file
View File

@ -0,0 +1,28 @@
---
author: tiaraquan
ms.author: tiaraquan
manager: aaroncz
ms.service: windows-client
ms.subservice: autopatch
ms.topic: include
ms.date: 09/24/2024
ms.localizationpriority: medium
---
<!--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 -->
You must 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
Graph API endpoints:
- devicelistenerprod.microsoft.com
- login.windows.net
- payloadprod*.blob.core.windows.net

7
windows/deployment/windows-autopatch/manage/windows-autopatch-driver-and-firmware-update-programmatic-controls.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: 09/16/2024
ms.date: 09/24/2024
---
# Programmatic controls for drivers and firmware updates
@ -44,6 +44,11 @@ All of the [Windows Autopatch prerequisites](../prepare/windows-autopatch-fix-is
<!--Using include for Graph Explorer permissions-->
[!INCLUDE [Windows Autopath permissions using Graph Explorer](../includes/windows-autopatch-graph-explorer-permissions.md)]
### Required endpoints
<!--Using include for required Graph API endpoints-->
[!INCLUDE [windows-autopatch-required-graph-api-endpoints](../includes/windows-autopatch-required-graph-api-endpoints.md)]
## Open Graph Explorer
<!--Using include for Graph Explorer sign in-->

7
windows/deployment/windows-autopatch/manage/windows-autopatch-windows-feature-update-programmatic-controls.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: 09/16/2024
ms.date: 09/24/2024
---
# Programmatic controls for Windows feature updates
@ -48,6 +48,11 @@ All of the [Windows Autopatch prerequisites](../prepare/windows-autopatch-prereq
<!--Using include for Graph Explorer permissions-->
[!INCLUDE [Windows Autopatch permissions using Graph Explorer](../includes/windows-autopatch-graph-explorer-permissions.md)]
### Required endpoints
<!--Using include for required Graph API endpoints-->
[!INCLUDE [windows-autopatch-required-graph-api-endpoints](../includes/windows-autopatch-required-graph-api-endpoints.md)]
## Open Graph Explorer
<!--Using include for Graph Explorer sign in-->

7
windows/deployment/windows-autopatch/manage/windows-autopatch-windows-quality-update-programmatic-controls.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: 09/16/2024
ms.date: 09/24/2024
---
# Programmatic controls for expedited Windows quality updates
@ -44,6 +44,11 @@ All of the [Windows Autopatch prerequisites](../prepare/windows-autopatch-prereq
<!--Using include for Graph Explorer permissions-->
[!INCLUDE [Windows Autopatch permissions using Graph Explorer](../includes/windows-autopatch-graph-explorer-permissions.md)]
### Required endpoints
<!--Using include for required Graph API endpoints-->
[!INCLUDE [windows-autopatch-required-graph-api-endpoints](../includes/windows-autopatch-required-graph-api-endpoints.md)]
## Open Graph Explorer
<!--Using include for Graph Explorer sign in-->

2
windows/deployment/windows-autopatch/overview/windows-autopatch-overview.md
View File

@ -63,7 +63,7 @@ In addition to the features included in [Business Premium and A3+ licenses](#bus
| [Microsoft 365 Apps for enterprise updates](../manage/windows-autopatch-microsoft-365-apps-enterprise.md) | Windows Autopatch aims to keep at least 90% of eligible devices on a supported version of the Monthly Enterprise Channel (MEC). |
| [Microsoft Edge updates](../manage/windows-autopatch-edge.md) | Windows Autopatch configures eligible devices to benefit from Microsoft Edge's progressive rollouts on the Stable channel. |
| [Microsoft Teams updates](../manage/windows-autopatch-teams.md) | Windows Autopatch allows eligible devices to benefit from the standard automatic update channel. |
| Policy health |<ul><li>[Policy health and remediation](../monitor/windows-autopatch-policy-health-and-remediation.md)</li><ul><li>When Windows Autopatch detects policies in the tenant are either missing or modified that affects the service, Windows Autopatch raises alerts and detailed recommended actions to ensure healthy operation of the service.</li></ul></ul><ul><li>[Resolve policy conflicts](../monitor/windows-autopatch-resolve-policy-conflicts.md)</li><ul><li>o When the Windows Autopatch service detects policies in the tenant that conflict with a setting in another Intune device policy, this conflict is displayed. With the Resolve policy conflicts feature, you can review the policies and their settings and manually resolve these conflicts.</li></ul><ul> |
| [Policy health and remediation](../monitor/windows-autopatch-policy-health-and-remediation.md) | When Windows Autopatch detects policies in the tenant are either missing or modified that affects the service, Windows Autopatch raises alerts and detailed recommended actions to ensure healthy operation of the service. |
| Enhanced [Windows quality and feature update reports](../monitor/windows-autopatch-windows-quality-and-feature-update-reports-overview.md) and [device alerts](../monitor/windows-autopatch-device-alerts.md) | Using Windows quality and feature update reports, you can monitor and remediate Windows Autopatch managed devices that are Not up to Date and resolve any device alerts to bring Windows Autopatch managed devices back into compliance. |
| [Submit support requests](../manage/windows-autopatch-support-request.md) with the Windows Autopatch Service Engineering Team | When you activate additional Autopatch features, you can submit, manage, and edit support requests. |

6
windows/deployment/windows-autopatch/prepare/windows-autopatch-configure-network.md
View File

@ -1,7 +1,7 @@
---
title: Configure your network
description: This article details the network configurations needed for Windows Autopatch
ms.date: 09/16/2024
ms.date: 09/24/2024
ms.service: windows-client
ms.subservice: autopatch
ms.topic: how-to
@ -33,7 +33,7 @@ There are URLs from several Microsoft products that must be in the allowed list
| Microsoft service | URLs required on Allowlist |
| ----- | ----- |
| Microsoft Entra ID | [Hybrid identity required ports and protocols](/azure/active-directory/hybrid/reference-connect-ports)<p><p>[Active Directory and Active Directory Domain Services Port Requirements](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd772723(v=ws.10))</p> |
| Microsoft Intune | [Intune network configuration requirements](/intune/network-bandwidth-use)<p><p>[Network endpoints for Microsoft Intune](/mem/intune/fundamentals/intune-endpoints)</p> |
| Microsoft Intune | [Intune network configuration requirements](/mem/intune/fundamentals/network-bandwidth-use)<p><p>[Network endpoints for Microsoft Intune](/mem/intune/fundamentals/intune-endpoints)</p> |
| Windows Update for Business (WUfB) | [Windows Update for Business firewall and proxy requirements](https://support.microsoft.com/help/3084568/can-t-download-updates-from-windows-update-from-behind-a-firewall-or-p) |
#### [Windows Enterprise E3+ and F3](#tab/windows-enterprise-e3-and-f3-licenses-required-microsoft-endpoints)
@ -63,7 +63,7 @@ The following URLs must be on the allowed list of your proxy and firewall so tha
| Microsoft service | URLs required on allowlist |
| ----- | ----- |
| Windows Autopatch | <ul><li>mmdcustomer.microsoft.com</li><li>mmdls.microsoft.com</li><li>logcollection.mmd.microsoft.com</li><li>support.mmd.microsoft.com</li></ul>|
| Windows Autopatch | <ul><li>mmdcustomer.microsoft.com</li><li>mmdls.microsoft.com</li><li>logcollection.mmd.microsoft.com</li><li>support.mmd.microsoft.com</li><li>devicelistenerprod.microsoft.com</li><li>login.windows.net</li><li>payloadprod*.blob.core.windows.net</li></ul>|
## Delivery Optimization

1
windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2024.md
View File

@ -36,7 +36,6 @@ Minor corrections such as typos, style, or formatting issues aren't listed.
| Article | Description |
| ----- | ----- |
| [Reliability report](../operate/windows-autopatch-reliability-report.md) | Added the [Reliability report](../operate/windows-autopatch-reliability-report.md) feature |
| [Resolve policy conflicts](../operate/windows-autopatch-resolve-policy-conflicts.md) | Added the [Resolve policy conflicts](../operate/windows-autopatch-resolve-policy-conflicts.md) feature |
## February 2024

23
windows/deployment/windows-enterprise-e3-overview.md
View File

@ -66,7 +66,6 @@ Windows Enterprise edition has many features that are unavailable in Windows Pro
|Feature|Description|
|--- |--- |
|Credential Guard|Credential Guard uses virtualization-based security to help protect security secrets so that only privileged system software can access them. Examples of security secrets that can be protected include NTLM password hashes and Kerberos Ticket Granting Tickets. This protection helps prevent Pass-the-Hash or Pass-the-Ticket attacks.<br><br>Credential Guard has the following features:<li>**Hardware-level security** - Credential Guard uses hardware platform security features (such as Secure Boot and virtualization) to help protect derived domain credentials and other secrets.<li>**Virtualization-based security** - Windows services that access derived domain credentials and other secrets run in a virtualized, protected environment that is isolated.<li>**Improved protection against persistent threats** - Credential Guard works with other technologies (for example, Device Guard) to help provide further protection against attacks, no matter how persistent.<li>**Improved manageability** - Credential Guard can be managed through Group Policy, Windows Management Instrumentation (WMI), or Windows PowerShell.<br><br>For more information, see [Protect derived domain credentials with Credential Guard](/windows/security/identity-protection/credential-guard/credential-guard).<br><br>*Credential Guard requires <ul><li>UEFI 2.3.1 or greater with Trusted Boot</li><li>Virtualization Extensions such as Intel VT-x, AMD-V, and SLAT must be enabled</li><li>x64 version of Windows</li><li>IOMMU, such as Intel VT-d, AMD-Vi</li><li>BIOS Lockdown</li><li>TPM 2.0 recommended for device health attestation (uses software if TPM 2.0 not present)*</li></ul>|
|Device Guard|This feature is a combination of hardware and software security features that allows only trusted applications to run on a device. Even if an attacker manages to get control of the Windows kernel, they're much less likely to run executable code. Device Guard can use virtualization-based security (VBS) in Windows Enterprise edition to isolate the Code Integrity service from the Windows kernel itself. With VBS, even if malware gains access to the kernel, the effects can be severely limited, because the hypervisor can prevent the malware from executing code.<br><br>Device Guard protects in the following ways:<li>Helps protect against malware<li>Helps protect the Windows system core from vulnerability and zero-day exploits<li>Allows only trusted apps to run<br><br>For more information, see [Introduction to Device Guard](/windows/security/application-security/application-control/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control).|
|AppLocker management|This feature helps IT pros determine which applications and files users can run on a device. The applications and files that can be managed include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers.<br><br>For more information, see [AppLocker](/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview).|
|Application Virtualization (App-V)|This feature makes applications available to end users without installing the applications directly on users' devices. App-V transforms applications into centrally managed services that are never installed and don't conflict with other applications. This feature also helps ensure that applications are kept current with the latest security updates.<br><br>For more information, see [Getting started with App-V for Windows client](/microsoft-desktop-optimization-pack/app-v/appv-for-windows).|
|User Experience Virtualization (UE-V)|With this feature, user-customized Windows and application settings can be captured and stored on a centrally managed network file share.<br><br>When users sign in, their personalized settings are applied to their work session, regardless of which device or virtual desktop infrastructure (VDI) sessions they sign into.<br><br>UE-V provides the following features:<li>Specify which application and Windows settings synchronize across user devices<li>Deliver the settings anytime and anywhere users work throughout the enterprise<li>Create custom templates for line-of-business applications<li>Recover settings after hardware replacement or upgrade, or after reimaging a virtual machine to its initial state<br><br>For more information, see [User Experience Virtualization (UE-V) overview](/microsoft-desktop-optimization-pack/ue-v/uev-for-windows).|
@ -106,28 +105,6 @@ For more information about implementing Credential Guard, see the following reso
- [Security considerations for Original Equipment Manufacturers](/windows-hardware/design/device-experiences/oem-security-considerations)
- [Device Guard and Credential Guard hardware readiness tool](https://www.microsoft.com/download/details.aspx?id=53337)
### Device Guard
Now that the devices have Windows Enterprise, Device Guard can be implemented on the Windows Enterprise devices by performing the following steps:
1. **Optionally, create a signing certificate for code integrity policies**. As code integrity policies are deployed, catalog files or code integrity policies might need to be signed internally. To sign catalog files or code integrity policies internally, either a publicly issued code signing certificate (normally purchase) or an internal certificate authority (CA) is needed. If an internal CA is chosen, a code signing certificate needs to be created.
2. **Create code integrity policies from "golden" computers**. Departments or roles sometimes use distinctive or partly distinctive sets of hardware and software. In these instances, "golden" computers containing the software and hardware for these departments or roles can be set up. In this respect, creating and managing code integrity policies to align with the needs of roles or departments can be similar to managing corporate images. From each "golden" computer, a code integrity policy can be created and then decided how to manage that policy. Code integrity policies can be merged to create a broader policy or a primary policy, or each policy can be managed and deployed individually.
3. **Audit the code integrity policy and capture information about applications that are outside the policy**. Microsoft recommends using "audit mode" to carefully test each code integrity policy before enforcing it. With audit mode, no application is blocked. The policy just logs an event whenever an application outside the policy is started. Later, the policy can be expanded to allow these applications, as needed.
4. **Create a "catalog file" for unsigned line-of-business (LOB) applications**. Use the Package Inspector tool to create and sign a catalog file for the unsigned LOB applications. In later steps, the catalog file's signature can be merged into the code integrity policy so that the policy allows applications in the catalog.
5. **Capture needed policy information from the event log, and merge information into the existing policy as needed**. After a code integrity policy has been running for a time in audit mode, the event log will contain information about applications that are outside the policy. To expand the policy so that it allows for these applications, use Windows PowerShell commands to capture the needed policy information from the event log. Once the information is captured, merge that information into the existing policy. Code integrity policies can also be merged from other sources, which allow flexibility in creating the final code integrity policies.
6. **Deploy code integrity policies and catalog files**. After confirming that all the preceding steps are completed, catalog files can be deployed and the code integrity policies can be taken out of audit mode. Microsoft strongly recommends beginning this process with a test group of users. Testing provides a final quality-control validation before deploying the catalog files and code integrity policies more broadly.
7. **Enable desired hardware security features**. Hardware-based security features—also called virtualization-based security (VBS) features—strengthen the protections offered by code integrity policies.
For more information about implementing Device Guard, see:
- [Windows Defender Application Control and virtualization-based protection of code integrity](/windows/security/application-security/application-control/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control)
- [Device Guard deployment guide](/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide)
### AppLocker management

8
windows/privacy/configure-windows-diagnostic-data-in-your-organization.md
View File

@ -137,11 +137,11 @@ This approach is the most complex because it requires the following configuratio
### Data access
The principle of least privileged access guides access to Windows diagnostic data. Microsoft does not share personal data of our customers with third parties, except at the customer’s discretion or for the limited purposes described in the [Privacy Statement](https://privacy.microsoft.com/en-US/privacystatement). Microsoft may share business reports with hardware manufacturers and third-party partners that include aggregated and deidentified diagnostic data information. Data-sharing decisions are made by an internal team including privacy, legal, and data management.
The principle of least privileged access guides access to Windows diagnostic data. Microsoft does not share personal data of our customers with third parties, except at the customer’s discretion or for the limited purposes described in the [Privacy Statement](https://www.microsoft.com/privacy/privacystatement). Microsoft may share business reports with hardware manufacturers and third-party partners that include aggregated and deidentified diagnostic data information. Data-sharing decisions are made by an internal team including privacy, legal, and data management.
### Retention
Microsoft believes in and practices data minimization. We strive to gather only the info we need and to store it only for as long as it’s needed to provide a service or for analysis. For more information on how long data is retained, see the section named **Our retention of personal data** in the [Microsoft Privacy Statement](https://privacy.microsoft.com/en-US/privacystatement).
Microsoft believes in and practices data minimization. We strive to gather only the info we need and to store it only for as long as it’s needed to provide a service or for analysis. For more information on how long data is retained, see the section named **Our retention of personal data** in the [Microsoft Privacy Statement](https://www.microsoft.com/privacy/privacystatement).
## Diagnostic data settings
@ -190,7 +190,7 @@ Required diagnostic data includes:
- Operating system attributes, such as Windows edition and virtualization state
- Storage attributes, such as number of drives, type, and size
- Quality metrics that helps provide an understanding about how the Connected User Experiences and diagnostic data component is functioning, including % of uploaded events, dropped events, blocked events, and the last upload time.
- Quality metrics that help provide an understanding about how the Connected User Experiences and diagnostic data component is functioning, including % of uploaded events, dropped events, blocked events, and the last upload time.
- Quality-related information that helps Microsoft develop a basic understanding of how a device and its operating system are performing. Some examples are the device characteristics of a Connected Standby device, the number of crashes or hangs, and app state change details, such as how much processor time and memory were used, and the total uptime for an app.
@ -316,7 +316,7 @@ The Windows diagnostic data processor configuration enables you to be the contro
- The device must be joined to Azure Active Directory (can be a hybrid Azure AD join).
> [!NOTE]
> In all cases, enrollment in the Windows diagnostic data processor configuration requires a device to be joined to an Azure AD tenant. If a device isn't properly enrolled, Microsoft will act as the controller for Windows diagnostic data in accordance with the [Microsoft Privacy Statement](https://privacy.microsoft.com/privacystatement) and the [Data Protection Addendum](https://www.microsoft.com/licensing/docs/view/Microsoft-Products-and-Services-Data-Protection-Addendum-DPA) terms won't apply.
> In all cases, enrollment in the Windows diagnostic data processor configuration requires a device to be joined to an Azure AD tenant. If a device isn't properly enrolled, Microsoft will act as the controller for Windows diagnostic data in accordance with the [Microsoft Privacy Statement](https://www.microsoft.com/privacy/privacystatement) and the [Data Protection Addendum](https://www.microsoft.com/licensing/docs/view/Microsoft-Products-and-Services-Data-Protection-Addendum-DPA) terms won't apply.
For the best experience, use the most current build of any operating system specified above. Configuration functionality and availability may vary on older systems. For release information, see [Windows 10 Enterprise and Education](/lifecycle/products/windows-10-enterprise-and-education) and [Windows 11 Enterprise and Education](/lifecycle/products/windows-11-enterprise-and-education) on the Microsoft Lifecycle Policy site.

4
windows/privacy/manage-connections-from-windows-operating-system-components-to-microsoft-services.md
View File

@ -1616,7 +1616,7 @@ You can disable Teredo by using Group Policy or by using the netsh.exe command.
### <a href="" id="bkmk-wifisense"></a>23. Wi-Fi Sense
> [!IMPORTANT]
> Beginning with Windows 10, version 1803, Wi-Fi Sense is no longer available. The following section only applies to Windows 10, version 1709 and prior. Please see [Connecting to open Wi-Fi hotspots in Windows 10](https://privacy.microsoft.com/windows-10-open-wi-fi-hotspots) for more details.
> Beginning with Windows 10, version 1803, Wi-Fi Sense is no longer available. The following section only applies to Windows 10, version 1709 and prior. Please see [Connecting to open Wi-Fi hotspots in Windows 10](https://support.microsoft.com/windows/bcec4e8b-00e7-4930-d3ff-5349a3e70037) for more details.
Wi-Fi Sense automatically connects devices to known hotspots and to the wireless networks the person’s contacts have shared with them.
@ -1737,7 +1737,7 @@ In Group Policy, configure:
### <a href="" id="bkmk-spotlight"></a>25. Personalized Experiences
Personalized experiences provides features such as different background images and text on the lock screen, suggested apps, Microsoft account notifications, and Windows tips. Example features include Windows Spotlight and Start Suggestions. You can control them by using the Group Policy.
Personalized experiences provide features such as different background images and text on the lock screen, suggested apps, Microsoft account notifications, and Windows tips. Example features include Windows Spotlight and Start Suggestions. You can control them by using the Group Policy.
> [!NOTE]
> This excludes how individual experiences (e.g., Windows Spotlight) can be controlled by users in Windows Settings.

18
windows/privacy/windows-privacy-compliance-guide.md
View File

@ -35,7 +35,7 @@ Transparency is an important part of the data collection process in Windows. Com
### 1.1 Device set up experience and support for layered transparency
When setting up a device, a user can configure their privacy settings. Those privacy settings are key in determining the amount of personal data collected. For each privacy setting, the user is provided information about the setting along with the links to supporting information. This information explains what data is collected, how the data is used, and how to manage the setting after the device setup is complete. When connected to the network during this portion of setup, the user can also review the privacy statement. A brief overview of the set up experience for privacy settings is described in [Windows Insiders get first look at new privacy screen settings layout coming to Windows 10](https://blogs.windows.com/windowsexperience/2018/03/06/windows-insiders-get-first-look-new-privacy-screen-settings-layout-coming-windows-10/#uCC2bKYP8M5BqrDP.97), a blog entry on Windows Blogs.
When setting up a device, a user can configure their privacy settings. Those privacy settings are key in determining the amount of personal data collected. For each privacy setting, the user is provided information about the setting along with the links to supporting information. This information explains what data is collected, how the data is used, and how to manage the setting after the device setup is complete. When connected to the network during this portion of setup, the user can also review the privacy statement. A brief overview of the setup experience for privacy settings is described in [Windows Insiders get first look at new privacy screen settings layout coming to Windows 10](https://blogs.windows.com/windowsexperience/2018/03/06/windows-insiders-get-first-look-new-privacy-screen-settings-layout-coming-windows-10/#uCC2bKYP8M5BqrDP.97), a blog entry on Windows Blogs.
The following table provides an overview of the Windows 10 and Windows 11 privacy settings presented during the device setup experience that involve processing personal data and where to find additional information.
@ -44,11 +44,11 @@ The following table provides an overview of the Windows 10 and Windows 11 privac
| Feature/Setting | Description | Supporting content | Privacy statement |
| --- | --- | --- | --- |
| Diagnostic Data | <p>Microsoft uses diagnostic data to keep Windows secure, up to date, troubleshoot problems, and make product improvements. Regardless of what choices you make for diagnostic data collection, the device will be just as secure and will operate normally. This data is collected by Microsoft to quickly identify and address issues affecting its customers.</p><p>Diagnostic data is categorized into the following:<ul><li>**Required diagnostic data**<br />Required diagnostic data includes information about your device, its settings, capabilities, and whether it is performing properly, whether a device is ready for an update, and whether there are factors that may impede the ability to receive updates, such as low battery, limited disk space, or connectivity through a paid network. You can find out what is collected with required diagnostic data [here](./required-windows-diagnostic-data-events-and-fields-2004.md).</li><li>**Optional diagnostic data**<br />Optional diagnostic data includes more detailed information about your device and its settings, capabilities, and device health. When you choose to send optional diagnostic data, required diagnostic data will always be included. You can find out the types of optional diagnostic data collected [here](./optional-diagnostic-data.md).</li></ul></p> | [Learn more](https://support.microsoft.com/help/4468236/diagnostics-feedback-and-privacy-in-windows-10-microsoft-privacy)<br /><br />[Configure Windows diagnostic data in your organization](configure-windows-diagnostic-data-in-your-organization.md) | [Privacy Statement](https://privacy.microsoft.com/privacystatement#maindiagnosticsmodule) |
| Inking & typing | Microsoft collects optional inking and typing diagnostic data to improve the language recognition and suggestion capabilities of apps and services running on Windows. | [Learn more](https://support.microsoft.com/help/4468236/diagnostics-feedback-and-privacy-in-windows-10-microsoft-privacy) | [Privacy Statement](https://privacy.microsoft.com/privacystatement#maindiagnosticsmodule) |
| Location | Get location-based experiences like directions and weather. Let Windows and apps request your location and allow Microsoft to use your location data to improve location services. | [Learn more](https://support.microsoft.com/help/4468240/windows-10-location-service-and-privacy) |[Privacy Statement](https://privacy.microsoft.com/privacystatement#mainlocationservicesmotionsensingmodule) |
| Find my device | Use your device’s location data to help you find your device if you lose it. | [Learn more](https://support.microsoft.com/help/11579/microsoft-account-find-and-lock-lost-windows-device) | [Privacy Statement](https://privacy.microsoft.com/privacystatement#mainlocationservicesmotionsensingmodule) |
| Tailored Experiences | Let Microsoft offer you tailored experiences based on the diagnostic data you choose to send. Tailored experiences include personalized tips, ads, and recommendations to enhance Microsoft products and services for your needs. | [Learn more](https://support.microsoft.com/help/4468236/diagnostics-feedback-and-privacy-in-windows-10-microsoft-privacy) | [Privacy Statement](https://privacy.microsoft.com/privacystatement#maindiagnosticsmodule) |
| Diagnostic Data | <p>Microsoft uses diagnostic data to keep Windows secure, up to date, troubleshoot problems, and make product improvements. Regardless of what choices you make for diagnostic data collection, the device will be just as secure and will operate normally. This data is collected by Microsoft to quickly identify and address issues affecting its customers.</p><p>Diagnostic data is categorized into the following:<ul><li>**Required diagnostic data**<br />Required diagnostic data includes information about your device, its settings, capabilities, and whether it is performing properly, whether a device is ready for an update, and whether there are factors that may impede the ability to receive updates, such as low battery, limited disk space, or connectivity through a paid network. You can find out what is collected with required diagnostic data [here](./required-windows-diagnostic-data-events-and-fields-2004.md).</li><li>**Optional diagnostic data**<br />Optional diagnostic data includes more detailed information about your device and its settings, capabilities, and device health. When you choose to send optional diagnostic data, required diagnostic data will always be included. You can find out the types of optional diagnostic data collected [here](./optional-diagnostic-data.md).</li></ul></p> | [Learn more](https://support.microsoft.com/help/4468236/diagnostics-feedback-and-privacy-in-windows-10-microsoft-privacy)<br /><br />[Configure Windows diagnostic data in your organization](configure-windows-diagnostic-data-in-your-organization.md) | [Privacy Statement](https://www.microsoft.com/privacy/privacystatement#maindiagnosticsmodule) |
| Inking & typing | Microsoft collects optional inking and typing diagnostic data to improve the language recognition and suggestion capabilities of apps and services running on Windows. | [Learn more](https://support.microsoft.com/help/4468236/diagnostics-feedback-and-privacy-in-windows-10-microsoft-privacy) | [Privacy Statement](https://www.microsoft.com/privacy/privacystatement#maindiagnosticsmodule) |
| Location | Get location-based experiences like directions and weather. Let Windows and apps request your location and allow Microsoft to use your location data to improve location services. | [Learn more](https://support.microsoft.com/help/4468240/windows-10-location-service-and-privacy) |[Privacy Statement](https://www.microsoft.com/privacy/privacystatement#mainlocationservicesmotionsensingmodule) |
| Find my device | Use your device’s location data to help you find your device if you lose it. | [Learn more](https://support.microsoft.com/help/11579/microsoft-account-find-and-lock-lost-windows-device) | [Privacy Statement](https://www.microsoft.com/privacy/privacystatement#mainlocationservicesmotionsensingmodule) |
| Tailored Experiences | Let Microsoft offer you tailored experiences based on the diagnostic data you choose to send. Tailored experiences include personalized tips, ads, and recommendations to enhance Microsoft products and services for your needs. | [Learn more](https://support.microsoft.com/help/4468236/diagnostics-feedback-and-privacy-in-windows-10-microsoft-privacy) | [Privacy Statement](https://www.microsoft.com/privacy/privacystatement#maindiagnosticsmodule) |
| Advertising Id | Apps can use advertising ID to provide more personalized advertising in accordance with the privacy policy of the app provider. | [Learn more](https://support.microsoft.com/help/4459081/windows-10-general-privacy-settings) | [Privacy statement](https://support.microsoft.com/help/4459081/windows-10-general-privacy-settings) |
@ -201,7 +201,7 @@ If a user signs in to a Windows experience or app on their device with their Mic
Microsoft complies with applicable law regarding the collection, use, and retention of personal information, including its transfer across borders.
Microsoft’s [Privacy Statement](https://privacy.microsoft.com/privacystatement#mainwherewestoreandprocessdatamodule) provides details on how we store and process personal data.
The [Microsoft Privacy Statement](https://www.microsoft.com/privacy/privacystatement#mainwherewestoreandprocessdatamodule) provides details on how we store and process personal data.
## 5. Related Windows product considerations
@ -243,7 +243,7 @@ Microsoft Intune is a cloud-based endpoint management solution. It manages user
* [Microsoft Trust Center: GDPR Overview](https://www.microsoft.com/trust-center/privacy/gdpr-overview)
* [Microsoft Trust Center: Privacy at Microsoft](https://www.microsoft.com/trust-center/privacy)
* [Windows IT Pro Docs](/windows/#pivot=it-pro)
* [Microsoft Privacy Statement](https://privacy.microsoft.com/privacystatement)
* [Microsoft Privacy Statement](https://www.microsoft.com/privacy/privacystatement)
* [Manage connections from Windows operating system components to Microsoft services](manage-connections-from-windows-operating-system-components-to-microsoft-services.md)
* [Privacy at Microsoft](https://privacy.microsoft.com/privacy-report)
* [Privacy at Microsoft](https://www.microsoft.com/privacy)
* [Microsoft Service Trust Portal](https://servicetrust.microsoft.com/)

15
windows/security/hardware-security/enable-virtualization-based-protection-of-code-integrity.md
View File

@ -61,7 +61,7 @@ To apply the new policy on a domain-joined computer, either restart or run `gpup
### Use registry keys to enable memory integrity
Set the following registry keys to enable memory integrity. These keys provide exactly the same set of configuration options provided by Group Policy.
Set the following registry keys to enable memory integrity. These keys provide similar set of configuration options provided by Group Policy
> [!IMPORTANT]
>
@ -95,7 +95,7 @@ reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "EnableVirtualiza
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 1 /f
```
**To enable VBS with Secure Boot and DMA (value 3)**
**To enable VBS with Secure Boot and DMA protection (value 3)**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "RequirePlatformSecurityFeatures" /t REG_DWORD /d 3 /f
@ -131,6 +131,17 @@ reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorE
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v "Locked" /t REG_DWORD /d 1 /f
```
**To enable VBS (and memory integrity) in mandatory mode**
```console
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Mandatory" /t REG_DWORD /d 1 /f
```
The **Mandatory** setting prevents the OS loader from continuing to boot in case the Hypervisor, Secure Kernel or one of their dependent modules fails to load.
> [!IMPORTANT]
> Special care should be used before enabling this mode, since, in case of any failure of the virtualization modules, the system will refuse to boot.
**To gray out the memory integrity UI and display the message "This setting is managed by your administrator"**
```console
reg delete HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity /v "WasEnabledBy" /f

28
windows/security/operating-system-security/data-protection/personal-data-encryption/configure.md
View File

@ -2,7 +2,7 @@
title: PDE settings and configuration
description: Learn about the available options to configure Personal Data Encryption (PDE) and how to configure them via Microsoft Intune or Configuration Service Providers (CSP).
ms.topic: how-to
ms.date: 05/06/2024
ms.date: 09/24/2024
---
# PDE settings and configuration
@ -36,6 +36,21 @@ The following table lists the recommended settings to improve PDE's security.
## Configure PDE with Microsoft Intune
If you use Microsoft Intune to manage your devices, you can configure PDE using a disk encryption policy, a settings catalog policy, or a custom profile.
### Disk encryption policy
To configure devices using a [disk encryption policy](/mem/intune/protect/endpoint-security-disk-encryption-policy), go to **Endpoint security** > **Disk encryption** and select **Create policy**:
- **Platform** > **Windows**
- **Profile** > **Personal Data Encryption**
Provide a name, and select **Next**. In the **Configuration settings** page, select **Enable Personal Data Encryption** and configure the settings as needed.
Assign the policy to a group that contains as members the devices or users that you want to configure.
### Settings catalog policy
[!INCLUDE [intune-settings-catalog-1](../../../../../includes/configure/intune-settings-catalog-1.md)]
| Category | Setting name | Value |
@ -80,6 +95,17 @@ Alternatively, you can configure devices using the [Policy CSP][CSP-1] and [PDE
Once PDE is enabled, it isn't recommended to disable it. However if you need to disable PDE, you can do so using the following steps.
### Disable PDE with a disk encryption policy
To disable PDE devices using a [disk encryption policy](/mem/intune/protect/endpoint-security-disk-encryption-policy), go to **Endpoint security** > **Disk encryption** and select **Create policy**:
- **Platform** > **Windows**
- **Profile** > **Personal Data Encryption**
Provide a name, and select **Next**. In the **Configuration settings** page, select **Disable Personal Data Encryption**.
Assign the policy to a group that contains as members the devices or users that you want to configure.
### Disable PDE with a settings catalog policy in Intune
[!INCLUDE [intune-settings-catalog-1](../../../../../includes/configure/intune-settings-catalog-1.md)]

2
windows/security/operating-system-security/data-protection/personal-data-encryption/faq.yml
View File

@ -4,7 +4,7 @@ metadata:
title: Frequently asked questions for Personal Data Encryption (PDE)
description: Answers to common questions regarding Personal Data Encryption (PDE).
ms.topic: faq
ms.date: 05/06/2024
ms.date: 09/24/2024
title: Frequently asked questions for Personal Data Encryption (PDE)
summary: |

2
windows/security/operating-system-security/data-protection/personal-data-encryption/index.md
View File

@ -2,7 +2,7 @@
title: Personal Data Encryption (PDE)
description: Personal Data Encryption unlocks user encrypted files at user sign-in instead of at boot.
ms.topic: how-to
ms.date: 05/06/2024
ms.date: 09/24/2024
---
# Personal Data Encryption (PDE)