Merge branch 'lsaldanha-5120578' of https://github.com/MicrosoftDocs/windows-docs-pr into lsaldanha-5120578

2025-05-15 06:47:21 +00:00 · 2021-05-24 10:00:53 +05:30 · 2021-05-24 10:00:53 +05:30 · 22b4089222
commit 22b4089222
parent 988b07c78c d94bba0d9b
14 changed files with 252 additions and 84602 deletions
--- a/store-for-business/add-unsigned-app-to-code-integrity-policy.md
+++ b/store-for-business/add-unsigned-app-to-code-integrity-policy.md
@ -18,12 +18,12 @@ ms.date: 03/10/2021
 # Add unsigned app to code integrity policy

 > [!IMPORTANT]
-> We are introducing a new version of the Device Guard Signing Service (DGSS) to be more automation friendly. The new version of the service (DGSS v2) is now available. As announced earlier, you will have until the end of December 2020 to transition to DGSS v2. At the end of December 2020, the existing web-based mechanisms for the current version of the DGSS service will be retired and will no longer be available for use. Please make plans to migrate to the new version of the service by the end of December 2020.
+> We are introducing a new version of the Device Guard Signing Service (DGSS) to be more automation friendly. The new version of the service (DGSS v2) is now available. As announced earlier, you will have until June 9, 2021 to transition to DGSS v2. On June 9, 2021, the existing web-based mechanisms for the current version of the DGSS service will be retired and will no longer be available for use. Please make plans to migrate to the new version of the service by June 9, 2021.
 >
 > Following are the major changes we are making to the service: 
 > - The method for consuming the service will change to a more automation-friendly method based on PowerShell cmdlets. These cmdlets are available as a NuGet download, https://www.nuget.org/packages/Microsoft.Acs.Dgss.Client/.
 > - In order to achieve desired isolation, you will be required to get a new CI policy from DGSS v2 (and optionally sign it). 
-> -	DGSS v2 will not have support for downloading leaf certificates used to sign your files (however, the root certificate will still be available to download).  Note that the certificate used to sign a file can be easily extracted from the signed file itself.  As a result, after DGSS v1 is retired at the end of December 2020, you will no longer be able to download the leaf certificates used to sign your files.
+> -	DGSS v2 will not have support for downloading leaf certificates used to sign your files (however, the root certificate will still be available to download).  Note that the certificate used to sign a file can be easily extracted from the signed file itself.  As a result, after DGSS v1 is retired, you will no longer be able to download the leaf certificates used to sign your files.
 >
 > The following functionality will be available via these PowerShell cmdlets:
 > - Get a CI policy
@ -117,4 +117,4 @@ Catalog signing is a vital step to adding your unsigned apps to your code integr
     When you use the Device Guard signing portal to sign a catalog file, the signing certificate is added to the default policy. When you download the signed catalog file, you should also download the default policy and merge this code integrity policy with your existing code integrity policies to protect machines running the catalog file. You need to do this step to trust and run your catalog files. For more information, see the Merging code integrity policies in the [Device Guard deployment guide](/windows/device-security/device-guard/device-guard-deployment-guide).

 6. Open the root certificate that you downloaded, and follow the steps in **Certificate Import wizard** to install the certificate in your machine's certificate store.
-7. Deploy signed catalogs to your managed devices. For more information, see Deploy catalog files with Group Policy, or Deploy catalog files with Microsoft Endpoint Manager in the [Device Guard deployment guide](/windows/device-security/device-guard/device-guard-deployment-guide).
+7. Deploy signed catalogs to your managed devices. For more information, see Deploy catalog files with Group Policy, or Deploy catalog files with Microsoft Endpoint Manager in the [Device Guard deployment guide](/windows/device-security/device-guard/device-guard-deployment-guide).
--- a/store-for-business/device-guard-signing-portal.md
+++ b/store-for-business/device-guard-signing-portal.md
@ -18,12 +18,12 @@ ms.date: 10/17/2017
 # Device Guard signing

 > [!IMPORTANT]
-> We are introducing a new version of the Device Guard Signing Service (DGSS) to be more automation friendly. The new version of the service (DGSS v2) is now available. As announced earlier, you will have until the end of December 2020 to transition to DGSS v2. At the end of December 2020, the existing web-based mechanisms for the current version of the DGSS service will be retired and will no longer be available for use. Please make plans to migrate to the new version of the service by the end of December 2020.
+> We are introducing a new version of the Device Guard Signing Service (DGSS) to be more automation friendly. The new version of the service (DGSS v2) is now available. As announced earlier, you will have until June 9, 2021 to transition to DGSS v2. On June 9, 2021, the existing web-based mechanisms for the current version of the DGSS service will be retired and will no longer be available for use. Please make plans to migrate to the new version of the service by June 9, 2021.
 >
 > Following are the major changes we are making to the service: 
 > - The method for consuming the service will change to a more automation-friendly method based on PowerShell cmdlets. These cmdlets are available as a NuGet download, https://www.nuget.org/packages/Microsoft.Acs.Dgss.Client/.
 > - In order to achieve desired isolation, you will be required to get a new CI policy from DGSS v2 (and optionally sign it). 
-> -	DGSS v2 will not have support for downloading leaf certificates used to sign your files (however, the root certificate will still be available to download).  Note that the certificate used to sign a file can be easily extracted from the signed file itself.  As a result, after DGSS v1 is retired at the end of December 2020, you will no longer be able to download the leaf certificates used to sign your files.
+> -	DGSS v2 will not have support for downloading leaf certificates used to sign your files (however, the root certificate will still be available to download).  Note that the certificate used to sign a file can be easily extracted from the signed file itself.  As a result, after DGSS v1 is retired, you will no longer be able to download the leaf certificates used to sign your files.
 >
 > The following functionality will be available via these PowerShell cmdlets:
 > - Get a CI policy
@ -32,7 +32,7 @@ ms.date: 10/17/2017
 > - Download root cert
 > - Download history of your signing operations 
 >
-> For any questions, please contact us at DGSSMigration@microsoft.com.  
+> For any questions, please contact us at DGSSMigration@microsoft.com. 


 **Applies to**
@ -72,4 +72,4 @@ Catalog and policy files have required files types.
 Signing code integrity policies and access to Device Guard portal requires the Device Guard signer role.

 ## Device Guard signing certificates
-All certificates generated by the Device Guard signing service are unique per customer and are independent of the Microsoft production code signing certificate authorities. All Certification Authority (CA) keys are stored within the cryptographic boundary of Federal Information Processing Standards (FIPS) publication 140-2 compliant hardware security modules. After initial generation, root certificate keys and top level CA keys are removed from the online signing service, encrypted, and stored offline.
+All certificates generated by the Device Guard signing service are unique per customer and are independent of the Microsoft production code signing certificate authorities. All Certification Authority (CA) keys are stored within the cryptographic boundary of Federal Information Processing Standards (FIPS) publication 140-2 compliant hardware security modules. After initial generation, root certificate keys and top level CA keys are removed from the online signing service, encrypted, and stored offline.
--- a/store-for-business/sign-code-integrity-policy-with-device-guard-signing.md
+++ b/store-for-business/sign-code-integrity-policy-with-device-guard-signing.md
@ -18,12 +18,12 @@ ms.date: 10/17/2017
 # Sign code integrity policy with Device Guard signing

 > [!IMPORTANT]
-> We are introducing a new version of the Device Guard Signing Service (DGSS) to be more automation friendly. The new version of the service (DGSS v2) is now available. As announced earlier, you will have until the end of December 2020 to transition to DGSS v2. At the end of December 2020, the existing web-based mechanisms for the current version of the DGSS service will be retired and will no longer be available for use. Please make plans to migrate to the new version of the service by the end of December 2020.
+> We are introducing a new version of the Device Guard Signing Service (DGSS) to be more automation friendly. The new version of the service (DGSS v2) is now available. As announced earlier, you will have until June 9, 2021 to transition to DGSS v2. On June 9, 2021, the existing web-based mechanisms for the current version of the DGSS service will be retired and will no longer be available for use. Please make plans to migrate to the new version of the service by June 9, 2021.
 >
 > Following are the major changes we are making to the service: 
 > - The method for consuming the service will change to a more automation-friendly method based on PowerShell cmdlets. These cmdlets are available as a NuGet download, https://www.nuget.org/packages/Microsoft.Acs.Dgss.Client/.
 > - In order to achieve desired isolation, you will be required to get a new CI policy from DGSS v2 (and optionally sign it). 
-> -	DGSS v2 will not have support for downloading leaf certificates used to sign your files (however, the root certificate will still be available to download).  Note that the certificate used to sign a file can be easily extracted from the signed file itself.  As a result, after DGSS v1 is retired at the end of December 2020, you will no longer be able to download the leaf certificates used to sign your files.
+> -	DGSS v2 will not have support for downloading leaf certificates used to sign your files (however, the root certificate will still be available to download).  Note that the certificate used to sign a file can be easily extracted from the signed file itself.  As a result, after DGSS v1 is retired, you will no longer be able to download the leaf certificates used to sign your files.
 >
 > The following functionality will be available via these PowerShell cmdlets:
 > - Get a CI policy
@ -58,4 +58,4 @@ Before you get started, be sure to review these best practices:
 4.  After the files are uploaded, click **Sign** to sign the code integrity policy.
 5.  Click **Download** to download the signed code integrity policy.

-    When you sign a code integrity policy with the Device Guard signing portal, the signing certificate is added to the policy. This means you can't modify this policy. If you need to make changes, make them to an unsigned version of the policy, and then resign the policy.
+    When you sign a code integrity policy with the Device Guard signing portal, the signing certificate is added to the policy. This means you can't modify this policy. If you need to make changes, make them to an unsigned version of the policy, and then resign the policy.
--- a/windows/client-management/mdm/certificate-authentication-device-enrollment.md
+++ b/windows/client-management/mdm/certificate-authentication-device-enrollment.md
@ -14,7 +14,7 @@ ms.date: 06/26/2017

 # Certificate authentication device enrollment

-This section provides an example of the mobile device enrollment protocol using certificate authentication policy. For details about the Microsoft mobile device enrollment protocol for Windows 10, see [\[MS-MDE2\]: Mobile Device Enrollment Protocol Version 2]( https://go.microsoft.com/fwlink/p/?LinkId=619347).
+This section provides an example of the mobile device enrollment protocol using certificate authentication policy. For details about the Microsoft mobile device enrollment protocol for Windows 10, see [\[MS-MDE2\]: Mobile Device Enrollment Protocol Version 2](https://go.microsoft.com/fwlink/p/?LinkId=619347).

 > [!Note]
 > To set up devices to use certificate authentication for enrollment, you should create a provisioning package. For more information about provisioning packages, see [Build and apply a provisioning package](/windows/configuration/provisioning-packages/provisioning-create-package).
@ -31,7 +31,7 @@ For the list of enrollment scenarios not supported in Windows 10, see [Enrollme

 The following example shows the discovery service request.

-``` syntax
+```xml
 POST /EnrollmentServer/Discovery.svc HTTP/1.1
 Content-Type: application/soap+xml; charset=utf-8
 User-Agent: Windows Enrollment Client
@ -60,7 +60,7 @@ Cache-Control: no-cache
            <EmailAddress>user@contoso.com</EmailAddress>
            <OSEdition>101</OSEdition> <!--New in Windows 10-->
            <OSVersion>10.0.0.0</OSVersion> <!--New in Windows 10-->
-            <RequestVersion>3.0</RequestVersion> <!--Updated in Windows 10-->
+            <RequestVersion>3.0</RequestVersion> <!--Updated in Windows 10-->   
            <ApplicationVersion>10.0.0.0</ApplicationVersion>
            <AuthPolicies>Certificate</AuthPolicies> <!--New in Windows 10-->
         </request> 
@ -71,7 +71,7 @@ Cache-Control: no-cache

 The following example shows the discovery service response.

-```
+```xml
 HTTP/1.1 200 OK
 Content-Length: 865
 Content-Type: application/soap+xml; charset=utf-8
@ -111,7 +111,7 @@ http://schemas.microsoft.com/windows/management/2012/01/enrollment/IDiscoverySer

 The following example shows the policy web service request.

-```
+```xml
 POST /ENROLLMENTSERVER/DEVICEENROLLMENTWEBSERVICE.SVC HTTP/1.1
 Content-Type: application/soap+xml; charset=utf-8
 User-Agent: Windows Enrollment Client
@ -183,7 +183,7 @@ Cache-Control: no-cache

 The following snippet shows the policy web service response.

-```
+```xml
 HTTP/1.1 200 OK
 Date: Fri, 03 Aug 2012 20:00:00 GMT
 Server: <server name here>
@ -261,7 +261,7 @@ Content-Length: xxxx

 The following example shows the enrollment web service request.

-```
+```xml
 POST /EnrollmentServer/DeviceEnrollmentWebService.svc HTTP/1.1
 Content-Type: application/soap+xml; charset=utf-8
 User-Agent: Windows Enrollment Client
@ -369,7 +369,7 @@ http://schemas.microsoft.com/5.0.0.0/ConfigurationManager/Enrollment/DeviceEnrol

 The following example shows the enrollment web service response.

-```
+```xml
 HTTP/1.1 200 OK
 Cache-Control: private
 Content-Length: 10231
@ -422,7 +422,7 @@ Date: Fri, 03 Aug 2012 00:32:59 GMT

 The following example shows the encoded provisioning XML.

-```
+```xml
 <wap-provisioningdoc version="1.1">
   <characteristic type="CertificateStore">
      <characteristic type="Root">
--- a/windows/client-management/mdm/devdetail-ddf-file.md
+++ b/windows/client-management/mdm/devdetail-ddf-file.md
@ -189,7 +189,7 @@ The XML below is the current version for this CSP.
          <MIME>text/plain</MIME>
        </DFType>
      </DFProperties>
-    </Node> 
+    </Node>
    <Node>
      <NodeName>HwV</NodeName>
      <DFProperties>
--- a/windows/client-management/mdm/images/edit-row.png
+++ b/windows/client-management/mdm/images/edit-row.png
--- a/windows/client-management/mdm/policy-csp-deviceinstallation.md
+++ b/windows/client-management/mdm/policy-csp-deviceinstallation.md
@ -30,6 +30,9 @@ ms.localizationpriority: medium
  <dd>
    <a href="#deviceinstallationallowinstallationofmatchingdevicesetupclasses">DeviceInstallation/AllowInstallationOfMatchingDeviceSetupClasses</a>
  </dd>
+ <dd>
+    <a href="#deviceinstallationenableinstallationpolicylayering">DeviceInstallation/EnableInstallationPolicyLayering</a>
+  </dd>
  <dd>
    <a href="#deviceinstallationpreventdevicemetadatafromnetwork">DeviceInstallation/PreventDeviceMetadataFromNetwork</a>
  </dd>
@ -94,12 +97,22 @@ ms.localizationpriority: medium

 <!--/Scope-->
 <!--Description-->
-This policy setting allows you to specify a list of Plug and Play hardware IDs and compatible IDs for devices that Windows is allowed to install. 
+This policy setting allows you to specify a list of plug-and-play hardware IDs and compatible IDs for devices that Windows is allowed to install. 

 > [!TIP]
-> Use this policy setting only when the "Prevent installation of devices not described by other policy settings" policy setting is enabled. Other policy settings that prevent device installation take precedence over this one.
+> This policy setting is intended to be used only when the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting is enabled, however it may also be used with the "Prevent installation of devices not described by other policy settings" policy setting for legacy policy definitions.

-If you enable this policy setting, Windows is allowed to install or update any device whose Plug and Play hardware ID or compatible ID appears in the list you create, unless another policy setting specifically prevents that installation (for example, the "Prevent installation of devices that match any of these device IDs" policy setting, the "Prevent installation of devices for these device classes" policy setting, or the "Prevent installation of removable devices" policy setting). If you enable this policy setting on a remote desktop server, the policy setting affects redirection of the specified devices from a remote desktop client to the remote desktop server.
+When this policy setting is enabled together with the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting, Windows is allowed to install or update any device whose Plug and Play hardware ID or compatible ID appears in the list you create, unless another policy setting at the same or higher layer in the hierarchy specifically prevents that installation, such as the following policy settings:
+- Prevent installation of devices that match these device IDs
+- Prevent installation of devices that match any of these device instance IDs
+
+If the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting is not enabled with this policy setting, then any other policy settings specifically preventing installation will take precedence.
+> [!NOTE]
+> The "Prevent installation of devices not described by other policy settings" policy setting has been replaced by the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting for supported target Windows 10 versions. It is recommended that you use the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting when possible.
+
+Alternatively, if this policy setting is enabled together with the "Prevent installation of devices not described by other policy settings" policy setting, Windows is allowed to install or update driver packages whose device setup class GUIDs appear in the list you create, unless another policy setting specifically prevents installation (for example, the "Prevent installation of devices that match these device IDs" policy setting, the "Prevent installation of devices for these device classes" policy setting, the "Prevent installation of devices that match any of these device instance IDs" policy setting, or the "Prevent installation of removable devices" policy setting).
+
+If you enable this policy setting on a remote desktop server, the policy setting affects redirection of the specified devices from a remote desktop client to the remote desktop server.

 If you disable or do not configure this policy setting, and no other policy setting describes the device, the "Prevent installation of devices not described by other policy settings" policy setting determines whether the device can be installed.

@ -203,17 +216,31 @@ To verify that the policy is applied, check C:\windows\INF\setupapi.dev.log and

 > [!div class = "checklist"]
 > * Device
-
+Added in Windows 10, version 1903. Also available in Windows 10, version 1809.
 <hr/>

 <!--/Scope-->
 <!--Description-->
-Added in Windows 10, version 1903. Also available in Windows 10, version 1809. This policy setting allows you to specify a list of Plug and Play device instance IDs for devices that Windows is allowed to install. Use this policy setting only when the "Prevent installation of devices not described by other policy settings" policy setting is enabled. Other policy settings that prevent device installation take precedence over this one.
+This policy setting allows you to specify a list of Plug and Play device instance IDs for devices that Windows is allowed to install.

-If you enable this policy setting, Windows is allowed to install or update any device whose Plug and Play device instance ID appears in the list you create, unless another policy setting specifically prevents that installation (for example, the "Prevent installation of devices that match any of these device IDs" policy setting, the "Prevent installation of devices for these device classes" policy setting, the "Prevent installation of devices that match any of these device instance IDs" policy setting, or the "Prevent installation of removable devices" policy setting). If you enable this policy setting on a remote desktop server, the policy setting affects redirection of the specified devices from a remote desktop client to the remote desktop server.
+> [!TIP]
+> This policy setting is intended to be used only when the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting is enabled, however it may also be used with the "Prevent installation of devices not described by other policy settings" policy setting for legacy policy definitions.
+
+When this policy setting is enabled together with the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting, Windows is allowed to install or update any device whose Plug and Play device instance ID appears in the list you create, unless another policy setting at the same or higher layer in the hierarchy specifically prevents that installation, such as the following policy settings:
+- Prevent installation of devices that match any of these device instance IDs
+ 
+If the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting is not enabled with this policy setting, then any other policy settings specifically preventing installation will take precedence.
+
+> [!NOTE]
+> The "Prevent installation of devices not described by other policy settings" policy setting has been replaced by the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting for supported target Windows 10 versions. It is recommended that you use the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting when possible.
+
+Alternatively, if this policy setting is enabled together with the "Prevent installation of devices not described by other policy settings" policy setting, Windows is allowed to install or update any device whose Plug and Play device instance ID appears in the list you create, unless another policy setting specifically prevents that installation (for example, the "Prevent installation of devices that match any of these device IDs" policy setting, the "Prevent installation of devices for these device classes" policy setting, the "Prevent installation of devices that match any of these device instance IDs" policy setting, or the "Prevent installation of removable devices" policy setting).
+
+If you enable this policy setting on a remote desktop server, the policy setting affects redirection of the specified devices from a remote desktop client to the remote desktop server.

 If you disable or do not configure this policy setting, and no other policy setting describes the device, the "Prevent installation of devices not described by other policy settings" policy setting determines whether the device can be installed.

+
 Peripherals can be specified by their [device instance ID](/windows-hardware/drivers/install/device-instance-ids). Test the configuration prior to rolling it out to ensure it allows the devices expected. Ideally test various instances of the hardware. For example, test multiple USB keys rather than only one.

 <!--/Description-->
@ -315,20 +342,30 @@ To verify the policy is applied, check C:\windows\INF\setupapi.dev.log and see i

 <!--/Scope-->
 <!--Description-->
-This policy setting allows you to specify a list of device setup class globally unique identifiers (GUIDs) for device drivers that Windows is allowed to install. 
+This policy setting allows you to specify a list of device setup class globally unique identifiers (GUIDs) for driver packages that Windows is allowed to install. 

 > [!TIP]
-> Use this policy setting only when the "Prevent installation of devices not described by other policy settings" policy setting is enabled. Other policy settings that prevent device installation take precedence over this one.
+> This policy setting is intended to be used only when the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting is enabled, however it may also be used with the "Prevent installation of devices not described by other policy settings" policy setting for legacy policy definitions.

-If you enable this policy setting, Windows is allowed to install or update device drivers whose device setup class GUIDs appear in the list you create, unless another policy setting specifically prevents installation (for example, the "Prevent installation of devices that match these device IDs" policy setting, the "Prevent installation of devices for these device classes" policy setting, or the "Prevent installation of removable devices" policy setting). If you enable this policy setting on a remote desktop server, the policy setting affects redirection of the specified devices from a remote desktop client to the remote desktop server.
+When this policy setting is enabled together with the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting, Windows is allowed to install or update driver packages whose device setup class GUIDs appear in the list you create, unless another policy setting at the same or higher layer in the hierarchy specifically prevents that installation, such as the following policy settings:

-This setting allows device installation based on the serial number of a removable device if that number is in the hardware ID.
+- Prevent installation of devices for these device classes
+- Prevent installation of devices that match these device IDs
+- Prevent installation of devices that match any of these device instance IDs
+
+If the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting is not enabled with this policy setting, then any other policy settings specifically preventing installation will take precedence.
+
+> [!NOTE]
+> The "Prevent installation of devices not described by other policy settings" policy setting has been replaced by the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting for supported target Windows 10 versions. It is recommended that you use the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting when possible.
+
+Alternatively, if this policy setting is enabled together with the "Prevent installation of devices not described by other policy settings" policy setting, Windows is allowed to install or update driver packages whose device setup class GUIDs appear in the list you create, unless another policy setting specifically prevents installation (for example, the "Prevent installation of devices that match these device IDs" policy setting, the "Prevent installation of devices for these device classes" policy setting, the "Prevent installation of devices that match any of these device instance IDs" policy setting, or the "Prevent installation of removable devices" policy setting).
+
+If you enable this policy setting on a remote desktop server, the policy setting affects redirection of the specified devices from a remote desktop client to the remote desktop server.

 If you disable or do not configure this policy setting, and no other policy setting describes the device, the "Prevent installation of devices not described by other policy settings" policy setting determines whether the device can be installed.

 Peripherals can be specified by their [hardware identity](/windows-hardware/drivers/install/device-identification-strings). For a list of common identifier structures, see [Device Identifier Formats](/windows-hardware/drivers/install/device-identifier-formats). Test the configuration prior to rolling it out to ensure it allows the devices expected. Ideally test various instances of the hardware. For example, test multiple USB keys rather than only one.

-
 <!--/Description-->
 > [!TIP]
 > This is an ADMX-backed policy and requires a special SyncML format to enable or disable.  For details, see [Understanding ADMX-backed policies](./understanding-admx-backed-policies.md).
@ -394,6 +431,133 @@ To verify that the policy is applied, check C:\windows\INF\setupapi.dev.log and

 <hr/>

+<!--Policy-->
+## DeviceInstallation/EnableInstallationPolicyLayering
+
+<!--SupportedSKUs-->
+<table>
+<tr>
+    <th>Windows Edition</th>
+    <th>Supported?</th>
+</tr>
+<tr>
+    <td>Home</td>
+    <td><img src="images/crossmark.png" alt="cross mark" /></td>
+</tr>
+<tr>
+    <td>Pro</td>
+    <td><img src="images/checkmark.png" alt="check mark" /><sup>5</sup></td>
+</tr>
+<tr>
+    <td>Business</td>
+    <td><img src="images/checkmark.png" alt="check mark" /><sup>5</sup></td>
+</tr>
+<tr>
+    <td>Enterprise</td>
+    <td><img src="images/checkmark.png" alt="check mark" /><sup>5</sup></td>
+</tr>
+<tr>
+    <td>Education</td>
+    <td><img src="images/checkmark.png" alt="check mark" /><sup>5</sup></td>
+</tr>
+</table>
+
+<!--/SupportedSKUs-->
+<hr/>
+
+<!--Scope-->
+[Scope](./policy-configuration-service-provider.md#policy-scope):
+
+> [!div class = "checklist"]
+> * Device
+Added in Windows 10, Version 2106
+<hr/>
+
+<!--/Scope-->
+<!--Description-->
+This policy setting will change the evaluation order in which Allow and Prevent policy settings are applied when more than one install policy setting is applicable for a given device. Enable this policy setting to ensure that overlapping device match criteria is applied based on an established hierarchy where more specific match criteria supersedes less specific match criteria. The hierarchical order of evaluation for policy settings that specify device match criteria is as follows:
+
+Device instance IDs > Device IDs > Device setup class > Removable devices 
+
+**Device instance IDs**
+- Prevent installation of devices using drivers that match these device instance IDs.
+- Allow installation of devices using drivers that match these device instance IDs.
+
+**Device IDs**
+- Prevent installation of devices using drivers that match these device IDs.
+- Allow installation of devices using drivers that match these device IDs.
+
+**Device setup class**
+- Prevent installation of devices using drivers that match these device setup classes.
+- Allow installation of devices using drivers that match these device setup classes.
+
+**Removable devices**
+- Prevent installation of removable devices.
+
+> [!NOTE]
+> This policy setting provides more granular control than the "Prevent installation of devices not described by other policy settings" policy setting. If these conflicting policy settings are enabled at the same time, the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting will be enabled and the other policy setting will be ignored.
+
+If you disable or do not configure this policy setting, the default evaluation is used. By default, all "Prevent installation..." policy settings have precedence over any other policy setting that allows Windows to install a device.
+
+<!--/Description-->
+> [!TIP]
+> This is an ADMX-backed policy and requires a special SyncML format to enable or disable.  For details, see [Understanding ADMX-backed policies](./understanding-admx-backed-policies.md).
+> 
+> You must specify the data type in the SyncML as &lt;Format&gt;chr&lt;/Format&gt;. For an example SyncML, refer to [Enabling a policy](./understanding-admx-backed-policies.md#enabling-a-policy).
+> 
+> The payload of the SyncML 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 if your MDM supports it.  For more information, see [CDATA Sections](http://www.w3.org/TR/REC-xml/#sec-cdata-sect).
+
+<!--ADMXBacked-->
+ADMX Info:  
+-   GP English name: *Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria*
+-   GP name: *DeviceInstall_Allow_Deny_Layered*
+-   GP path: *System/Device Installation/Device Installation Restrictions*
+-   GP ADMX file name: *deviceinstallation.admx*
+
+<!--/ADMXBacked-->
+<!--SupportedValues-->
+
+<!--/SupportedValues-->
+<!--Example-->
+```xml
+<SyncML>
+    <SyncBody>
+        <Replace>
+            <CmdID>$CmdID$</CmdID>
+            <Item>
+                <Target>
+                    <LocURI>./Device/Vendor/MSFT/Policy/Config/DeviceInstallation/EnableInstallationPolicyLayering</LocURI>
+                </Target>
+                <Meta>
+                    <Format xmlns="syncml:metinf">string</Format>
+                </Meta>
+                <Data><enabled/><Data id="AllowDenyLayered" value="1"/></Data>;
+                </Item>
+        </Replace>
+    </SyncBody>
+</SyncML>
+```
+
+To verify that the policy is applied, check C:\windows\INF\setupapi.dev.log and see if the following is listed near the end of the log:
+
+
+```txt
+>>>  [Device Installation Restrictions Policy Check]
+>>>  Section start 2018/11/15 12:26:41.659
+<<<  Section end 2018/11/15 12:26:41.751
+<<<  [Exit status: SUCCESS]
+```
+You can also change the evaluation order of device installation policy settings by using a custom profile in Intune.
+
+:::image type="content" source="images/edit-row.png" alt-text="This is a edit row image":::
+
+<!--/Example-->
+<!--Validation-->
+
+<!--/Validation-->
+<!--/Policy-->
+<hr/>
+
 <!--Policy-->
 ## DeviceInstallation/PreventDeviceMetadataFromNetwork

@ -519,9 +683,12 @@ ADMX Info:
 <!--Description-->
 This policy setting allows you to prevent the installation of devices that are not specifically described by any other policy setting.

-If you enable this policy setting, Windows is prevented from installing or updating the device driver for any device that is not described by either the "Allow installation of devices that match any of these device IDs" or the "Allow installation of devices for these device classes" policy setting.
+> [!NOTE]
+> This policy setting has been replaced by the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting to provide more granular control. It is recommended that you use the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting instead of this policy setting.

-If you disable or do not configure this policy setting, Windows is allowed to install or update the device driver for any device that is not described by the "Prevent installation of devices that match any of these device IDs," "Prevent installation of devices for these device classes," or "Prevent installation of removable devices" policy setting.
+If you enable this policy setting, Windows is prevented from installing or updating the driver package for any device that is not described by either the "Allow installation of devices that match any of these device IDs", the "Allow installation of devices for these device classes", or the "Allow installation of devices that match any of these device instance IDs" policy setting.
+
+If you disable or do not configure this policy setting, Windows is allowed to install or update the driver package for any device that is not described by the "Prevent installation of devices that match any of these device IDs", "Prevent installation of devices for these device classes" policy setting, "Prevent installation of devices that match any of these device instance IDs", or "Prevent installation of removable devices" policy setting.

 <!--/Description-->
 > [!TIP]
@ -629,7 +796,10 @@ You can also block installation by using a custom profile in Intune.

 <!--/Scope-->
 <!--Description-->
-This policy setting allows you to specify a list of Plug and Play hardware IDs and compatible IDs for devices that Windows is prevented from installing. This policy setting takes precedence over any other policy setting that allows Windows to install a device.
+This policy setting allows you to specify a list of Plug and Play hardware IDs and compatible IDs for devices that Windows is prevented from installing. By default, this policy setting takes precedence over any other policy setting that allows Windows to install a device.
+
+> [!NOTE]
+> To enable the "Allow installation of devices that match any of these device instance IDs" policy setting to supersede this policy setting for applicable devices, enable the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting.

 If you enable this policy setting, Windows is prevented from installing a device whose hardware ID or compatible ID appears in the list you create. If you enable this policy setting on a remote desktop server, the policy setting affects redirection of the specified devices from a remote desktop client to the remote desktop server.

@ -873,9 +1043,12 @@ with

 <!--/Scope-->
 <!--Description-->
-This policy setting allows you to specify a list of device setup class globally unique identifiers (GUIDs) for device drivers that Windows is prevented from installing. This policy setting takes precedence over any other policy setting that allows Windows to install a device.
+This policy setting allows you to specify a list of device setup class globally unique identifiers (GUIDs) for driver packages that Windows is prevented from installing. By default, this policy setting takes precedence over any other policy setting that allows Windows to install a device.

-If you enable this policy setting, Windows is prevented from installing or updating device drivers whose device setup class GUIDs appear in the list you create. If you enable this policy setting on a remote desktop server, the policy setting affects redirection of the specified devices from a remote desktop client to the remote desktop server.
+> [!NOTE]
+> To enable the "Allow installation of devices that match any of these device IDs" and "Allow installation of devices that match any of these device instance IDs" policy settings to supersede this policy setting for applicable devices, enable the "Apply layered order of evaluation for Allow and Prevent device installation policies across all device match criteria" policy setting.
+
+If you enable this policy setting, Windows is prevented from installing or updating driver packages whose device setup class GUIDs appear in the list you create. If you enable this policy setting on a remote desktop server, the policy setting affects redirection of the specified devices from a remote desktop client to the remote desktop server.

 If you disable or do not configure this policy setting, Windows can install and update devices as allowed or prevented by other policy settings.

--- a/windows/client-management/mdm/policy-ddf-file.md
+++ b/windows/client-management/mdm/policy-ddf-file.md
--- a/windows/client-management/mdm/supl-ddf-file.md
+++ b/windows/client-management/mdm/supl-ddf-file.md
@ -725,7 +725,7 @@ The XML below is the DDF for the current version for this CSP.
          <Node>
            <NodeName>LocMasterSwitchDependencyNII</NodeName>
            <DFProperties>
-              <AccessType>
+              <AccessType>-
                <Get />
                <Replace />
              </AccessType>
--- a/windows/client-management/windows-10-mobile-and-mdm.md
+++ b/windows/client-management/windows-10-mobile-and-mdm.md
@ -531,7 +531,7 @@ To distribute an app offline (organization-managed), the app must be downloaded

 To install acquired Microsoft Store or LOB apps offline on a Windows 10 Mobile device, IT administrators can use an MDM system. The MDM system distributes the app packages that you downloaded from Microsoft Store (also called sideloading) to Windows 10 Mobile devices. Support for offline app distribution depends on the MDM system you are using, so consult your MDM vendor documentation for details. You can fully automate the app deployment process so that no user intervention is required.

-Microsoft Store apps or LOB apps that have been uploaded to the Microsoft Store for Business are automatically trusted on all Windows devices, as they are cryptographically signed with Microsoft Store certificates. LOB apps that are uploaded to the Microsoft Store for Business are private to your organization and are never visible to other companies or consumers. If you do not want to upload your LOB apps, you have to establish trust for the app on your devices. To establish this trust, you’ll need to generate a signing certificate with your Public Key Infrastructure and add your chain of trust to the trusted certificates on the device (see the certificates section). You can install up to 20 self-signed LOB apps per device with Windows 10 Mobile. To install more than 20 apps on a device, you can purchase a signing certificate from a trusted public Certificate Authority, or upgrade your devices to Windows 10 Mobile Enterprise edition.
+Microsoft Store apps or LOB apps that have been uploaded to the Microsoft Store for Business are automatically trusted on all Windows devices, as they are cryptographically signed with Microsoft Store certificates. LOB apps that are uploaded to the Microsoft Store for Business are private to your organization and are never visible to other companies or consumers. If you do not want to upload your LOB apps, you have to establish trust for the app on your devices. To establish this trust, you’ll need to generate a signing certificate with your Public Key Infrastructure and add your chain of trust to the trusted certificates on the device (see the certificates section). You can install up to 20 self-signed LOB apps per device with Windows 10 Mobile. To install more than 20 apps on a device, you can purchase a signing certificate from a trusted public Certificate Authority, or upgrade your devices to Windows 10 edition.

 For more information, see [Microsoft Store for Business](/microsoft-store/index).

@ -786,14 +786,12 @@ Update availability depends on what servicing option you choose for the device.
 <td align="left">Immediately after the Feature Update is published to Windows Update by Microsoft</td>
 <td align="left">Microsoft typically releases two Feature Updates per 12-month period (approximately every four months, though it can potentially be longer)</td>
 <td align="left">Makes new features available to users as soon as possible</td>
-<td align="left">Mobile &amp; Mobile Enterprise</td>
 </tr>
 <tr class="even">
 <td align="left"><strong>Current Branch for Business (CBB)</strong></td>
 <td align="left">A minimum of four months after the corresponding Feature Update is first published to Windows Update by Microsoft</td>
 <td align="left">A minimum of four months, though it potentially can be longerNo</td>
 <td align="left">Provides additional time to test new feature before deployment</td>
-<td align="left">Mobile Enterprise only</td>
 </tr>
 </tbody>
 </table>
@ -802,11 +800,11 @@ Update availability depends on what servicing option you choose for the device.

 *Applies to: Corporate devices*

-While Windows 10 Mobile provides updates directly to user devices from Windows Update, there are many organizations that want to track, test, and schedule updates to corporate devices. To support these requirements, we created the Windows 10 Mobile Enterprise edition.
+While Windows 10 Mobile provides updates directly to user devices from Windows Update, there are many organizations that want to track, test, and schedule updates to corporate devices. To support these requirements, we created the Windows 10 edition.

-Upgrading to Windows 10 Mobile Enterprise edition provides additional device and app management capabilities for organizations that want to:
-   **Defer, approve and deploy feature and quality updates:** Windows 10 Mobile devices get updates directly from Windows Update. If you want to curate updates prior to deploying them, an upgrade to Windows 10 Mobile Enterprise edition is required. Once Enterprise edition is enabled, the phone can be set to the Current Branch for Business servicing option, giving IT additional time to test updates before they are released.
-   **Deploy an unlimited number of self-signed LOB apps to a single device:** To use an MDM system to deploy LOB apps directly to devices, you must cryptographically sign the software packages with a code signing certificate that your organization’s certificate authority (CA) generates. You can deploy a maximum of 20 self-signed LOB apps to a Windows 10 Mobile device. To deploy more than 20 self-signed LOB apps, Windows 10 Mobile Enterprise is required.
+Upgrading to Windows 10 edition provides additional device and app management capabilities for organizations that want to:
+-   **Defer, approve and deploy feature and quality updates:** Windows 10 Mobile devices get updates directly from Windows Update. If you want to curate updates prior to deploying them, an upgrade to Windows 10 edition is required. Once Enterprise edition is enabled, the phone can be set to the Current Branch for Business servicing option, giving IT additional time to test updates before they are released.
+-   **Deploy an unlimited number of self-signed LOB apps to a single device:** To use an MDM system to deploy LOB apps directly to devices, you must cryptographically sign the software packages with a code signing certificate that your organization’s certificate authority (CA) generates. You can deploy a maximum of 20 self-signed LOB apps to a Windows 10 Mobile device. To deploy more than 20 self-signed LOB apps, Windows 10 is required.
 -   **Set the diagnostic data level:** Microsoft collects diagnostic data to help keep Windows devices secure and to help Microsoft improve the quality of Windows and Microsoft services. An upgrade to Windows 10 Mobile Enterprise edition is required to set the diagnostic data level so that only diagnostic information required to keep devices secured is gathered.

 To learn more about diagnostic, see [Configure Windows diagnostic data in your organization](/windows/configuration/configure-windows-diagnostic-data-in-your-organization).
--- a/windows/deployment/upgrade/windows-10-edition-upgrades.md
+++ b/windows/deployment/upgrade/windows-10-edition-upgrades.md
@ -26,9 +26,13 @@ With Windows 10, you can quickly upgrade from one edition of Windows 10 to ano

 For a list of operating systems that qualify for the Windows 10 Pro Upgrade or Windows 10 Enterprise Upgrade through Microsoft Volume Licensing, see [Windows 10 Qualifying Operating Systems](https://download.microsoft.com/download/2/d/1/2d14fe17-66c2-4d4c-af73-e122930b60f6/Windows10-QOS.pdf).

-The following table shows the methods and paths available to change the edition of Windows 10 that is running on your computer. **Note**: The reboot requirement for upgrading from Pro to Enterprise was removed in version 1607.
+The following table shows the methods and paths available to change the edition of Windows 10 that is running on your computer.

-Note: Although it isn't displayed yet in the table, edition upgrade is also possible using [edition upgrade policy](/configmgr/compliance/deploy-use/upgrade-windows-version) in Microsoft Endpoint Configuration Manager.
+> [!NOTE]
+> The reboot requirement for upgrading from Pro to Enterprise was removed in version 1607.
+
+> [!TIP]
+> Although it isn't displayed yet in the table, edition upgrade is also possible using [edition upgrade policy](/configmgr/compliance/deploy-use/upgrade-windows-version) in Microsoft Endpoint Configuration Manager.

 ![not supported](../images/x_blk.png) (X) = not supported</br>
 ![supported, reboot required](../images/check_grn.png) (green checkmark) = supported, reboot required</br>
@ -39,7 +43,7 @@ X = unsupported <BR>
 &#x2714; (green) = supported; reboot required<BR>
 &#x2714; (blue) = supported; no reboot required

-|Method |Home > Pro |Home > Education |Pro > Education |Pro > Enterprise |Ent > Education |Mobile > Mobile Enterprise |
+|Method |Home > Pro |Home > Education |Pro > Education |Pro > Enterprise |Ent > Education |Mobile |
 |-------|-----------|-----------------|----------------|-----------------|----------------|--------|
 | Using mobile device management (MDM) |![unsupported](../images/x_blk.png) |![supported](../images/check_grn.png) |![supported](../images/check_grn.png) |![supported](../images/check_blu.png) |![supported](../images/check_grn.png) |![supported](../images/check_blu.png) |
 | Using a provisioning package |![unsupported](../images/x_blk.png) |![supported](../images/check_grn.png) |![supported](../images/check_grn.png) |![supported](../images/check_grn.png) |![supported](../images/check_grn.png) |![supported](../images/check_blu.png) |
@ -63,7 +67,6 @@ X = unsupported <BR>
 | **Pro for Workstations > Enterprise** | ![supported, no reboot](../images/check_blu.png) | ![supported, no reboot](../images/check_blu.png) | ![supported, no reboot](../images/check_blu.png) | ![supported, no reboot](../images/check_blu.png) <br>(1703 - PC)<br>(1709 - MSfB) | ![supported, no reboot](../images/check_blu.png) | ![not supported](../images/x_blk.png) |
 | **Pro Education > Education** | ![supported, reboot required](../images/check_grn.png) | ![supported, reboot required](../images/check_grn.png) | ![supported, reboot required](../images/check_grn.png) | ![supported, reboot required](../images/check_grn.png) <br>(MSfB) | ![supported, reboot required](../images/check_grn.png) | ![not supported](../images/x_blk.png) |
 | **Enterprise > Education** | ![supported, reboot required](../images/check_grn.png) | ![supported, reboot required](../images/check_grn.png) | ![supported, reboot required](../images/check_grn.png) | ![supported, reboot required](../images/check_grn.png) <br>(MSfB) | ![supported, reboot required](../images/check_grn.png) | ![not supported](../images/x_blk.png) |
-| **Mobile > Mobile Enterprise** | ![supported, no reboot](../images/check_blu.png) |![supported, no reboot](../images/check_blu.png) | ![not supported](../images/x_blk.png) | ![not supported](../images/x_blk.png) | ![not supported](../images/x_blk.png) | ![not supported](../images/x_blk.png) |

 > [!NOTE]
 > - For information about upgrade paths in Windows 10 in S mode (for Pro or Education), check out [Windows 10 Pro/Enterprise in S mode](../windows-10-pro-in-s-mode.md)
@ -84,7 +87,7 @@ Use Windows Configuration Designer to create a provisioning package to upgrade a
 - To create a provisioning package for upgrading mobile editions of Windows 10, go to **Runtime settings &gt; EditionUpgrade &gt; UpgradeEditionWithLicense** in the **Available customizations** panel in Windows ICD and enter the product key for the upgraded edition.

 For more info about Windows Configuration Designer, see these topics:
- [Create a provisioining package for Windows 10](/windows/configuration/provisioning-packages/provisioning-create-package)
+- [Create a provisioning package for Windows 10](/windows/configuration/provisioning-packages/provisioning-create-package)
 - [Apply a provisioning package](/windows/configuration/provisioning-packages/provisioning-apply-package)


@ -122,7 +125,8 @@ If you do not have a product key, you can upgrade your edition of Windows 10 th

 3.  Follow the on-screen instructions.

-    **Note**<br>If you are a Windows 10 Home N or Windows 10 Home KN user and have trouble finding your applicable upgrade in the Microsoft Store, click [here](ms-windows-store://windowsupgrade/).
+    > [!NOTE]
+    > If you are a Windows 10 Home N or Windows 10 Home KN user and have trouble finding your applicable upgrade in the Microsoft Store, click [here](ms-windows-store://windowsupgrade/).

 ## License expiration

@ -130,7 +134,8 @@ Volume license customers whose license has expired will need to change the editi

 Downgrading from any edition of Windows 10 to Windows 7, 8, or 8.1 by entering a different product key is not supported.  You also cannot downgrade from a later version to an earlier version of the same edition (Ex: Windows 10 Pro 1709 to 1703) unless the rollback process is used. This topic does not discuss version downgrades.

-Note: If you are using [Windows 10 Enterprise Subscription Activation](/windows/deployment/windows-10-enterprise-subscription-activation) and a license expires, devices will automatically revert to the original edition when the grace period expires.
+> [!NOTE]
+> If you are using [Windows 10 Enterprise Subscription Activation](/windows/deployment/windows-10-enterprise-subscription-activation) and a license expires, devices will automatically revert to the original edition when the grace period expires.

 ### Scenario example

@ -150,21 +155,21 @@ You can move directly from Enterprise to any valid destination edition. In this
 <br>
 <table border="0" cellpadding="1">
    <tr>
-        <td colspan="10" align="center">Destination edition</td>
+        <th colspan="10" align="center">Destination edition</th>
    </tr>
    <tr>
-        <td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</td>
-        <td></td>
-        <td>Home</td>
-        <td>Pro</td>
-        <td>Pro for Workstations</td>
-        <td>Pro Education</td>
-        <td>Education</td>
-        <td>Enterprise LTSC</td>
-        <td>Enterprise</td>
+        <th>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</th>
+        <th>&nbsp;</th>
+        <th>Home</th>
+        <th>Pro</th>
+        <th>Pro for Workstations</th>
+        <th>Pro Education</th>
+        <th>Education</th>
+        <th>Enterprise LTSC</th>
+        <th>Enterprise</th>
    </tr>
    <tr>
-        <td rowspan="9" nowrap="nowrap" valign="middle">Starting edition</td>
+        <th rowspan="9" nowrap="nowrap" valign="middle">Starting edition</th>
    </tr>
    <tr>
        <td>Home</td>
--- a/windows/deployment/upgrade/windows-10-upgrade-paths.md
+++ b/windows/deployment/upgrade/windows-10-upgrade-paths.md
@ -43,17 +43,17 @@ D = Edition downgrade; personal data is maintained, applications and settings ar
 <table border="0" cellpadding="1">
    <tr>
        <td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</td>
-        <td></td>
-        <td>Windows 10 Home</td>
-        <td>Windows 10 Pro</td>
-        <td>Windows 10 Pro Education</td>
-        <td>Windows 10 Education</td>
-        <td>Windows 10 Enterprise</td>
-        <td>Windows 10 Mobile</td>
-        <td>Windows 10 Mobile Enterprise</td>
+        <td>&nbsp;</td>
+        <th>Windows 10 Home</th>
+        <th>Windows 10 Pro</th>
+        <th>Windows 10 Pro Education</th>
+        <th>Windows 10 Education</th>
+        <th>Windows 10 Enterprise</th>
+        <th>Windows 10 Mobile</th>
+        <th>Windows 10 Mobile Enterprise</th>
    </tr>
    <tr>
-        <td rowspan="7" nowrap="nowrap">Windows 7</td>
+        <th rowspan="7" nowrap="nowrap">Windows 7</th>
    </tr>
    <tr>
        <td>Starter</td>
@ -116,7 +116,7 @@ D = Edition downgrade; personal data is maintained, applications and settings ar
        <td></td>
    </tr>
    <tr>
-        <td rowspan="10" nowrap="nowrap">Windows 8.1</td>
+        <th rowspan="10" nowrap="nowrap">Windows 8.1</th>
    </tr>
    <tr>
        <td>(Core)</td>
@ -209,7 +209,7 @@ D = Edition downgrade; personal data is maintained, applications and settings ar
        <td>✔</td>
    </tr>
    <tr>
-        <td rowspan="8" nowrap="nowrap">Windows 10</td>
+        <th rowspan="8" nowrap="nowrap">Windows 10</th>
    </tr>
    <tr>
        <td>Home</td>
@ -261,17 +261,7 @@ D = Edition downgrade; personal data is maintained, applications and settings ar
        <td></td>
        <td>✔</td>
    </tr>
-    <tr>
-        <td>Mobile Enterprise</td>
-        <td></td>
-        <td></td>
-        <td></td>
-        <td></td>
-        <td></td>
-        <td>D</td>
-        <td></td>
-    </tr>
-</table>
+   </table>


 ## Related Topics
--- a/windows/privacy/basic-level-windows-diagnostic-events-and-fields-1903.md
+++ b/windows/privacy/basic-level-windows-diagnostic-events-and-fields-1903.md
@ -7023,7 +7023,7 @@ The following fields are available:
 - **ScenarioId**  Indicates the update scenario.
 - **SessionId**  Unique value for each update attempt.
 - **UpdateId**  Unique ID for each update.
- **Version**  Version of update
+- **Version**  Version of update.


 ### Update360Telemetry.UpdateAgentOneSettings
--- a/windows/whats-new/whats-new-windows-10-version-1803.md
+++ b/windows/whats-new/whats-new-windows-10-version-1803.md
@ -171,7 +171,7 @@ The new [security baseline for Windows 10 version 1803](/windows/security/threat

 ### Microsoft Defender Antivirus

-Microsoft Defender Antivirus now shares detection status between M365 services and interoperates with Microsoft Defender for Endpoint.  Additional policies have also been implemented to enhance cloud based protection, and new channels are available for emergency protection. For more information, see [Virus and threat protection](/windows/security/threat-protection/windows-defender-security-center/wdsc-virus-threat-protection) and [Use next-gen technologies in Microsoft Defender Antivirus through cloud-delivered protection](/microsoft-365/security/defender-endpoint/utilize-microsoft-cloud-protection-microsoft-defender-antivirus).
+Microsoft Defender Antivirus now shares detection status between M365 services and interoperates with Microsoft Defender for Endpoint.  Additional policies have also been implemented to enhance cloud based protection, and new channels are available for emergency protection. For more information, see [Virus and threat protection](/windows/security/threat-protection/windows-defender-security-center/wdsc-virus-threat-protection) and [Use next-gen technologies in Microsoft Defender Antivirus through cloud-delivered protection](/microsoft-365/security/defender-endpoint/cloud-protection-microsoft-defender-antivirus).

 ### Windows Defender Exploit Guard