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

Refresh articles

Browse Source
This commit is contained in:
Vinay Pamnani
2023-08-08 12:38:25 -04:00
parent 6265060188
commit 34e94edec6
3 changed files with 55 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
windows/client-management/certificate-renewal-windows-mdm.md
View File

@ -8,7 +8,7 @@ ms.topic: article
ms.prod: windows-client ms.prod: windows-client
ms.technology: itpro-manage ms.technology: itpro-manage
author: vinaypamnani-msft author: vinaypamnani-msft
ms.date: 06/26/2017 ms.date: 08/08/2023
appliesto: 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 11</a>
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 10</a> - ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 10</a>
@ -16,7 +16,7 @@ appliesto:
# Certificate Renewal # Certificate Renewal
The enrolled client certificate expires after a period of use. The expiration date of the certificate is specified by the server. To ensure continuous access to enterprise applications, Windows supports a user-triggered certificate renewal process. The user is prompted to provide the current password for the corporate account. The enrollment client gets a new client certificate from the enrollment server, and deletes the old certificate. The client generates a new private/public key pair, generates a PKCS\#7 request, and signs the PKCS\#7 request with the existing certificate. In Windows, automatic MDM client certificate renewal is also supported. The enrolled client certificate expires after a period of use. The expiration date of the certificate is specified by the server. To ensure continuous access to enterprise applications, Windows supports a user-triggered certificate renewal process. The user is prompted to provide the current password for the corporate account. The enrollment client gets a new client certificate from the enrollment server, and deletes the old certificate. The client generates a new private/public key pair, generates a PKCS#7 request, and signs the PKCS#7 request with the existing certificate. In Windows, automatic MDM client certificate renewal is also supported.
> [!NOTE] > [!NOTE]
> Make sure that the EntDMID in the DMClient configuration service provider is set before the certificate renewal request is triggered. > Make sure that the EntDMID in the DMClient configuration service provider is set before the certificate renewal request is triggered.
@ -30,9 +30,9 @@ Windows supports automatic certificate renewal, also known as Renew On Behalf Of
Auto certificate renewal is the only supported MDM client certificate renewal method for the device that's enrolled using WAB authentication. Meaning, the AuthPolicy is set to Federated. It also means if the server supports WAB authentication, then the MDM certificate enrollment server MUST also support client TLS to renew the MDM client certificate. Auto certificate renewal is the only supported MDM client certificate renewal method for the device that's enrolled using WAB authentication. Meaning, the AuthPolicy is set to Federated. It also means if the server supports WAB authentication, then the MDM certificate enrollment server MUST also support client TLS to renew the MDM client certificate.
For Windows devices, during the MDM client certificate enrollment phase or during MDM management section, the enrollment server or MDM server could configure the device to support automatic MDM client certificate renewal using [CertificateStore CSP's](mdm/certificatestore-csp.md) ROBOSupport node under CertificateStore/My/WSTEP/Renew URL. For Windows devices, during the MDM client certificate enrollment phase or during MDM management section, the enrollment server or MDM server could configure the device to support automatic MDM client certificate renewal using [CertificateStore CSP's](mdm/certificatestore-csp.md) ROBOSupport node under `CertificateStore/My/WSTEP/Renew` URL.
With automatic renewal, the PKCS\#7 message content isn't b64 encoded separately. With manual certificate renewal, there's an additional b64 encoding for PKCS\#7 message content. With automatic renewal, the PKCS#7 message content isn't base64 encoded separately. With manual certificate renewal, there's an additional base64 encoding for PKCS#7 message content.
During the automatic certificate renewal process, if the root certificate isn't trusted by the device, the authentication will fail. Use one of device pre-installed root certificates, or configure the root cert over a DM session using the [CertificateStore CSP](mdm/certificatestore-csp.md). During the automatic certificate renewal process, if the root certificate isn't trusted by the device, the authentication will fail. Use one of device pre-installed root certificates, or configure the root cert over a DM session using the [CertificateStore CSP](mdm/certificatestore-csp.md).
@ -96,21 +96,21 @@ The following example shows the details of an automatic renewal request.
In Windows, the renewal period can only be set during the MDM enrollment phase. Windows supports a certificate renewal period and renewal failure retry. They're configurable by both MDM enrollment server and later by the MDM management server using CertificateStore CSP's RenewPeriod and RenewInterval nodes. The device could retry automatic certificate renewal multiple times until the certificate expires. For manual certificate renewal, the Windows device reminds the user with a dialog at every renewal retry time until the certificate is expired. In Windows, the renewal period can only be set during the MDM enrollment phase. Windows supports a certificate renewal period and renewal failure retry. They're configurable by both MDM enrollment server and later by the MDM management server using CertificateStore CSP's RenewPeriod and RenewInterval nodes. The device could retry automatic certificate renewal multiple times until the certificate expires. For manual certificate renewal, the Windows device reminds the user with a dialog at every renewal retry time until the certificate is expired.
For more information about the parameters, see the CertificateStore configuration service provider. For more information about the parameters, see the [CertificateStore configuration service provider](mdm/certificatestore-csp.md).
Unlike manual certificate renewal, the device will not do an automatic MDM client certificate renewal if the certificate is already expired. To make sure the device has enough time to automatically renew, we recommend you set a renewal period a couple months (40-60 days) before the certificate expires. And, set the renewal retry interval to every few days, like every 4-5 days instead every 7 days (weekly). This change increases the chance that the device will try to connect at different days of the week. Unlike manual certificate renewal, the device will not do an automatic MDM client certificate renewal if the certificate is already expired. To make sure the device has enough time to automatically renew, we recommend you set a renewal period a couple months (40-60 days) before the certificate expires. And, set the renewal retry interval to every few days, like every 4-5 days instead of every 7 days (weekly). This change increases the chance that the device will try to connect at different days of the week.
## Certificate renewal response ## Certificate renewal response
When RequestType is set to Renew, the web service verifies the following (in additional to initial enrollment): When RequestType is set to Renew, the web service verifies the following (in additional to initial enrollment):
- The signature of the PKCS\#7 BinarySecurityToken is correct - The signature of the PKCS#7 BinarySecurityToken is correct
- The client's certificate is in the renewal period - The client's certificate is in the renewal period
- The certificate was issued by the enrollment service - The certificate was issued by the enrollment service
- The requester is the same as the requester for initial enrollment - The requester is the same as the requester for initial enrollment
- For standard client's request, the client hasn't been blocked - For standard client's request, the client hasn't been blocked
After validation is completed, the web service retrieves the PKCS\#10 content from the PKCS\#7 BinarySecurityToken. The rest is the same as initial enrollment, except that the Provisioning XML only needs to have the new certificate issued by the CA. After validation is completed, the web service retrieves the PKCS#10 content from the PKCS#7 BinarySecurityToken. The rest is the same as initial enrollment, except that the Provisioning XML only needs to have the new certificate issued by the CA.
> [!NOTE] > [!NOTE]
> The HTTP server response must not be chunked; it must be sent as one message. > The HTTP server response must not be chunked; it must be sent as one message.
@ -120,7 +120,8 @@ The following example shows the details of a certificate renewal response.
```xml ```xml
<wap-provisioningdoc version="1.1"> <wap-provisioningdoc version="1.1">
<characteristic type="CertificateStore"> <characteristic type="CertificateStore">
<!-- Root certificate provision is only needed here if it is not in the device already --> <characteristic type="Root"> <!-- Root certificate provision is only needed here if it is not in the device already -->
<characteristic type="Root">
<characteristic type="System"> <characteristic type="System">
<characteristic type="EncodedRootCertHashInsertedHere "> <characteristic type="EncodedRootCertHashInsertedHere ">
<parm name="EncodedCertificate" value="EncodedCertInsertedHere" /> <parm name="EncodedCertificate" value="EncodedCertInsertedHere" />
@ -147,9 +148,9 @@ The following example shows the details of a certificate renewal response.
## Configuration service providers supported during MDM enrollment and certificate renewal ## Configuration service providers supported during MDM enrollment and certificate renewal
The following configuration service providers are supported during MDM enrollment and certificate renewal process. See Configuration service provider reference for detailed descriptions of each configuration service provider. The following configuration service providers are supported during MDM enrollment and certificate renewal process.
- CertificateStore - [CertificateStore](mdm/certificatestore-csp.md)
- w7 APPLICATION - [w7 APPLICATION](mdm/w7-application-csp.md)
- DMClient - [DMClient](mdm/dmclient-csp.md)
- EnterpriseAppManagement - [EnterpriseAppManagement](mdm/enterpriseappvmanagement-csp.md)

60
windows/client-management/client-tools/manage-device-installation-with-group-policy.md
View File

@ -1,9 +1,9 @@
--- ---
title: Manage Device Installation with Group Policy (Windows 10 and Windows 11) title: Manage Device Installation with Group Policy
description: Find out how to manage Device Installation Restrictions with Group Policy. description: Find out how to manage Device Installation Restrictions with Group Policy.
ms.prod: windows-client ms.prod: windows-client
author: vinaypamnani-msft author: vinaypamnani-msft
ms.date: 09/14/2021 ms.date: 08/08/2023
ms.reviewer: ms.reviewer:
manager: aaroncz manager: aaroncz
ms.author: vinpa ms.author: vinpa
@ -17,15 +17,13 @@ appliesto:
# Manage Device Installation with Group Policy # Manage Device Installation with Group Policy
## Summary
By using Windows operating systems, administrators can determine what devices can be installed on computers they manage. This guide summarizes the device installation process and demonstrates several techniques for controlling device installation by using Group Policy. By using Windows operating systems, administrators can determine what devices can be installed on computers they manage. This guide summarizes the device installation process and demonstrates several techniques for controlling device installation by using Group Policy.
## Introduction ## Introduction
### General ### General
This step-by-step guide describes how you can control device installation on the computers that you manage, including designating which devices users can and can't install. This guide applies to all Windows versions starting with RS5 (1809). The guide includes the following scenarios: This step-by-step guide describes how you can control device installation on the computers that you manage, including designating which devices users can and can't install. This guide applies to all Windows versions starting with Windows 10, version 1809. The guide includes the following scenarios:
- Prevent users from installing devices that are on a "prohibited" list. If a device isn't on the list, then the user can install it. - Prevent users from installing devices that are on a "prohibited" list. If a device isn't on the list, then the user can install it.
- Allow users to install only devices that are on an "approved" list. If a device isn't on the list, then the user can't install it. - Allow users to install only devices that are on an "approved" list. If a device isn't on the list, then the user can't install it.
@ -62,32 +60,15 @@ You can ensure that users install only those devices that your technical support
## Scenario Overview ## Scenario Overview
The scenarios presented in this guide illustrate how you can control device installation and usage on the computers that you manage. The scenarios use Group Policy on a local machine to simplify using the procedures in a lab environment. In an environment where you manage multiple client computers, you should apply these settings using Group Policy. With Group Policy deployed by Active Directory, you can apply settings to all computers that are members of a domain or an organizational unit in a domain. For more information about how to use Group Policy to manage your client computers, see Group Policy at the Microsoft Web site. The scenarios presented in this guide illustrate how you can control device installation and usage on the computers that you manage. The scenarios use Group Policy on a local machine to simplify using the procedures in a lab environment. In an environment where you manage multiple client computers, you should apply these settings using Group Policy. With Group Policy deployed by Active Directory, you can apply settings to all computers that are members of a domain or an organizational unit in a domain. For more information about how to create a Group policy object to manage your client computers, see [Create a Group Policy Object](/windows/security/operating-system-security/network-security/windows-firewall/create-a-group-policy-object).
Group Policy guides: | Scenario | Description|
|--|--|
- [Create a Group Policy Object (Windows 10) - Windows Security](/windows/security/threat-protection/windows-firewall/create-a-group-policy-object) | Scenario #1: Prevent installation of all printers | In this scenario, the administrator wants to prevent users from installing any printers. Thus is a basic scenario to introduce you to the 'prevent/allow' functionality of Device Installation policies in Group Policy. |
- [Advanced Group Policy Management - Microsoft Desktop Optimization Pack](/microsoft-desktop-optimization-pack/agpm) | Scenario #2: Prevent installation of a specific printer | In this scenario, the administrator allows standard users to install all printers while but preventing them from installing a specific one. |
| Scenario #3: Prevent installation of all printers while allowing a specific printer to be installed | In this scenario, you'll combine what you learned from both scenario #1 and scenario #2. The administrator wants to allow standard users to install only a specific printer while preventing the installation of all other printers. This scenario is a more realistic one and brings you a step farther in understanding of the Device Installation Restrictions policies. |
### Scenario #1: Prevent installation of all printers | Scenario #4: Prevent installation of a specific USB device | This scenario, although similar to scenario #2, brings another layer of complexity—how does device connectivity work in the PnP tree. The administrator wants to prevent standard users from installing a specific USB device. By the end of the scenario, you should understand the way devices are nested in layers under the PnP device connectivity tree. |
| Scenario #5: Prevent installation of all USB devices while allowing an installation of only an authorized USB thumb drive | In this scenario, combining all previous four scenarios, you'll learn how to protect a machine from all unauthorized USB devices. The administrator wants to allow users to install only a small set of authorized USB devices while preventing any other USB device from being installed. In addition, this scenario includes an explanation of how to apply the 'prevent' functionality to existing USB devices that have already been installed on the machine, and the administrator likes to prevent any farther interaction with them (blocking them all together). This scenario builds on the policies and structure we introduced in the first four scenarios and therefore it's preferred to go over them first before attempting this scenario. |
In this scenario, the administrator wants to prevent users from installing any printers. Thus is a basic scenario to introduce you to the 'prevent/allow' functionality of Device Installation policies in Group Policy.
### Scenario #2: Prevent installation of a specific printer
In this scenario, the administrator allows standard users to install all printers while but preventing them from installing a specific one.
### Scenario #3: Prevent installation of all printers while allowing a specific printer to be installed
In this scenario, you'll combine what you learned from both scenario #1 and scenario #2. The administrator wants to allow standard users to install only a specific printer while preventing the installation of all other printers. This scenario is a more realistic one and brings you a step farther in understanding of the Device Installation Restrictions policies.
### Scenario #4: Prevent installation of a specific USB device
This scenario, although similar to scenario #2, brings another layer of complexity—how does device connectivity work in the PnP tree. The administrator wants to prevent standard users from installing a specific USB device. By the end of the scenario, you should understand the way devices are nested in layers under the PnP device connectivity tree.
### Scenario #5: Prevent installation of all USB devices while allowing an installation of only an authorized USB thumb drive
In this scenario, combining all previous four scenarios, you'll learn how to protect a machine from all unauthorized USB devices. The administrator wants to allow users to install only a small set of authorized USB devices while preventing any other USB device from being installed. In addition, this scenario includes an explanation of how to apply the 'prevent' functionality to existing USB devices that have already been installed on the machine, and the administrator likes to prevent any farther interaction with them (blocking them all together). This scenario builds on the policies and structure we introduced in the first four scenarios and therefore it's preferred to go over them first before attempting this scenario.
## Technology Review ## Technology Review
@ -217,11 +198,8 @@ Some of these policies take precedence over other policies. The flowchart shown
To complete each of the scenarios, ensure you have: To complete each of the scenarios, ensure you have:
- A client computer running Windows. - A client computer running Windows.
- A USB thumb drive. The scenarios described in this guide use a USB thumb drive as the example device (also known as a "removable disk drive", "memory drive," a "flash drive," or a "keyring drive"). Most USB thumb drives don't require any manufacturer-provided drivers, and these devices work with the inbox drivers provided with the Windows build. - A USB thumb drive. The scenarios described in this guide use a USB thumb drive as the example device (also known as a "removable disk drive", "memory drive," a "flash drive," or a "keyring drive"). Most USB thumb drives don't require any manufacturer-provided drivers, and these devices work with the inbox drivers provided with the Windows build.
- A USB/network printer pre-installed on the machine. - A USB/network printer pre-installed on the machine.
- Access to the administrator account on the testing machine. The procedures in this guide require administrator privileges for most steps. - Access to the administrator account on the testing machine. The procedures in this guide require administrator privileges for most steps.
### Understanding implications of applying 'Prevent' policies retroactive ### Understanding implications of applying 'Prevent' policies retroactive
@ -353,7 +331,7 @@ Creating the policy to prevent all printers from being installed:
1. Enter the printer class GUID you found above with the curly braces: `{4d36e979-e325-11ce-bfc1-08002be10318}`. 1. Enter the printer class GUID you found above with the curly braces: `{4d36e979-e325-11ce-bfc1-08002be10318}`.
![List of prevent Class GUIDs.](images/device-installation-gpo-prevent-class-list.png)<br/>_List of prevent Class GUIDs_ ![List of prevent Class GUIDs](images/device-installation-gpo-prevent-class-list.png)<br/>_List of prevent Class GUIDs_
1. Click 'OK'. 1. Click 'OK'.
@ -364,7 +342,7 @@ Creating the policy to prevent all printers from being installed:
> [!IMPORTANT] > [!IMPORTANT]
> Using a Prevent policy (like the one we used in scenario #1 above) and applying it to all previously installed devices (see step #9) could render crucial devices unusable; hence, use with caution. For example: If an IT admin wants to prevent all removable storage devices from being installed on the machine, using 'Disk Drive' class for blocking and applying it retroactive could render the internal hard-drive unusable and to break the machine. > Using a Prevent policy (like the one we used in scenario #1 above) and applying it to all previously installed devices (see step #9) could render crucial devices unusable; hence, use with caution. For example: If an IT admin wants to prevent all removable storage devices from being installed on the machine, using 'Disk Drive' class for blocking and applying it retroactive could render the internal hard-drive unusable and to break the machine.
### Testing the scenario ### Testing scenario 1
1. If you haven't completed step #9, follow these steps: 1. If you haven't completed step #9, follow these steps:
@ -418,7 +396,7 @@ Creating the policy to prevent a single printer from being installed:
1. Optionally, if you would like to apply the policy to an existing install, open the **Prevent installation of devices that match any of these device IDs** policy again. In the 'Options' window, mark the checkbox that says 'Also apply to matching devices that are already installed'. 1. Optionally, if you would like to apply the policy to an existing install, open the **Prevent installation of devices that match any of these device IDs** policy again. In the 'Options' window, mark the checkbox that says 'Also apply to matching devices that are already installed'.
### Testing the scenario ### Testing scenario 2
If you completed step #8 above and restarted the machine, look for your printer under Device Manager or the Windows Settings app and see that it's no-longer available for you to use. If you completed step #8 above and restarted the machine, look for your printer under Device Manager or the Windows Settings app and see that it's no-longer available for you to use.
@ -469,7 +447,7 @@ First create a 'Prevent Class' policy and then create 'Allow Device' one:
1. Enter the printer class GUID you found above with the curly braces (this value is important! Otherwise, it won't work): {4d36e979-e325-11ce-bfc1-08002be10318} 1. Enter the printer class GUID you found above with the curly braces (this value is important! Otherwise, it won't work): {4d36e979-e325-11ce-bfc1-08002be10318}
![List of prevent Class GUIDs.](images/device-installation-gpo-prevent-class-list.png)<br/>_List of prevent Class GUIDs_ ![List of prevent Class IDs](images/device-installation-gpo-prevent-class-list.png)<br/>_List of prevent Class GUIDs_
1. Click 'OK'. 1. Click 'OK'.
@ -495,7 +473,7 @@ First create a 'Prevent Class' policy and then create 'Allow Device' one:
1. Click 'Apply' on the bottom right of the policy's window—this option pushes the policy and allows the target printer to be installed (or stayed installed). 1. Click 'Apply' on the bottom right of the policy's window—this option pushes the policy and allows the target printer to be installed (or stayed installed).
## Testing the scenario ## Testing scenario 3
1. Look for your printer under Device Manager or the Windows Settings app and see that it's still there and accessible. Or just print a test document. 1. Look for your printer under Device Manager or the Windows Settings app and see that it's still there and accessible. Or just print a test document.
@ -562,7 +540,7 @@ Creating the policy to prevent a single USB thumb-drive from being installed:
1. Optional - if you would like to apply the policy to an existing install, open the **Prevent installation of devices that match any of these device IDs** policy again. In the 'Options' window, mark the checkbox that says 'also apply to matching devices that are already installed'. 1. Optional - if you would like to apply the policy to an existing install, open the **Prevent installation of devices that match any of these device IDs** policy again. In the 'Options' window, mark the checkbox that says 'also apply to matching devices that are already installed'.
### Testing the scenario ### Testing scenario 4
1. If you haven't completed step #8, follow these steps: 1. If you haven't completed step #8, follow these steps:
@ -668,6 +646,6 @@ First create a 'Prevent Class' policy and then create 'Allow Device' one:
1. To apply the 'Prevent' coverage of all currently installed USB devices, open the **Prevent installation of devices using drivers that match these device setup classes** policy again; in the 'Options' window mark the checkbox that says 'also apply to matching devices that are already installed' and click 'OK'. 1. To apply the 'Prevent' coverage of all currently installed USB devices, open the **Prevent installation of devices using drivers that match these device setup classes** policy again; in the 'Options' window mark the checkbox that says 'also apply to matching devices that are already installed' and click 'OK'.
### Testing the scenario ### Testing scenario 5
You shouldn't be able to install any USB thumb-drive, except the one you authorized for usage You shouldn't be able to install any USB thumb-drive, except the one you authorized for usage.

42
windows/client-management/oma-dm-protocol-support.md
View File

@ -8,7 +8,7 @@ ms.topic: article
ms.prod: windows-client ms.prod: windows-client
ms.technology: itpro-manage ms.technology: itpro-manage
author: vinaypamnani-msft author: vinaypamnani-msft
ms.date: 06/26/2017 ms.date: 08/08/2023
appliesto: 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 11</a>
- ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 10</a> - ✅ <a href="https://learn.microsoft.com/windows/release-health/supported-versions-windows-client" target="_blank">Windows 10</a>
@ -38,26 +38,26 @@ The following table shows the OMA DM standards that Windows uses.
Common elements are used by other OMA DM element types. The following table lists the OMA DM common elements used to configure the devices. For more information about OMA DM common elements, see "SyncML Representation Protocol Device Management Usage" (OMA-SyncML-DMRepPro-V1_1_2-20030613-A) available from the [OMA website](https://www.openmobilealliance.org/release/DM/V1_1_2-20031209-A/). Common elements are used by other OMA DM element types. The following table lists the OMA DM common elements used to configure the devices. For more information about OMA DM common elements, see "SyncML Representation Protocol Device Management Usage" (OMA-SyncML-DMRepPro-V1_1_2-20030613-A) available from the [OMA website](https://www.openmobilealliance.org/release/DM/V1_1_2-20031209-A/).
|Element|Description| | Element | Description |
|--- |--- | |:--|:--|
|Chal|Specifies an authentication challenge. The server or client can send a challenge to the other if no credentials or inadequate credentials were given in the original request message.| | Chal | Specifies an authentication challenge. The server or client can send a challenge to the other if no credentials or inadequate credentials were given in the original request message. |
|Cmd|Specifies the name of an OMA DM command referenced in a Status element.| | Cmd | Specifies the name of an OMA DM command referenced in a Status element. |
|CmdID|Specifies the unique identifier for an OMA DM command.| | CmdID | Specifies the unique identifier for an OMA DM command. |
|CmdRef|Specifies the ID of the command for which status or results information is being returned. This element takes the value of the CmdID element of the corresponding request message.| | CmdRef | Specifies the ID of the command for which status or results information is being returned. This element takes the value of the CmdID element of the corresponding request message. |
|Cred|Specifies the authentication credential for the originator of the message.| | Cred | Specifies the authentication credential for the originator of the message. |
|Final|Indicates that the current message is the last message in the package.| | Final | Indicates that the current message is the last message in the package. |
|LocName|Specifies the display name in the Target and Source elements, used for sending a user ID for MD5 authentication.| | LocName | Specifies the display name in the Target and Source elements, used for sending a user ID for MD5 authentication. |
|LocURI|Specifies the address of the target or source location. If the address contains a non-alphanumeric character, it must be properly escaped according to the URL encoding standard.| | LocURI | Specifies the address of the target or source location. If the address contains a non-alphanumeric character, it must be properly escaped according to the URL encoding standard. |
|MsgID|Specifies a unique identifier for an OMA DM session message.| | MsgID | Specifies a unique identifier for an OMA DM session message. |
|MsgRef|Specifies the ID of the corresponding request message. This element takes the value of the request message MsgID element.| | MsgRef | Specifies the ID of the corresponding request message. This element takes the value of the request message MsgID element. |
|RespURI|Specifies the URI that the recipient must use when sending a response to this message.| | RespURI | Specifies the URI that the recipient must use when sending a response to this message. |
|SessionID|Specifies the identifier of the OMA DM session associated with the containing message.<div class="alert">**Note**<br> If the server doesn't notify the device that it supports a new version (through SyncApplicationVersion node in the DMClient CSP), the client returns the SessionID in integer in decimal format. If the server supports DM session sync version 2.0, which is used in Windows, the device client returns 2 bytes.</div>| | SessionID | Specifies the identifier of the OMA DM session associated with the containing message. If the server doesn't notify the device that it supports a new version (through SyncApplicationVersion node in the DMClient CSP), the client returns the SessionID in integer in decimal format. If the server supports DM session sync version 2.0, which is used in Windows, the device client returns 2 bytes. |
|Source|Specifies the message source address.| | Source | Specifies the message source address. |
|SourceRef|Specifies the source of the corresponding request message. This element takes the value of the request message Source element and is returned in the Status or Results element.| | SourceRef | Specifies the source of the corresponding request message. This element takes the value of the request message Source element and is returned in the Status or Results element. |
|Target|Specifies the address of the node, in the DM Tree, that is the target of the OMA DM command.| | Target | Specifies the address of the node, in the DM Tree, that is the target of the OMA DM command. |
|TargetRef|Specifies the target address in the corresponding request message. This element takes the value of the request message Target element and is returned in the Status or Results element.| | TargetRef | Specifies the target address in the corresponding request message. This element takes the value of the request message Target element and is returned in the Status or Results element. |
|VerDTD|Specifies the major and minor version identifier of the OMA DM representation protocol specification used to represent the message.| | VerDTD | Specifies the major and minor version identifier of the OMA DM representation protocol specification used to represent the message. |
|VerProto|Specifies the major and minor version identifier of the OMA DM protocol specification used with the message.| | VerProto | Specifies the major and minor version identifier of the OMA DM protocol specification used with the message. |
## Device management session ## Device management session