mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 13:27:23 +00:00
style and acrolinx review
This commit is contained in:
Aaron Czechowski
parent
225aaccfd5
commit
9c4af135ff
@ -1,16 +1,16 @@
|
||||
---
|
||||
title: Declared Configuration Extensibility
|
||||
description: Learn more about Declared Configuration extensibility through native WMI providers.
|
||||
ms.date: 09/11/2023
|
||||
title: Declared configuration extensibility
|
||||
description: Learn more about declared configuration extensibility through native WMI providers.
|
||||
ms.date: 09/26/2023
|
||||
ms.topic: how-to
|
||||
---
|
||||
|
||||
# Declared Configuration Extensibility Providers
|
||||
# Declared configuration extensibility providers
|
||||
|
||||
The Declared Configuration enrollment supporting the Declared Configuration client stack, offers Extensibility through native WMI providers. This feature instantiates and interfaces with a Windows Management Instrumentation (WMI) provider that has implemented an MI interface. The interface must implement GetTargetResource, TestTargetResource, and SetTargetResource methods, and may implement any number of string properties.
|
||||
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 has implemented a management infrastructure (MI) interface. The interface must implement GetTargetResource, TestTargetResource, and SetTargetResource methods, and may implement any number of string properties.
|
||||
|
||||
> [!NOTE]
|
||||
> Only string properties are currently supported by Extensibility providers.
|
||||
> Only string properties are currently supported by extensibility providers.
|
||||
|
||||
```mof
|
||||
[static, Description ("Get resource state based on input configuration file." )]
|
||||
@ -47,14 +47,14 @@ uint32 SetTargetResource(
|
||||
);
|
||||
```
|
||||
|
||||
## Author DSC resources
|
||||
## Author desired state configuration resources
|
||||
|
||||
To create a native WMI provider, follow the steps outlined in [How to Implement an MI Provider](/previous-versions/windows/desktop/wmi_v2/how-to-implement-an-mi-provider). These steps include generating the source code for MI interface using `Convert-MofToProvider.exe` tool to generate the DLL and prepare it for placement.
|
||||
To create a native WMI provider, follow the steps outlined in [How to implement an MI provider](/previous-versions/windows/desktop/wmi_v2/how-to-implement-an-mi-provider). These steps include how to generate the source code for an MI interface using the `Convert-MofToProvider.exe` tool to generate the DLL and prepare it for placement.
|
||||
|
||||
1. Create a MOF file that defines the schema for DSC resource including parameters and methods. This file includes the required parameters for the resource.
|
||||
1. Create a MOF file that defines the schema for the desired state configuration resource including parameters and methods. This file includes the required parameters for the resource.
|
||||
2. Copy the schema MOF file along with any required files into the provider tools directory, for example: ProviderGenerationTool.
|
||||
3. Edit the required files and include the correct file names and class names.
|
||||
4. Invoke the provider generator tool to generate provider's project files.
|
||||
4. Invoke the provider generator tool to generate the provider's project files.
|
||||
5. Copy the generated files into the provider's project folder.
|
||||
6. Start the development process.
|
||||
|
||||
@ -64,7 +64,7 @@ This example provides more details about each step to demonstrate how to impleme
|
||||
|
||||
### Step 1: Create the resource schema MOF file
|
||||
|
||||
Create a sample schema MOF file used to generate the initial source code for the `MSFT_FileDirectoryConfiguration` native resource and place it in the project directory named `MSFT_FileDirectoryConfiguration`.
|
||||
Create a sample schema MOF file used to generate the initial source code for the `MSFT_FileDirectoryConfiguration` native resource. Place it in the project directory named `MSFT_FileDirectoryConfiguration`.
|
||||
|
||||
```mof
|
||||
#pragma include ("cim_schema_2.26.0.mof")
|
||||
@ -126,11 +126,11 @@ class MSFT_FileDirectoryConfiguration : OMI_BaseResource
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> - Class name and DLL file name should be the same; as defined in `Provider.DEF` file.
|
||||
> - The type qualifier, `[Key]`, on a property indicates that this property will uniquely identify the resource instance. At least one `[Key]` property is required.
|
||||
> - The `[Required]` qualifier indicates that the property is required (a value must be specified in any configuration script that uses this resource).
|
||||
> - The `[write]` qualifier indicates that this property is optional when using the custom resource in a configuration script. The `[read]` qualifier indicates that a property cannot be set by a configuration, and is for reporting purposes only.
|
||||
> - `[Values]` qualifier restricts the values that can be assigned to the property to the list of values defined in `[ValueMap]`. For more information, see [ValueMap and Value Qualifiers](/windows/win32/wmisdk/value-map).
|
||||
> - The class name and DLL file name should be the same, as defined in the `Provider.DEF` file.
|
||||
> - The type qualifier `[Key]` on a property indicates that it uniquely identifies the resource instance. At least one `[Key]` property is required.
|
||||
> - The `[Required]` qualifier indicates that the property is required. In other words, a value must be specified in any configuration script that uses this resource.
|
||||
> - The `[write]` qualifier indicates that the property is optional when using the custom resource in a configuration script. The `[read]` qualifier indicates that a property can't be set by a configuration, and is for reporting purposes only.
|
||||
> - The `[Values]` qualifier restricts the values that can be assigned to the property. Define the list of allowed values in `[ValueMap]`. For more information, see [ValueMap and value qualifiers](/windows/win32/wmisdk/value-map).
|
||||
> - Any new MOF file should include the following lines at the top of the file:
|
||||
>
|
||||
> ```mof
|
||||
@ -145,25 +145,25 @@ class MSFT_FileDirectoryConfiguration : OMI_BaseResource
|
||||
|
||||
Copy these required files and folders to the project directory you created in step 1:
|
||||
|
||||
- CIM-2.26.0
|
||||
- codegen.cmd
|
||||
- Convert-MofToProvider.exe
|
||||
- MSFT_Credential.mof
|
||||
- MSFT_DSCResource.mof
|
||||
- OMI_BaseResource.mof
|
||||
- OMI_Errors.mof
|
||||
- Provider.DEF
|
||||
- wmicodegen.dll
|
||||
- `CIM-2.26.0`
|
||||
- `codegen.cmd`
|
||||
- `Convert-MofToProvider.exe`
|
||||
- `MSFT_Credential.mof`
|
||||
- `MSFT_DSCResource.mof`
|
||||
- `OMI_BaseResource.mof`
|
||||
- `OMI_Errors.mof`
|
||||
- `Provider.DEF`
|
||||
- `wmicodegen.dll`
|
||||
|
||||
For more information on how to obtain the required files, see [How to Implement an MI Provider](/previous-versions/windows/desktop/wmi_v2/how-to-implement-an-mi-provider).
|
||||
For more information on how to obtain the required files, see [How to implement an MI provider](/previous-versions/windows/desktop/wmi_v2/how-to-implement-an-mi-provider).
|
||||
|
||||
### Step 3: Edit the required files
|
||||
|
||||
Modify the following files in the project directory:
|
||||
|
||||
- MSFT_FileDirectoryConfiguration.mof: This is the file that was created in step 1.
|
||||
- Provider.DEF: This file contains the DLL name, for example, `MSFT_FileDirectoryConfiguration.dll`.
|
||||
- codegen.cmd: This file contains the command to invoke `convert-moftoprovider.exe`.
|
||||
- `MSFT_FileDirectoryConfiguration.mof`: You created this file in step 1.
|
||||
- `Provider.DEF`: This file contains the DLL name, for example, `MSFT_FileDirectoryConfiguration.dll`.
|
||||
- `codegen.cmd`: This file contains the command to invoke `convert-moftoprovider.exe`.
|
||||
|
||||
```cmd
|
||||
"convert-moftoprovider.exe" ^
|
||||
@ -177,73 +177,75 @@ Modify the following files in the project directory:
|
||||
-OutPath temp
|
||||
```
|
||||
|
||||
### Step 4: Invoke the provider generator tool
|
||||
### Step 4: Run the provider generator tool
|
||||
|
||||
Run `codegen.cmd`, which invokes the `convert-moftoprovider.exe` command. Alternatively, you can run the command directly.
|
||||
Run `codegen.cmd`, which runs the `convert-moftoprovider.exe` command. Alternatively, you can run the command directly.
|
||||
|
||||
### Step 5: Copy generated source files
|
||||
### Step 5: Copy the generated source files
|
||||
|
||||
Copy the generated files from the `temp` folder that was specified with `-OutPath` parameter in the command from step 3 to the project directory you created in step 1.
|
||||
The command in step 3 specifies the `-OutPath` parameter, which in this example is a folder named `temp`. When you run the tool in step 4, it creates new files in this folder. Copy the generated files from this `temp` folder to the project directory. You created the project directory in step 1, which in this example is `MSFT_FileDirectoryConfiguration`.
|
||||
|
||||
> [!NOTE]
|
||||
> With each update to the schema MOF file, `codegen.cmd` script to regenerate the source files must be executed again, which overwrites the source files if they exist. To prevent this, this example uses a temporary folder. It is best to minimize the updates to the schema MOF file since the main implementation should be merged with the most recent auto-generated source files.
|
||||
> Any time you update the schema MOF file, run the `codegen.cmd` script to regenerate the source files. Rerunning the generator tool overwrites any existing the source files. To prevent this behavior, this example uses a temporary folder. Minimize updates to the schema MOF file since the main implementation should be merged with the most recent auto-generated source files.
|
||||
|
||||
### About MSFT_FileDirectoryConfiguration resource
|
||||
### About the `MSFT_FileDirectoryConfiguration` resource
|
||||
|
||||
After you run the provider generator tool, several source and header files are created, including:
|
||||
After you run the provider generator tool, it creates several source and header files:
|
||||
|
||||
- MSFT_FileDirectoryConfiguration.c
|
||||
- MSFT_FileDirectoryConfiguration.h
|
||||
- module.c
|
||||
- schema.c
|
||||
- WMIAdapter.c
|
||||
- `MSFT_FileDirectoryConfiguration.c`
|
||||
- `MSFT_FileDirectoryConfiguration.h`
|
||||
- `module.c`
|
||||
- `schema.c`
|
||||
- `WMIAdapter.c`
|
||||
|
||||
From this list, only `MSFT_FileDirectoryConfiguration.c` and `MSFT_FileDirectoryConfiguration.h` need modifications. The extension for the source files can be changed from `c` to `cpp` too (which is the case for this resource). The business logic for this resource is implemented in `MSFT_FileDirectoryConfigurationImp.cpp` and `MSFT_FileDirectoryConfigurationImp.h`. These new files are added to the MSFT_FileDirectoryConfiguration directory after the provider generator tool was invoked.
|
||||
From this list, you only need to modify `MSFT_FileDirectoryConfiguration.c` and `MSFT_FileDirectoryConfiguration.h`. You can also change the extension for the source files from `.c` to `.cpp`, which is the case for this resource. The business logic for this resource is implemented in `MSFT_FileDirectoryConfigurationImp.cpp` and `MSFT_FileDirectoryConfigurationImp.h`. These new files are added to the `MSFT_FileDirectoryConfiguration` project directory after you run the provider generator tool.
|
||||
|
||||
There are three auto-generated functions in MSFT_FileDirectoryConfiguration.cpp that must be implemented for a native DSC resource:
|
||||
For a native desired state configuration resource, you have to implement three autogenerated functions in `MSFT_FileDirectoryConfiguration.cpp`:
|
||||
|
||||
- MSFT_FileDirectoryConfiguration_Invoke_GetTargetResource
|
||||
- MSFT_FileDirectoryConfiguration_Invoke_TestTargetResource
|
||||
- MSFT_FileDirectoryConfiguration_Invoke_SetTargetResource
|
||||
- `MSFT_FileDirectoryConfiguration_Invoke_GetTargetResource`
|
||||
- `MSFT_FileDirectoryConfiguration_Invoke_TestTargetResource`
|
||||
- `MSFT_FileDirectoryConfiguration_Invoke_SetTargetResource`
|
||||
|
||||
From these three functions, only MSFT_FileDirectoryConfiguration_Invoke_GetTargetResource is required for a Get scenario. MSFT_FileDirectoryConfiguration_Invoke_TestTargetResource and MSFT_FileDirectoryConfiguration_Invoke_SetTargetResource are used when remediation is needed. Besides these three functions, there are several other auto-generated functions in MSFT_FileDirectoryConfiguration.cpp that don't need implementation for a native DSC resource and should be left as-is.
|
||||
From these three functions, only `MSFT_FileDirectoryConfiguration_Invoke_GetTargetResource` is required for a Get scenario. `MSFT_FileDirectoryConfiguration_Invoke_TestTargetResource` and `MSFT_FileDirectoryConfiguration_Invoke_SetTargetResource` are used when remediation is needed.
|
||||
|
||||
- MSFT_FileDirectoryConfiguration_Load
|
||||
- MSFT_FileDirectoryConfiguration_Unload
|
||||
- MSFT_FileDirectoryConfiguration_EnumerateInstances
|
||||
- MSFT_FileDirectoryConfiguration_GetInstance
|
||||
- MSFT_FileDirectoryConfiguration_CreateInstance
|
||||
- MSFT_FileDirectoryConfiguration_ModifyInstance
|
||||
- MSFT_FileDirectoryConfiguration_DeleteInstance
|
||||
There are several other autogenerated functions in `MSFT_FileDirectoryConfiguration.cpp` that don't need implementation for a native desired state configuration resource. You don't need to modify the following functions:
|
||||
|
||||
### About MSFT_FileDirectoryConfiguration_Invoke_GetTargetResource
|
||||
- `MSFT_FileDirectoryConfiguration_Load`
|
||||
- `MSFT_FileDirectoryConfiguration_Unload`
|
||||
- `MSFT_FileDirectoryConfiguration_EnumerateInstances`
|
||||
- `MSFT_FileDirectoryConfiguration_GetInstance`
|
||||
- `MSFT_FileDirectoryConfiguration_CreateInstance`
|
||||
- `MSFT_FileDirectoryConfiguration_ModifyInstance`
|
||||
- `MSFT_FileDirectoryConfiguration_DeleteInstance`
|
||||
|
||||
MSFT_FileDirectoryConfiguration_Invoke_GetTargetResource function performs these steps to complete its task:
|
||||
### About `MSFT_FileDirectoryConfiguration_Invoke_GetTargetResource`
|
||||
|
||||
The `MSFT_FileDirectoryConfiguration_Invoke_GetTargetResource` function does the following steps to complete its task:
|
||||
|
||||
1. Validate the input resource.
|
||||
1. Ensure the keys and required parameters are present.
|
||||
1. Create a resource instance that is used as the output of the Get method. This instance is of type **MSFT_FileDirectoryConfiguration**, which is derived from **MI_Instance**.
|
||||
1. Create a resource instance that is used as the output of the Get method. This instance is of type `MSFT_FileDirectoryConfiguration`, which is derived from `MI_Instance`.
|
||||
1. Create the output resource instance from the modified resource instance and return it to the MI client by calling these functions:
|
||||
|
||||
- MSFT_FileDirectoryConfiguration_GetTargetResource_Construct
|
||||
- MSFT_FileDirectoryConfiguration_GetTargetResource_SetPtr_OutputResource
|
||||
- MSFT_FileDirectoryConfiguration_GetTargetResource_Set_MIReturn
|
||||
- MSFT_FileDirectoryConfiguration_GetTargetResource_Post
|
||||
- MSFT_FileDirectoryConfiguration_GetTargetResource_Destruct
|
||||
- `MSFT_FileDirectoryConfiguration_GetTargetResource_Construct`
|
||||
- `MSFT_FileDirectoryConfiguration_GetTargetResource_SetPtr_OutputResource`
|
||||
- `MSFT_FileDirectoryConfiguration_GetTargetResource_Set_MIReturn`
|
||||
- `MSFT_FileDirectoryConfiguration_GetTargetResource_Post`
|
||||
- `MSFT_FileDirectoryConfiguration_GetTargetResource_Destruct`
|
||||
|
||||
1. Clean up resources, for example, free allocated memory.
|
||||
|
||||
## MI implementation references
|
||||
|
||||
- [Introducing new Management Infrastructure (MI) API](https://blogs.msdn.microsoft.com/wmi/2013/05/16/introducing-new-management-infrastructure-mi-api/)
|
||||
- [Implementing MI Provider (1) - Overview](https://blogs.msdn.microsoft.com/wmi/2013/05/08/implementing-mi-provider-1-overview/)
|
||||
- [Implementing MI Provider (2) - Define Schema](https://blogs.msdn.microsoft.com/wmi/2013/05/08/implementing-mi-provider-2-define-schema/)
|
||||
- [Implementing MI Provider (3) - Generate Code](https://blogs.msdn.microsoft.com/wmi/2013/05/11/implementing-mi-provider-3-generate-code/)
|
||||
- [Implementing MI Provider (4) - Generate Code (continue)](https://blogs.msdn.microsoft.com/wmi/2013/12/28/implementing-mi-provider-4-generate-code-continute/)
|
||||
- [Implementing MI Provider (5) - Implement](https://blogs.msdn.microsoft.com/wmi/2013/12/28/implementing-mi-provider-5-implement/)
|
||||
- [Implementing MI Provider (6) - Build, Register, and Debug](https://blogs.msdn.microsoft.com/wmi/2013/12/28/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)
|
||||
- [MI_Result Enumeration](/windows/win32/api/mi/ne-mi-mi_result)
|
||||
- [MI_Type Enumeration](/windows/win32/api/mi/ne-mi-mi_type)
|
||||
- [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)
|
||||
- [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)
|
||||
- [MI_Result enumeration (mi.h)](/windows/win32/api/mi/ne-mi-mi_result)
|
||||
- [MI_Type enumeration (mi.h)](/windows/win32/api/mi/ne-mi-mi_type)
|
||||
|
||||
@ -1,34 +1,34 @@
|
||||
---
|
||||
title: Declared Configuration protocol
|
||||
description: Learn more about using Declared Configuration protocol for desired state management of Windows devices.
|
||||
ms.date: 09/11/2023
|
||||
title: Declared configuration protocol
|
||||
description: Learn more about using declared configuration protocol for desired state management of Windows devices.
|
||||
ms.date: 09/26/2023
|
||||
ms.topic: overview
|
||||
---
|
||||
|
||||
# What is Declared Configuration protocol
|
||||
# What is the declared configuration protocol
|
||||
|
||||
The Declared Configuration protocol is based on a desired state device configuration model though it still utilizes the underlying OMA-DM and Syncml protocol. Through a dedicated OMA-DM server, it provides all the settings in a single batch through this new 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 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 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. The new 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).
|
||||
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).
|
||||
|
||||
:::image type="content" source="images/declared-configuration-model.png" alt-text="Diagram illustrating the Declared configuration model.":::
|
||||
:::image type="content" source="images/declared-configuration-model.png" alt-text="Diagram illustrating the declared configuration model.":::
|
||||
|
||||
With the new [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.
|
||||
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.
|
||||
|
||||
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 in the fact that the batches of scenario settings are processed by the client asynchronously, freeing 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 intimate knowledge of the configuration surface area of the device including the proper handling of continuous device updates affecting the configuration scenario.
|
||||
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.
|
||||
|
||||
## Declared Configuration enrollment
|
||||
## Declared configuration enrollment
|
||||
|
||||
[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 Declared Configuration dual enrollment is performed by new DMClient CSP nodes, which are listed here:
|
||||
[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:
|
||||
|
||||
- [LinkedEnrollment/Priority](mdm/dmclient-csp.md#deviceproviderprovideridlinkedenrollmentpriority)
|
||||
- [LinkedEnrollment/Priority](mdm/dmclient-csp.md#deviceproviderprovideridlinkedenrollmentpriority) <!-- should be removed in final DDF -->
|
||||
- [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)
|
||||
|
||||
Here's a SyncML example for setting **LinkedEnrolment/DiscoveryEndpoint** and triggering **LinkedEnrollment/Enroll**:
|
||||
The following SyncML example sets **LinkedEnrolment/DiscoveryEndpoint** and triggers **LinkedEnrollment/Enroll**:
|
||||
|
||||
```xml
|
||||
<SyncML xmlns="SYNCML:SYNCML1.1">
|
||||
|
||||
@ -4,7 +4,7 @@ description: Learn more about the DeclaredConfiguration CSP.
|
||||
author: vinaypamnani-msft
|
||||
manager: aaroncz
|
||||
ms.author: vinpa
|
||||
ms.date: 09/13/2023
|
||||
ms.date: 09/27/2023
|
||||
ms.localizationpriority: medium
|
||||
ms.prod: windows-client
|
||||
ms.technology: itpro-manage
|
||||
@ -20,13 +20,16 @@ ms.topic: reference
|
||||
|
||||
<!-- DeclaredConfiguration-Editable-Begin -->
|
||||
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
|
||||
The Primary MDM Management device management 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 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 intimate knowledge of client handling of configuration.
|
||||
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 new Declared Configuration device management model requires the server to deliver all the setting values to the device for the scenario configuration, in batch, asynchronously through the client Declared Configuration CSP.
|
||||
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.
|
||||
|
||||
- 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.
|
||||
|
||||
- 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.
|
||||
|
||||
- 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).
|
||||
|
||||
- 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 be processed asynchronously. The client stack then exits, returning control back to Declared Configuration service allowing the device to asynchronously process the request.
|
||||
- On the client, if there are any requests in process or completed, a [generic alert](#declared-configuration-generic-alert) is sent to the server summing up each document status, state, progress. This summation is sent on every client HTTP request to the Declared Configuration OMA-DM server.
|
||||
- The Declared Configuration server uses the 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).
|
||||
<!-- DeclaredConfiguration-Editable-End -->
|
||||
|
||||
<!-- DeclaredConfiguration-Tree-Begin -->
|
||||
@ -115,7 +118,7 @@ The following list shows the DeclaredConfiguration configuration service provide
|
||||
|
||||
<!-- Device-Host-Complete-Editable-Begin -->
|
||||
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
|
||||
The Server to Client flow of the Complete request, is the same as an Inventory request.
|
||||
The server to client flow of the **Complete** request is the same as an **Inventory** request.
|
||||
<!-- Device-Host-Complete-Editable-End -->
|
||||
|
||||
<!-- Device-Host-Complete-DFProperties-Begin -->
|
||||
@ -471,7 +474,7 @@ The Server to Client flow of the Complete request, is the same as an Inventory r
|
||||
|
||||
<!-- Device-Host-Inventory-Editable-Begin -->
|
||||
<!-- Add any additional information about this policy here. Anything outside this section will get overwritten. -->
|
||||
The Server to Client flow of the Inventory request, is the same as the Complete request.
|
||||
The server to client flow of the **Inventory** request is the same as the **Complete** request.
|
||||
<!-- Device-Host-Inventory-Editable-End -->
|
||||
|
||||
<!-- Device-Host-Inventory-DFProperties-Begin -->
|
||||
@ -892,26 +895,26 @@ This node determines whether or not to start a sync session when failed to refre
|
||||
|
||||
<!-- DeclaredConfiguration-CspMoreInfo-Begin -->
|
||||
<!-- Add any additional information about this CSP here. Anything outside this section will get overwritten. -->
|
||||
## Declared Configuration OMA URI
|
||||
## Declared configuration 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 declared configuration 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".
|
||||
- `{DocID}` is a unique identifier for the desired state of the configuration scenario. Every document must have a ID, which must be a GUID.
|
||||
- The request can be a Configuration request, Inventory or Complete.
|
||||
- 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`.
|
||||
- `{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.
|
||||
|
||||
Example URI for a Complete request: `./Device/Vendor/MSFT/DeclaredConfiguration/Host/Complete/Documents/27FEA311-68B9-4320-9FC4-296F6FDFAFE2/Document`
|
||||
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
|
||||
## DeclaredConfiguration document XML
|
||||
|
||||
The value of the leaf node Document is an XML document describing the request. The actual processing of the request pivots around the `osdefinedscenario` tag:
|
||||
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.
|
||||
- `MSFTExtensibilityMIProviderConfig`: Used to configure MI provider settings.
|
||||
- `MSFTExtensibilityMIProviderInventory`: Used to retrieve MI provider setting values.
|
||||
|
||||
The DeclaredConfiguration CSP will synchronously validate 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 to attempt the desired state configuration of the specified scenario, asynchronously, freeing up the server to do other work thus the low latency of the new 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, and to maintain it throughout its lifetime, until it's removed or modified by the server.
|
||||
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.
|
||||
|
||||
Here's an example that uses the built-in native MI provider **MSFT_FileDirectoryConfiguration** with the OS defined scenario **MSFTExtensibilityMIProviderConfig**.
|
||||
The following example uses the built-in, native MI provider `MSFT_FileDirectoryConfiguration` with the OS-defined scenario `MSFTExtensibilityMIProviderConfig`:
|
||||
|
||||
```xml
|
||||
<DeclaredConfiguration schema="1.0" context="Device" id="27FEA311-68B9-4320-9FC4-296F6FDFAFE2" checksum="99925209110918B67FE962460137AA3440AFF4DB6ABBE15C8F499682457B9999" osdefinedscenario="MSFTExtensibilityMIProviderConfig">
|
||||
@ -922,7 +925,7 @@ Here's an example that uses the built-in native MI provider **MSFT_FileDirectory
|
||||
</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 a variety of online encoders that you can use. To avoid encoding the payload, you can use [CDATA Section](http://www.w3.org/TR/REC-xml/#sec-cdata-sect) as shown in this example.
|
||||
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:
|
||||
|
||||
```xml
|
||||
<?xml version="1.0" encoding="utf-8"?>
|
||||
@ -951,48 +954,48 @@ The standard OMA-DM SyncML syntax is used to specify the DeclaredConfiguration C
|
||||
|
||||
### DeclaredConfiguration XML document tags
|
||||
|
||||
Both MSFTExtensibilityMIProviderConfig and MSFTExtensibilityMIProviderInventory OS defined scenarios require the same tags and attributes.
|
||||
Both `MSFTExtensibilityMIProviderConfig` and `MSFTExtensibilityMIProviderInventory` are OS-defined scenarios that require the same tags and attributes.
|
||||
|
||||
- `<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 Declared Configuration CSP has two URIs to allow the specification of a configuration or an inventory request.
|
||||
- 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.
|
||||
|
||||
This tag has the following attributes:
|
||||
|
||||
| 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 should be a GUID. |
|
||||
| checksum | This is the server supplied version of the document. |
|
||||
| osdefinedscenario | The named scenario that is to be configured with the given configuration data. In case of Extensibility, the scenario is either MSFTExtensibilityMIProviderConfig or MSFTExtensibilityMIProviderInventory. |
|
||||
| `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`. |
|
||||
|
||||
- `<DSC>` XML tag describes the targeted WMI provider expressed by a namespace and classname along with the values either to be applied to the device or queried by the MI provider.
|
||||
- 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. |
|
||||
| `namespace` | Specifies the targeted MI provider namespace. |
|
||||
| `classname` | The targeted MI provider. |
|
||||
|
||||
- `<Key>` XML tag describes the required parameter name and value (only need value for configuration). The name is an attribute and the value is `<Key>` content.
|
||||
- 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 a MI Provider parameter. |
|
||||
| `name` | Specifies the name of an MI provider parameter. |
|
||||
|
||||
- `<Value>` XML tag describes the non-required parameter name and value (only need value for configuration). The name is an attribute and the value is `<Value>` content.
|
||||
- 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 a MI Provider parameter. |
|
||||
| `name` | Specifies the name of an MI provider parameter. |
|
||||
|
||||
## Declared Configuration generic alert
|
||||
## Declared configuration generic alert
|
||||
|
||||
On every client response to the server's request, the client constructs a Declared Configuration alert summing up the state of each of the documents that the Windows service has processed. Here's an example 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:
|
||||
|
||||
```xml
|
||||
<Alert>
|
||||
@ -1015,7 +1018,9 @@ 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 is being processed by the client stack be it a configuration or inventory request. It describes the context of the document that specifies the scope of how the document is applied. The value should be "Device". The "state" attribute has a value of 60, which indicates that the document was processed successfully. Other state values are:
|
||||
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`.
|
||||
|
||||
The **state** attribute has a value of `60`, which indicates that the document was processed successfully. The following class defines the other state values:
|
||||
|
||||
```csharp
|
||||
enum class DCCSPURIState :unsigned long
|
||||
@ -1049,7 +1054,7 @@ enum class DCCSPURIState :unsigned long
|
||||
|
||||
## SyncML examples
|
||||
|
||||
- Retrieve the results of Configuration or Inventory Request:
|
||||
- Retrieve the results of a configuration or inventory request:
|
||||
|
||||
```xml
|
||||
<SyncML xmlns="SYNCML:SYNCML1.1">
|
||||
@ -1099,7 +1104,7 @@ enum class DCCSPURIState :unsigned long
|
||||
</Results>
|
||||
```
|
||||
|
||||
- Replace a Configuration or Inventory Request
|
||||
- Replace a configuration or inventory request
|
||||
|
||||
```xml
|
||||
<SyncML xmlns="SYNCML:SYNCML1.1">
|
||||
@ -1152,7 +1157,7 @@ enum class DCCSPURIState :unsigned long
|
||||
</Results>
|
||||
```
|
||||
|
||||
- Abandon a Configuration or Inventory Request: This results in the document being tracked but not be reapplied. The Alert has the "Abandoned" property set to 1 to indicate that the document is no longer managed by the Declared Configuration server.
|
||||
- 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">
|
||||
@ -1175,7 +1180,7 @@ enum class DCCSPURIState :unsigned long
|
||||
</SyncML>
|
||||
```
|
||||
|
||||
- Deletion of Configuration or Inventory Request: The SyncML deletion of the document will only remove the document but the Extensibility settings remain tattooed.
|
||||
- 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"?>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user