Merge pull request #2504 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to master to sync with https://github.com/MicrosoftDocs/windows-itpro-docs (branch public)
This commit is contained in:
Tina Burden
2020-04-09 11:34:56 -07:00
committed by GitHub
3 changed files with 8 additions and 1 deletions

View File

@ -45,12 +45,16 @@ Setting a null (empty) date will delete the existing schedule. In accordance wit
<p style="margin-left: 20px">The supported operations are Get, Add, Replace, and Delete.</p>
<p style="margin-left: 20px">The supported data type is "String".</p>
<a href="" id="schedule-dailyrecurrent"></a>**Schedule/DailyRecurrent**
<p style="margin-left: 20px">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. </br>
Example to configure: 2018-10-25T18:00:00</p>
<p style="margin-left: 20px">The supported operations are Get, Add, Replace, and Delete.</p>
<p style="margin-left: 20px">The supported data type is "String".</p>
## Related topics

View File

@ -175,6 +175,7 @@ Here's the XSD for the ProfileXML node in VPNv2 CSP for Windows 10 and some pro
<xs:sequence>
<xs:element name="Address" type="xs:string" minOccurs="1" maxOccurs="1"/>
<xs:element name="PrefixSize" type="xs:unsignedByte" minOccurs="1" maxOccurs="1"/>
<xs:element name="ExclusionRoute" type="xs:boolean" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>

View File

@ -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 servers 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.