diff --git a/windows/client-management/mdm/reboot-csp.md b/windows/client-management/mdm/reboot-csp.md index 70668fa9de..e7cb92b9c4 100644 --- a/windows/client-management/mdm/reboot-csp.md +++ b/windows/client-management/mdm/reboot-csp.md @@ -45,12 +45,16 @@ Setting a null (empty) date will delete the existing schedule. In accordance wit

The supported operations are Get, Add, Replace, and Delete.

+

The supported data type is "String".

+ **Schedule/DailyRecurrent**

This node will execute a reboot each day at a scheduled time starting at the configured starting time and date. Setting a null (empty) date will delete the existing schedule. The date and time value is ISO8601, and both the date and time are required. The CSP will return the date time in the following format: 2018-06-29T10:00:00+01:00.
Example to configure: 2018-10-25T18:00:00

The supported operations are Get, Add, Replace, and Delete.

+

The supported data type is "String".

+ ## Related topics diff --git a/windows/client-management/mdm/vpnv2-profile-xsd.md b/windows/client-management/mdm/vpnv2-profile-xsd.md index 1c13aa99ad..eecc7c7075 100644 --- a/windows/client-management/mdm/vpnv2-profile-xsd.md +++ b/windows/client-management/mdm/vpnv2-profile-xsd.md @@ -175,6 +175,7 @@ Here's the XSD for the ProfileXML node in VPNv2 CSP for Windows 10 and some pro + diff --git a/windows/security/information-protection/bitlocker/bitlocker-how-to-enable-network-unlock.md b/windows/security/information-protection/bitlocker/bitlocker-how-to-enable-network-unlock.md index 56c13ecbbe..a7a7e7fce7 100644 --- a/windows/security/information-protection/bitlocker/bitlocker-how-to-enable-network-unlock.md +++ b/windows/security/information-protection/bitlocker/bitlocker-how-to-enable-network-unlock.md @@ -80,7 +80,9 @@ The server side configuration to enable Network Unlock also requires provisionin 1. The Windows boot manager detects that a Network Unlock protector exists in the BitLocker configuration. 2. The client computer uses its DHCP driver in the UEFI to obtain a valid IPv4 IP address. -3. The client computer broadcasts a vendor-specific DHCP request that contains the Network Key (a 256-bit intermediate key) and an AES-256 session key for the reply. Both of these keys are encrypted using the 2048-bit RSA Public Key of the Network Unlock certificate from the WDS server. +3. The client computer broadcasts a vendor-specific DHCP request that contains: + 1. A Network Key (a 256-bit intermediate key) encrypted using the 2048-bit RSA Public Key of the Network Unlock certificate from the WDS server. + 2. An AES-256 session key for the reply. 4. The Network Unlock provider on the WDS server recognizes the vendor-specific request. 5. The provider decrypts it with the WDS server’s BitLocker Network Unlock certificate RSA private key. 6. The WDS provider then returns the network key encrypted with the session key using its own vendor-specific DHCP reply to the client computer. This forms an intermediate key.