Merging changes synced from https://github.com/MicrosoftDocs/windows-docs-pr (branch live)

.openpublishing.redirection.json

@@ -6232,6 +6232,11 @@
 "redirect_document_id": true
 },
 {
+"source_path": "windows/deployment/update/update-compliance-wdav-status.md",
+"redirect_url": "https://docs.microsoft.com/windows/deployment/update/update-compliance-get-started",
+"redirect_document_id": true
+},
+{
 "source_path": "windows/manage/update-compliance-using.md",
 "redirect_url": "https://docs.microsoft.com/windows/deployment/update/update-compliance-using",
 "redirect_document_id": true

windows/client-management/generate-kernel-or-complete-crash-dump.md

@@ -9,7 +9,7 @@ ms.localizationpriority: medium
 ms.author: delhan
 ms.date: 8/28/2019
 ms.reviewer: 
-manager: dcscontentpm
+manager: willchen
 ---
 
 # Generate a kernel or complete crash dump 

windows/deployment/TOC.md

@@ -246,6 +246,8 @@
 ### Monitor Windows Updates
 #### [Monitor Windows Updates with Update Compliance](update/update-compliance-monitor.md)
 #### [Get started with Update Compliance](update/update-compliance-get-started.md)
+##### [Update Compliance Configuration Script](update/update-compliance-configuration-script.md)
+##### [Manually Configuring Devices for Update Compliance](update/update-compliance-configuration-manual.md)
 #### [Use Update Compliance](update/update-compliance-using.md)
 ##### [Need Attention! report](update/update-compliance-need-attention.md)
 ##### [Security Update Status report](update/update-compliance-security-update-status.md)

windows/deployment/update/update-compliance-configuration-manual.md

@@ -0,0 +1,77 @@
+---
+title: Manually configuring devices for Update Compliance
+ms.reviewer: 
+manager: laurawi
+description: Manually configuring devices for Update Compliance
+keywords: update compliance, oms, operations management suite, prerequisites, requirements, updates, upgrades, antivirus, antimalware, signature, log analytics, wdav
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.pagetype: deploy
+audience: itpro
+author: jaimeo
+ms.author: jaimeo
+ms.localizationpriority: medium
+ms.collection: M365-analytics
+ms.topic: article
+---
+
+# Manually Configuring Devices for Update Compliance
+
+There are a number of requirements to consider when manually configuring Update Compliance. These can potentially change with newer versions of Windows 10. The [Update Compliance Configuration Script](update-compliance-configuration-script.md) will be updated when any configuration requirements change so only a redeployment of the script will be required.
+
+The requirements are separated into different categories:
+
+1. Ensuring the [**required policies**](#required-policies) for Update Compliance are correctly configured.
+2. Devices in every network topography needs to send data to the [**required endpoints**](#required-endpoints) for Update Compliance, for example both devices in main and satellite offices, which may have different network configurations.
+3. Ensure [**Required Windows services**](#required-services) are running or are scheduled to run. It is recommended all Microsoft and Windows services are set to their out-of-box defaults to ensure proper functionality.
+
+## Required policies
+
+> [!NOTE]
+> Windows 10 MDM and Group Policies are backed by registry keys. It is not recommended you set these registry keys directly for configuration as it can lead to unexpected behavior, so the exact registry key locations are not provided, though they are referenced for troubleshooting configuration issues with the [Update Compliance Configuration Script](update-compliance-configuration-script.md).
+
+Update Compliance has a number of policies that must be appropriately configured in order for devices to be processed by Microsoft and visible in Update Compliance. They are enumerated below, separated by whether the policies will be configured via [Mobile Device Management](https://docs.microsoft.com/windows/client-management/mdm/) (MDM) or Group Policy. For both tables:
+
+- **Policy** corresponds to the location and name of the policy.
+- **Value** Indicates what value the policy must be set to. Update Compliance requires *at least* Basic (or Required) telemetry, but can function off Enhanced or Full (or Optional).
+- **Function** details why the policy is required and what function it serves for Update Compliance. It will also detail a minimum version the policy is required, if any.
+
+### Mobile Device Management policies
+
+Each MDM Policy links to its documentation in the CSP hierarchy, providing its exact location in the hierarchy and more details.
+
+| Policy | Value | Function |
+|---------------------------|-|------------------------------------------------------------|
+|**Provider/*ProviderID*/**[**CommercialID**](https://docs.microsoft.com/windows/client-management/mdm/dmclient-csp#provider-providerid-commercialid) |[Your CommercialID](update-compliance-get-started.md#get-your-commercialid) |Identifies the device as belonging to your organization. |
+|**System/**[**AllowTelemetry**](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-system#system-allowtelemetry) |1- Basic |Configures the maximum allowed telemetry to be sent to Microsoft. Individual users can still set this lower than what the policy defines, see the below policy for more information. |
+|**System/**[**ConfigureTelemetryOptInSettingsUx**](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-system#system-configuretelemetryoptinsettingsux) | Disable Telemetry opt-in Settings | (*Windows 10 1803+*) Determines whether end-users of the device can adjust telemetry to levels lower than the level defined by AllowTelemetry. It is recommended you disable this policy order the effective telemetry level on devices may not be sufficient. |
+|**System/**[**AllowDeviceNameInDiagnosticData**](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-system#system-allowdevicenameindiagnosticdata) | 1 - Allowed | Allows device name to be sent for Windows Diagnostic Data. If this policy is Not Configured or set to 0 (Disabled), Device Name will not be sent and will not be visible in Update Compliance, showing `#` instead. |
+
+### Group Policies
+
+All Group Policies that need to be configured for Update Compliance are under **Computer Configuration>Administrative Templates>Windows Components\Data Collection and Preview Builds**. All of these policies must be in the *Enabled* state and set to the defined *Value* below.  
+
+| Policy | Value | Function |
+|---------------------------|-|-----------------------------------------------------------|
+|**Configure the Commercial ID** |[Your CommercialID](update-compliance-get-started.md#get-your-commercialid) | Identifies the device as belonging to your organization. |
+|**Allow Telemetry** | 1 - Basic |Configures the maximum allowed telemetry to be sent to Microsoft. Individual users can still set this lower than what the policy defines, see the below policy for more information. |
+|**Configure telemetry opt-in setting user interface** | Disable telemetry opt-in Settings |(*Windows 10 1803+*) Determines whether end-users of the device can adjust telemetry to levels lower than the level defined by AllowTelemetry. It is recommended you disable this policy order the effective telemetry level on devices may not be sufficient. |
+|**Allow device name to be sent in Windows diagnostic data** | Enabled | Allows device name to be sent for Windows Diagnostic Data. If this policy is Not Configured or Disabled, Device Name will not be sent and will not be visible in Update Compliance, showing `#` instead. |
+
+## Required endpoints
+
+To enable data sharing between devices, your network, and Microsoft's Diagnostic Data Service, configure your proxy to allow devices to contact the below endpoints.
+
+| **Endpoint**  | **Function**  |
+|---------------------------------------------------------|-----------|
+| `https://v10c.events.data.microsoft.com` | Connected User Experience and Diagnostic component endpoint for Windows 10, version 1803 and later. Census.exe must run on a regular cadence and contact this endpoint in order to receive the majority of [WaaSUpdateStatus](update-compliance-schema-waasupdatestatus.md) information for Update Compliance. |
+| `https://v10.vortex-win.data.microsoft.com` | Connected User Experience and Diagnostic component endpoint for Windows 10, version 1709 or earlier. |
+| `https://settings-win.data.microsoft.com` | Required for Windows Update functionality. |
+| `http://adl.windows.com` | Required for Windows Update functionality. |
+| `https://watson.telemetry.microsoft.com` | Windows Error Reporting (WER), used to provide more advanced error reporting in the event of certain Feature Update deployment failures. |
+| `https://oca.telemetry.microsoft.com`  | Online Crash Analysis, used to provide device-specific recommendations and detailed errors in the event of certain crashes. |
+| `https://login.live.com` | This endpoint facilitates MSA access and is required to create the primary identifier we use for devices. Without this service, devices will not be visible in the solution. This also requires Microsoft Account Sign-in Assistant service to be running (wlidsvc). |
+
+## Required services
+
+Many Windows and Microsoft services are required to ensure that not only the device can function, but Update Compliance can see device data. It is recommended that you allow all default services from the out-of-box experience to remain running. The [Update Compliance Configuration Script](update-compliance-configuration-script.md) checks whether the majority of these services are running or are allowed to run automatically.

windows/deployment/update/update-compliance-configuration-script.md

@@ -0,0 +1,99 @@
+---
+title: Update Compliance Configuration Script
+ms.reviewer: 
+manager: laurawi
+description: Downloading and using the Update Compliance Configuration Script
+keywords: update compliance, oms, operations management suite, prerequisites, requirements, updates, upgrades, antivirus, antimalware, signature, log analytics, wdav
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.pagetype: deploy
+audience: itpro
+author: jaimeo
+ms.author: jaimeo
+ms.localizationpriority: medium
+ms.collection: M365-analytics
+ms.topic: article
+---
+
+# Configuring devices through the Update Compliance Configuration Script
+
+The Update Compliance Configuration Script is the recommended method of configuring devices to send data to Microsoft for use with Update Compliance. The script configures device policies via Group Policy, ensures that required services are running, and more.
+
+You can [**download the script here**](https://github.com/cinglis-msft/UpdateComplianceConfigurationScript). Keep reading to learn how to configure the script and interpret error codes that are output in logs for troubleshooting.
+
+## How the script is organized
+
+The script is organized into two folders **Pilot** and **Deployment**. Both folders have the same key files: `ConfigScript.ps1` and `RunConfig.bat`. You configure `RunConfig.bat` according to the directions in the .bat itself, which will then execute `ConfigScript.ps1` with the parameters entered to RunConfig.bat.
+
+- The **Pilot** folder and its contents are intended to be used on an initial set of single devices in specific environments (main office & satellite office, for example) for testing and troubleshooting prior to broader deployment. This script is configured to collect and output detailed logs for every device it runs on.
+- The **Deployment** folder is intended to be deployed across an entire device population in a specific environment once devices in that environment have been validated with the Pilot script.
+
+## How to use the script
+
+### Piloting and Troubleshooting
+
+> [!IMPORTANT]
+> If you encounter an issue with Update Compliance, the first step should be to run the script in Pilot mode on a device you are encountering issues with, and save these Logs for reference with Support.
+
+When using the script in the context of troubleshooting, use `Pilot`. Enter `RunConfig.bat`, and configure it as follows:
+
+1. Configure `logPath` to a path where the script will have write access and a place you can easily access. This specifies the output of the log files generated when the script is in Verbose mode.
+2. Configure `commercialIDValue` to your CommercialID. To get your CommercialID, see [Getting your CommercialID](update-compliance-get-started.md#get-your-commercialid).
+3. Run the script. The script must be run in System context.
+4. Examine the Logs output for any issues. If there were issues:
+   - Compare Logs output with the required settings covered in [Manually Configuring Devices for Update Compliance] (update-compliance-configuration-manual.md).
+   - Examine the script errors and refer to the [script error reference](#script-error-reference) on how to interpret the codes.
+   - Make the necessary corrections and run the script again.
+5. When you no longer have issues, proceed to using the script for more broad deployment with the `Deployment` folder.
+
+
+### Broad deployment
+
+After verifying on a set of devices in a specific environment that everything is configured correctly, you can proceed to broad deployment.
+
+1. Configure `commercialIDValue` in `RunConfig.bat` to [your CommercialID](update-compliance-get-started.md#get-your-commercialid).
+2. Use a management tool like Configuration Manager or Intune to broadly deploy the script to your entire target population.
+
+## Script Error Reference
+
+|Error |Description |
+|-|-------------------|
+| 27 | Not system account. |
+| 37 | Unexpected exception when collecting logs|
+| 1  | General unexpected error|
+| 6  | Invalid CommercialID|
+| 48 | CommercialID is not a GUID|
+| 8  | Couldn't create registry key path to setup CommercialID|
+| 9  | Couldn't write CommercialID at registry key path|
+| 53 | There are conflicting CommercialID values.|
+| 11 | Unexpected result when setting up CommercialID.|
+| 62 | AllowTelemetry registry key is not of the correct type `REG_DWORD`|
+| 63 | AllowTelemetry is not set to the appropriate value and it could not be set by the script.|
+| 64 | AllowTelemetry is not of the correct type `REG_DWORD`.|
+| 99 | Device is not Windows 10.|
+| 40 | Unexpected exception when checking and setting telemetry.|
+| 12 | CheckVortexConnectivity failed, check Log output for more information.|
+| 12 | Unexpected failure when running CheckVortexConnectivity.|
+| 66 | Failed to verify UTC connectivity and recent uploads.| 
+| 67 | Unexpected failure when verifying UTC CSP connectivity of the WMI Bridge.|
+| 41 | Unable to impersonate logged-on user.|
+| 42 | Unexpected exception when attempting to impersonate logged-on user.|
+| 43 | Unexpected exception when attempting to impersonate logged-on user.|
+| 16 | Reboot is pending on device, restart device and restart script.|
+| 17 | Unexpected exception in CheckRebootRequired.|
+| 44 | Error when running CheckDiagTrack service.|
+| 45 | DiagTrack.dll not found.|
+| 50 | DiagTrack service not running.|
+| 54 | Microsoft Account Sign In Assistant (MSA) Service disabled.|
+| 55 | Failed to create new registry path for `SetDeviceNameOptIn` of the PowerShell script.|
+| 56 | Failed to create property for `SetDeviceNameOptIn` of the PowerShell script at registry path.|
+| 57 | Failed to update value for `SetDeviceNameOptIn` of the PowerShell script.|
+| 58 | Unexpected exception in `SetDeviceNameOptIn` of the PowerShell script.|
+| 59 | Failed to delete `LastPersistedEventTimeOrFirstBoot` property at registry path when attempting to clean up OneSettings.|
+| 60 | Failed to delete registry key when attempting to clean up OneSettings.|
+| 61 | Unexpected exception when attempting to clean up OneSettings.|
+| 52 | Could not find Census.exe|
+| 51 | Unexpected exception when attempting to run Census.exe|
+| 34 | Unexpected exception when attempting to check Proxy settings.|
+| 30 | Unable to disable Enterprise Auth Proxy. This registry value must be 0 for UTC to operate in an authenticated proxy environment.|
+| 35 | Unexpected exception when checking User Proxy.|

windows/deployment/update/update-compliance-get-started.md

@@ -1,8 +1,8 @@
 ---
-title: Get started with Update Compliance (Windows 10)
+title: Get started with Update Compliance
 ms.reviewer: 
 manager: laurawi
-description: Configure Update Compliance in Azure Portal to see the status of updates and antimalware protection on devices in your network.
+description: Prerequisites, Azure onboarding, and configuring devices for Update Compliance 
 keywords: update compliance, oms, operations management suite, prerequisites, requirements, updates, upgrades, antivirus, antimalware, signature, log analytics, wdav
 ms.prod: w10
 ms.mktglfcycl: deploy
@@ -16,112 +16,68 @@ ms.topic: article
 ---
 
 # Get started with Update Compliance
-This topic explains the steps necessary to configure your environment for Update Compliance.
 
-Steps are provided in sections that follow the recommended setup process:
+This topic introduces the high-level steps required to enroll to the Update Compliance solution and configure devices to send data to it. The following steps cover the enrollment and device configuration workflow.
 
-1. Ensure you meet the [Update Compliance prerequisites](#update-compliance-prerequisites).
-2. [Add Update Compliance to your Azure subscription](#add-update-compliance-to-your-azure-subscription).
-3. [Enroll devices in Update Compliance](#enroll-devices-in-update-compliance).
-4. [Use Update Compliance](update-compliance-using.md) to monitor Windows Updates and get Delivery Optimization insights.
+1. Ensure you can [meet the requirements](#update-compliance-prerequisites) to use Update Compliance.
+2. [Add Update Compliance](#add-update-compliance-to-your-azure-subscription) to your Azure subscription.
+3. [Configure devices](#enroll-devices-in-update-compliance) to send data to Update Compliance.
+
+After adding the solution to Azure and configuring devices, there will be a waiting period of up to 72 hours before you can begin to see devices in the solution. Before or as devices appear, you can learn how to [Use Update Compliance](update-compliance-using.md) to monitor Windows Updates and Delivery Optimization.
 
 ## Update Compliance prerequisites
+
 Before you begin the process to add Update Compliance to your Azure subscription, first ensure you can meet the prerequisites:
-1. Update Compliance works only with Windows 10 Professional, Education, and Enterprise editions. Update Compliance supports both the typical Windows 10 Enterprise edition, as well as [Windows 10 Enterprise multi-session](https://docs.microsoft.com/azure/virtual-desktop/windows-10-multisession-faq). Update Compliance only provides data for the standard Desktop Windows 10 version and is not currently compatible with Windows Server, Surface Hub, IoT, etc. 
-2. Update Compliance provides detailed deployment data for devices on the Semi-Annual Channel and the Long-term Servicing Channel. Update Compliance will show Windows Insider Preview devices, but currently will not provide detailed deployment information for them.
-3. Update Compliance requires at least the Basic level of diagnostic data and a Commercial ID to be enabled on the device. 
-4. For Windows 10 1803+, device names will not appear in Update Compliance unless you opt in. The steps to accomplish this is outlined in the [Enroll devices in Update Compliance](#enroll-devices-in-update-compliance) section.
+
+1. **Compatible Operating Systems and Editions**: Update Compliance works only with Windows 10 Professional, Education, and Enterprise editions. Update Compliance supports both the typical Windows 10 Enterprise edition, as well as [Windows 10 Enterprise multi-session](https://docs.microsoft.com/azure/virtual-desktop/windows-10-multisession-faq). Update Compliance only provides data for the standard Desktop Windows 10 version and is not currently compatible with Windows Server, Surface Hub, IoT, etc.
+2. **Compatible Windows 10 Servicing Channels**: Update Compliance supports Windows 10 devices on the Semi-Annual Channel (SAC) and the Long-term Servicing Channel (LTSC). Update Compliance *counts* Windows Insider Preview (WIP) devices, but does not currently provide detailed deployment insights for them.
+3. **Diagnostic data requirements**: Update Compliance requires devices be configured to send diagnostic data at *Required* level (previously *Basic*). To learn more about what's included in different diagnostic levels, see [Diagnostics, feedback, and privacy in Windows 10](https://support.microsoft.com/help/4468236/diagnostics-feedback-and-privacy-in-windows-10-microsoft-privacy).
+4. **Data transmission requirements**: Devices must be able to contact specific endpoints required to authenticate and send diagnostic data. These are enumerated in detail at [Configuring Devices for Update Compliance manually](update-compliance-configuration-manual.md).
+5. **Showing Device Names in Update Compliance**: For Windows 10 1803+, device names will not appear in Update Compliance unless you individually opt-in devices via policy. The steps to accomplish this is outlined in [Configuring Devices for Update Compliance](update-compliance-configuration-manual.md).
 
 ## Add Update Compliance to your Azure subscription
-Update Compliance is offered as a solution which is linked to a new or existing [Azure Log Analytics](https://docs.microsoft.com/azure/log-analytics/query-language/get-started-analytics-portal) workspace within your Azure subscription. To configure this, follow these steps:
 
-1. Sign in to the [Azure Portal](https://portal.azure.com) with your work or school account or a Microsoft account. If you don't already have an Azure subscription you can create one (including free trial options) through the portal.
+Update Compliance is offered as an Azure Marketplace application which is linked to a new or existing [Azure Log Analytics](https://docs.microsoft.com/azure/log-analytics/query-language/get-started-analytics-portal) workspace within your Azure subscription. To configure this, follow these steps:
+
+1. Go to the [Update Compliance page in the Azure Marketplace](https://azuremarketplace.microsoft.com/marketplace/apps/Microsoft.WaaSUpdateInsights?tab=Overview). You may need to login to your Azure subscription to access this.
+2. Select **Get it now**.
+3. Choose an existing or configure a new Log Analytics Workspace. While an Azure subscription is required, you will not be charged for ingestion of Update Compliance data.
+   - [Desktop Analytics](https://docs.microsoft.com/sccm/desktop-analytics/overview) customers are advised to use the same workspace for Update Compliance.
+   - [Azure Update Management](https://docs.microsoft.com/azure/automation/automation-update-management) customers are advised to use the same workspace for Update Compliance.
+4. After your workspace is configured and selected, select **Create**. You will receive a notification when the solution has been successfully created.
 
 > [!NOTE]
-> Update Compliance is included at no additional cost with Windows 10 Professional, Education, and Enterprise editions. An Azure subscription is required for managing and using Update Compliance, but no Azure charges are expected to accrue to the subscription as a result of using Update Compliance. 
+> It is not currently supported to programmatically enroll to Update Compliance via the [Azure CLI](https://docs.microsoft.com/cli/azure) or otherwise. You must manually add Update Compliance to your Azure subscription.
 
-2. In the Azure portal select **+ Create a resource**, and search for "Update Compliance". You should see it in the results below. 
+### Get your CommercialID
 
-![Update Compliance marketplace search results](images/UC_00_marketplace_search.png)
+A CommercialID is a globally-unique identifier assigned to a specific Log Analytics workspace. The CommercialID is copied to an MDM or Group Policy and is used to identify devices in your environment.
 
-3. Select **Update Compliance** and a blade will appear summarizing the solution's offerings. At the bottom, select **Create** to begin adding the solution to Azure.
+To find your CommercialID within Azure:
 
-![Update Compliance solution creation](images/UC_01_marketplace_create.png)
-
-4. Choose an existing workspace or create a new workspace that will be assigned to the Update Compliance solution. 
-   - [Desktop Analytics](https://docs.microsoft.com/sccm/desktop-analytics/overview) customers are advised to use the same workspace for Update Compliance. 
-   - If you are creating a new workspace, and your organization does not have policies governing naming conventions and structure, consider the following workspace settings to get started:
-       - Choose a workspace name which reflects the scope of planned usage in your organization, for example *PC-Analytics*.
-       - For the resource group setting select **Create new** and use the same name you chose for your new workspace.
-       - For the location setting, choose the Azure region where you would prefer the data to be stored.
-       - For the pricing tier select **per GB**.
-
-![Update Compliance workspace creation](images/UC_02_workspace_create.png)
-
-5. The resource group and workspace creation process could take a few minutes. After this, you are able to use that workspace for Update Compliance. Select **Create**.
-
-![Update Compliance workspace selection](images/UC_03_workspace_select.png)
-
-6. Watch for a notification in the Azure portal that your deployment has been successful. This might take a few minutes. Then, select **Go to resource**. 
-
-![Update Compliance deployment successful](images/UC_04_resourcegrp_deployment_successful.png)
-
-## Enroll devices in Update Compliance
-Once you've added Update Compliance to a workspace in your Azure subscription, you can start enrolling the devices in your organization. For Update Compliance there are three key steps to ensure successful enrollment:
-
-### Deploy your Commercial ID to devices
-A Commercial ID is a globally-unique identifier assigned to a specific Log Analytics workspace. This is used to identify devices as part of your environment.
-
-To find your Commercial ID within Azure: 
-1. Navigate to the **Solutions** tab for your workspace, and then select the **WaaSUpdateInsights** solution. 
-2. From there, select the Update Compliance Settings page on the navbar. 
-3. Your Commercial ID is available in the settings page.
-
-![Update Compliance Settings page](images/UC_commercialID.png)
+1. Navigate to the **Solutions** tab for your workspace, and then select the **WaaSUpdateInsights** solution.
+2. From there, select the Update Compliance Settings page on the navbar.
+3. Your CommercialID is available in the settings page.
 
 > [!IMPORTANT]
->Regenerate your Commercial ID only if your original ID can no longer be used or if you want to completely reset your workspace. Regenerating your Commercial ID cannot be undone and will result in you losing data for all devices that have the current Commercial ID until the new Commercial ID is deployed to devices.
+> Regenerate your CommercialID only if your original ID can no longer be used or if you want to completely reset your workspace. Regenerating your CommercialID cannot be undone and will result in you losing data for all devices that have the current CommercialID until the new CommercialID is deployed to devices.
 
-#### Deploying Commercial ID using Group Policy
-Commercial ID can be deployed using Group Policy. The Group Policy for Commercial ID is under **Computer Configuration\Administrative Templates\Windows Components\Data Collection and Preview Builds\Configure the Commercial ID**. 
+## Enroll devices in Update Compliance
 
-![Commercial ID Group Policy location](images/UC_commercialID_GP.png)
-
-#### Deploying Commercial ID using MDM
-Commercial ID can be deployed through a [Mobile Device Management](https://docs.microsoft.com/windows/client-management/mdm/) (MDM) policy beginning with Windows 10, version 1607. Commercial ID is under the [DMClient configuration service provider](https://docs.microsoft.com/windows/client-management/mdm/dmclient-csp). 
-
-### Ensure endpoints are whitelisted
-To enable data sharing between devices, your network, and Microsoft's Diagnostic Data Service, configure your proxy to whitelist the following endpoints. You may need security group approval to do this. 
-
-| **Endpoint**  | **Function**  |
-|---------------------------------------------------------|-----------|
-| `https://v10c.events.data.microsoft.com` | Connected User Experience and Diagnostic component endpoint for Windows 10, version 1803 and later. |
-| `https://v10.vortex-win.data.microsoft.com` | Connected User Experience and Diagnostic component endpoint for Windows 10, version 1709 or earlier. |
-| `https://settings-win.data.microsoft.com` | Enables the compatibility update to send data to Microsoft. |
-| `http://adl.windows.com` | Allows the compatibility update to receive the latest compatibility data from Microsoft. |
-| `https://watson.telemetry.microsoft.com` | Windows Error Reporting (WER), used to provide more advanced error reporting in the event of certain Feature Update deployment failures. |
-| `https://oca.telemetry.microsoft.com`  | Online Crash Analysis, used to provide device-specific recommendations and detailed errors in the event of certain crashes. |
-| `https://login.live.com` | This endpoint is optional but allows for the Update Compliance service to more reliably identify and process devices. If you want to disable end-user managed service account (MSA) access, you should apply the appropriate [policy](https://docs.microsoft.com/windows/security/identity-protection/access-control/microsoft-accounts#block-all-consumer-microsoft-account-user-authentication) instead of blocking this endpoint. |
-
-### Set diagnostic data levels
-Update Compliance requires that devices are configured to send Microsoft at least the Basic level of diagnostic data in order to function. For more information on Windows diagnostic data, see [Configure Windows diagnostic data in your organization](https://docs.microsoft.com/windows/privacy/configure-windows-diagnostic-data-in-your-organization).
-
-#### Configuring Telemetry level using Group Policy
-You can set Allow Telemetry through Group Policy, this setting is in the same place as the Commercial ID policy, under **Computer Configuration\Administrative Templates\Windows Components\Data Collection and Preview Builds\Allow Telemetry**. Update Compliance requires at least Basic (level 1) to function.
-
-![Allow Telemetry in Group Policy](images/UC_telemetrylevel.png)
-
-#### Configuring Telemetry level using MDM
-Telemetry level can additionally be configured through a [Mobile Device Management](https://docs.microsoft.com/windows/client-management/mdm/) (MDM) policy. Allow Telemetry is under the [Policy Configuration Service Provider](https://docs.microsoft.com/windows/client-management/mdm/policy-configuration-service-provider) as [System/AllowTelemetry](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-system#system-allowtelemetry).
-
-### Enabling Device Name in telemetry
-Beginning with Windows 10, version 1803, Device Name is no longer collected as part of normal Windows Diagnostic Data and must explicitly be allowed to be sent to Microsoft. If devices do not have this policy enabled, their device name will appear as '#' instead. 
-
-#### Allow Device Name in Telemetry with Group Policy
-Allow Device Name in Telemetry is under the same node as Commercial ID and Allow Telemetry policies in Group Policy, listed as **Allow device name to be sent in Windows diagnostic data**. 
-
-#### Allow Device Name in Telemetry with MDM
-Allow Device Name in Telemetry is under the [Policy Configuration Service Provider](https://docs.microsoft.com/windows/client-management/mdm/policy-configuration-service-provider) as [System/AllowTelemetry](https://docs.microsoft.com/windows/client-management/mdm/policy-csp-system#system-allowtelemetry). 
+Once you've added Update Compliance to a workspace in your Azure subscription, you'll need to configure any devices you want to monitor. There are two ways to configure devices to use Update Compliance.
 
 > [!NOTE]
-> After enrolling your devices (by deploying your CommercialID and Windows Diagnostic Data settings), it might take 48-72 hours for the first data to appear in the solution. Until then, Update Compliance will indicate it is still assessing devices. 
+> After configuring devices via one of the two methods below, it can take up to 72 hours before devices are visible in the solution. Until then, Update Compliance will indicate it is still assessing devices.
+
+### Configure devices using the Update Compliance Configuration Script
+
+The recommended way to configure devices to send data to Update Compliance is using the [Update Compliance Configuration Script](update-compliance-configuration-script.md). The script configures required policies via Group Policy. The script comes with two versions:
+
+- Pilot is more verbose and is intended to be use on an initial set of devices and for troubleshooting.
+- Deployment is intended to be deployed across the entire device population you want to monitor with Update Compliance.  
+
+To download the script and learn what you need to configure and how to troubleshoot errors, see [Configuring Devices using the Update Compliance Configuration Script](update-compliance-configuration-script.md).
+
+### Configure devices manually
+
+It is possible to manually configure devices to send data to Update Compliance, but the recommended method of configuration is to use the [Update Compliance Configuration Script](update-compliance-configuration-script.md). To learn more about configuring devices manually, see [Manually Configuring Devices for Update Compliance](update-compliance-configuration-manual.md).

windows/deployment/update/update-compliance-monitor.md

@@ -20,8 +20,8 @@ ms.topic: article
 > [!IMPORTANT]
 > While [Windows Analytics was retired on January 31, 2020](https://docs.microsoft.com/windows/deployment/update/update-compliance-monitor), support for Update Compliance has continued through the Azure Portal; however, please note the following updates:
 >
-> * On March 31, 2020, the Windows Defender Antivirus reporting feature of Update Compliance will be removed. You can continue to review malware definition status and manage and monitor malware attacks with Microsoft Endpoint Manager's [Endpoint Protection for Microsoft Intune](https://docs.microsoft.com/mem/intune/fundamentals/help-secure-windows-pcs-with-endpoint-protection-for-microsoft-intune). Configuration Manager customers can monitor Endpoint Protection with [Endpoint Protection in Configuration Manager](https://docs.microsoft.com/configmgr/protect/deploy-use/monitor-endpoint-protection).
-> * The Perspectives feature of Update Compliance will also be removed on March 31, 2020 in favor of a better experience. The Perspectives feature is part of the Log Search portal of Log Analytics, which was deprecated on February 15, 2019 in favor of [Azure Monitor Logs](https://docs.microsoft.com/azure/azure-monitor/log-query/log-search-transition). Your Update Compliance solution will be automatically upgraded to Azure Monitor Logs, and the data available in Perspectives will be migrated to a set of queries in the [Needs Attention section](update-compliance-need-attention.md) of Update Compliance.
+> * On March 31, 2020, the Windows Defender Antivirus reporting feature of Update Compliance was retired. You can continue to review malware definition status and manage and monitor malware attacks with Microsoft Endpoint Manager's [Endpoint Protection for Microsoft Intune](https://docs.microsoft.com/mem/intune/fundamentals/help-secure-windows-pcs-with-endpoint-protection-for-microsoft-intune). Configuration Manager customers can monitor Endpoint Protection with [Endpoint Protection in Configuration Manager](https://docs.microsoft.com/configmgr/protect/deploy-use/monitor-endpoint-protection).
+> * The Perspectives feature of Update Compliance was retired on March 31, 2020 in favor of a better experience. The Perspectives feature is part of the Log Search portal of Log Analytics, which was deprecated on February 15, 2019 in favor of [Azure Monitor Logs](https://docs.microsoft.com/azure/azure-monitor/log-query/log-search-transition). Your Update Compliance solution will be automatically upgraded to Azure Monitor Logs, and the data available in Perspectives will be migrated to a set of queries in the [Needs Attention section](update-compliance-need-attention.md) of Update Compliance.
 
 ## Introduction
 
@@ -37,25 +37,9 @@ Update Compliance uses Windows 10 and Windows Defender Antivirus diagnostic data
 
 See the following topics in this guide for detailed information about configuring and using the Update Compliance solution:
 
-- [Get started with Update Compliance](update-compliance-get-started.md): How to add Update Compliance to your environment.
-- [Using Update Compliance](update-compliance-using.md): How to begin using Update Compliance.
+- [Get started with Update Compliance](update-compliance-get-started.md) provides directions on adding Update Compliance to your Azure subscription and configuring devices to send data to Update Compliance.
+- [Using Update Compliance](update-compliance-using.md) breaks down every aspect of the Update Compliance experience.
 
-## Update Compliance architecture
-
-The Update Compliance architecture and data flow follows this process:
-
-1. User computers send diagnostic data to a secure Microsoft data center using the Microsoft Data Management Service.
-2. Diagnostic data is analyzed by the Update Compliance Data Service.
-3. Diagnostic data is pushed from the Update Compliance Data Service to your Azure Monitor workspace.
-4. Diagnostic data is available in the Update Compliance solution.
-
-
-> [!NOTE]
-> This process assumes that Windows diagnostic data is enabled and data sharing is enabled as outlined in the enrollment section of [Get started with Update Compliance](update-compliance-get-started.md).
-
-
-
- 
 ## Related topics
 
 * [Get started with Update Compliance](update-compliance-get-started.md)

windows/deployment/update/update-compliance-privacy.md

@@ -23,25 +23,28 @@ Update Compliance is fully committed to privacy, centering on these tenets:
 - **Security:** Your data is protected with strong security and encryption.
 - **Trust:** Update Compliance supports the Online Services Terms.
 
-
 ## Data flow for Update Compliance
+
 The data flow sequence is as follows:
 
 1. Diagnostic data is sent from devices to the Microsoft Diagnostic Data Management service, which is hosted in the US.
 2. An IT Administrator creates an Azure Log Analytics workspace. They then choose the location this workspace will store data and receives a Commercial ID for that workspace. The Commercial ID is added to each device in an organization by way of Group Policy, MDM or registry key.
-3. Each day Microsoft produces a "snapshot" of IT-focused insights for each workspace in the Diagnostic Data Management Service, identifying devices by Commercial ID. 
+3. Each day Microsoft produces a "snapshot" of IT-focused insights for each workspace in the Diagnostic Data Management Service, identifying devices by Commercial ID.
 4. These snapshots are copied to transient storage, used solely for Update Compliance where they are partitioned by Commercial ID.
-5. The snapshots are then copied to the appropriate Azure Log Analytics workspace, where the Update Compliance experience pulls the information from to populate visuals. 
+5. The snapshots are then copied to the appropriate Azure Log Analytics workspace, where the Update Compliance experience pulls the information from to populate visuals.
 
 ## FAQ
 
 ### Can Update Compliance be used without a direct client connection to the Microsoft Data Management Service?
+
 No, the entire service is powered by Windows diagnostic data, which requires that devices have this direct connectivity.
 
 ### Can I choose the data center location?
+
 Yes for Azure Log Analytics, but no for the Microsoft Data Management Service (which is hosted in the US).
 
 ## Related topics
+
 See related topics for additional background information on privacy and treatment of diagnostic data:
 
 - [Windows 10 and the GDPR for IT Decision Makers](https://docs.microsoft.com/windows/privacy/gdpr-it-guidance)

windows/deployment/update/update-compliance-schema-waasdeploymentstatus.md

@@ -19,13 +19,13 @@ ms.topic: article
 WaaSDeploymentStatus records track a specific update's installation progress on a specific device. Multiple WaaSDeploymentStatus records can exist simultaneously for a given device, as each record is specific to a given update and its type. For example, a device can have both a WaaSDeploymentStatus tracking a Windows Feature Update, as well as one tracking a Windows Quality Update, at the same time.
 
 |Field |Type |Example |Description |
-|-|-|-|-|
+|-|-|-----|------------------------|
 |**Computer** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`JohnPC-Contoso` |User or Organization-provided device name. If this appears as '#', then Device Name may not be sent through telemetry. To enable Device Name to be sent with telemetry, see [Enabling Device Name in Telemetry](https://docs.microsoft.com/windows/deployment/update/update-compliance-get-started#allow-device-name-in-telemetry-with-group-policy). |
 |**ComputerID** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`g:6755412281299915` |Microsoft Global Device Identifier. This is an internal identifier used by Microsoft. A connection to the end-user Managed Service Account (MSA) service is required for this identifier to be populated; no device data will be present in Update Compliance without this identifier. |
 |**DeferralDays** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`0` |The deferral policy for this content type or `UpdateCategory` (Windows `Feature` or `Quality`). |
 |**DeploymentError** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Disk Error` |A readable string describing the error, if any. If empty, there is either no string matching the error or there is no error. |
 |**DeploymentErrorCode** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`8003001E` |Microsoft internal error code for the error, if any. If empty, there is either no error or there is *no error code*, meaning that the issue raised does not correspond to an error, but some inferred issue. |
-|**DeploymentStatus** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Failed` |The high level status of installing this update on this device. Possible values are:<br><li> **Update completed**: Device has completed the update installation.<li> **In Progress**: Device is in one of the various stages of installing an update, detailed in `DetailedStatus`.<li> **Deferred**: A device's deferral policy is preventing the update from being offered by Windows Update.<li> **Cancelled**: The update was cancelled.<li> **Blocked**: There is a hard block on the update being completed. This could be that another update must be completed before this one, or some other task is blocking the installation of the update.<li> ** Unknown**: Update Compliance generated WaaSDeploymentStatus records for devices as soon as it detects an update newer than the one installed on the device. Devices that have not sent any deployment data for that update will have the status `Unknown`.<li> **Update paused**: Devices are paused via Windows Update for Business Pause policies, preventing the update from being offered by Windows Update. <li> **Failed**: Device encountered a failure in the update process, preventing it from installing the update. This may result in an automatic retry in the case of Windows Update, unless the `DeploymentError` indicates the issue requires action before the update can continue.|
+|**DeploymentStatus** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Failed` |The high level status of installing this update on this device. Possible values are:<br><li> **Update completed**: Device has completed the update installation.<li> **In Progress**: Device is in one of the various stages of installing an update, detailed in `DetailedStatus`.<li> **Deferred**: A device's deferral policy is preventing the update from being offered by Windows Update.<li> **Cancelled**: The update was cancelled.<li> **Blocked**: There is a hard block on the update being completed. This could be that another update must be completed before this one, or some other task is blocking the installation of the update.<li> **Unknown**: Update Compliance generated WaaSDeploymentStatus records for devices as soon as it detects an update newer than the one installed on the device. Devices that have not sent any deployment data for that update will have the status `Unknown`.<li> **Update paused**: Devices are paused via Windows Update for Business Pause policies, preventing the update from being offered by Windows Update. <li> **Failed**: Device encountered a failure in the update process, preventing it from installing the update. This may result in an automatic retry in the case of Windows Update, unless the `DeploymentError` indicates the issue requires action before the update can continue.|
 |**DetailedStatus** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Reboot required` |A detailed status for the installation of this update on this device. Possible values are:<br><li> **Update deferred**: When a device's Windows Update for Business policy dictates the update is deferred.<li> **Update paused**: The device's Windows Update for Business policy dictates the update is paused from being offered.<li> **Update offered**: The device has been offered the update, but has not begun downloading it.<li> **Pre-Download tasks passed**: The device has finished all necessary tasks prior to downloading the update.<li> **Compatibility hold**: The device has been placed under a *compatibility hold* to ensure a smooth feature update experience and will not resume the update until the hold has been cleared. For more information see [Feature Update Status report](update-compliance-feature-update-status.md#compatibility-holds).<li> **Download started**: The update has begun downloading on the device.<li> **Download Succeeded**: The update has successfully completed downloading. <li> **Pre-Install Tasks Passed**: Tasks that must be completed prior to installing the update have been completed.<li> **Install Started**: Installation of the update has begun.<li> **Reboot Required**: The device has finished installing the update, and a reboot is required before the update can be completed.<li> **Reboot Pending**: The device has a scheduled reboot to apply the update.<li> **Reboot Initiated**: The scheduled reboot has been initiated.<li> **Commit**: Changes are being committed post-reboot. This is another step of the installation process.<li> **Update Completed**: The update has successfully installed.|
 |**ExpectedInstallDate** |[datetime](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/datetime)|`3/28/2020, 1:00:01.318 PM`|Rather than the expected date this update will be installed, this should be interpreted as the minimum date Windows Update will make the update available for the device. This takes into account Deferrals. |
 |**LastScan** |[datetime](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/datetime)|`3/22/2020, 1:00:01.318 PM`|The last point in time that this device sent Update Session data. |

windows/deployment/update/update-compliance-schema-waasupdatestatus.md

@@ -19,7 +19,7 @@ ms.topic: article
 WaaSUpdateStatus records contain device-centric data and acts as the device record for Update Compliance. Each record provided in daily snapshots map to a single device in a single tenant. This table has data such as the current device's installed version of Windows, whether it is on the latest available updates, and whether the device needs attention.
 
 |Field |Type |Example |Description |
-|--|-|-|-|
+|--|-|----|------------------------|
 |**Computer** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`JohnPC-Contoso` |User or Organization-provided device name. If this appears as '#', then Device Name may not be sent through telemetry. To enable Device Name to be sent with telemetry, see [Enabling Device Name in Telemetry](https://docs.microsoft.com/windows/deployment/update/update-compliance-get-started#allow-device-name-in-telemetry-with-group-policy). |
 |**ComputerID** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`g:6755412281299915` |Microsoft Global Device Identifier. This is an internal identifier used by Microsoft. A connection to the end-user Managed Service Account (MSA) service is required for this identifier to be populated; no device data will be present in Update Compliance without this identifier. |
 |**DownloadMode** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Simple (99)` |The device's Delivery Optimization DownloadMode. To learn about possible values, see [Delivery Optimization Reference - Download mode](https://docs.microsoft.com/windows/deployment/update/waas-delivery-optimization-reference#download-mode) |

windows/deployment/update/update-compliance-schema-wudostatus.md

@@ -21,7 +21,7 @@ ms.topic: article
 
 WUDOStatus records provide information, for a single device, on their bandwidth utilization for a specific content type in the event they use [Delivery Optimization](https://support.microsoft.com/help/4468254/windows-update-delivery-optimization-faq), and other information to create more detailed reports and splice on certain common characteristics.
 
-These fields are briefly described in this article, to learn more about Delivery Optimization in general, check out the [Delivery Optimization Reference](https://docs.microsoft.com/windows/deployment/update/waas-delivery-optimization-reference). **@JAIME**
+These fields are briefly described in this article, to learn more about Delivery Optimization in general, check out the [Delivery Optimization Reference](https://docs.microsoft.com/windows/deployment/update/waas-delivery-optimization-reference).
 
 |Field |Type |Example |Description |
 |-|-|-|-|

windows/deployment/update/update-compliance-wd-av-status.md

@@ -1,47 +0,0 @@
----
-title: Update Compliance - Windows Defender AV Status report
-ms.reviewer: 
-manager: laurawi
-description: an overview of the Windows Defender AV Status report
-ms.prod: w10
-ms.mktglfcycl: deploy
-ms.pagetype: deploy
-audience: itpro
-itproauthor: jaimeo
-author: jaimeo
-ms.author: jaimeo
-ms.collection: M365-analytics
-ms.topic: article
----
-
-# Windows Defender AV Status
-
-
-> [!IMPORTANT]
-> On March 31, 2020, the Windows Defender Antivirus reporting feature of Update Compliance will be removed. You can continue to review malware definition status and manage and monitor malware attacks with Microsoft Endpoint Manager's [Endpoint Protection for Microsoft Intune](https://docs.microsoft.com/mem/intune/fundamentals/help-secure-windows-pcs-with-endpoint-protection-for-microsoft-intune). Configuration Manager customers can monitor Endpoint Protection with [Endpoint Protection in Configuration Manager](https://docs.microsoft.com/configmgr/protect/deploy-use/monitor-endpoint-protection).
-
-![The Windows Defender AV Status report](images/UC_workspace_WDAV_status.png)
-
-The Windows Defender AV Status section deals with data concerning signature and threat status for devices that use Windows Defender Antivirus. The section tile in the [Overview Blade](update-compliance-using.md#overview-blade) provides the percentage of devices with insufficient protection – this percentage only considers devices using Windows Defender Antivirus.
-
-> [!NOTE]
-> Update Compliance's Windows Defender Antivirus status is compatible with E3, B, F1, VL Professional and below licenses. Devices with an E5 license are not shown here; devices with an E5 license can be monitored using the [Windows Defender ATP portal](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-atp/configure-endpoints-windows-defender-advanced-threat-protection). If you'd like to learn more about Windows 10 licensing, see the [Windows 10 product licensing options](https://www.microsoft.com/Licensing/product-licensing/windows10.aspx). 
-
-## Windows Defender AV Status sections
-The **Protection Status** blade gives a count for devices that have either out-of-date signatures or real-time protection turned off. Below, it gives a more detailed breakdown of the two issues. Selecting any of these statuses will navigate you to a Log Search view containing the query. 
-
-The **Threat Status** blade shows, among devices that have encountered threats, how many were and were not remediated successfully. It also provides a detailed count. Selecting either of these will take you to the respective query in Log Search for further investigation. 
-
-Here are some important terms to consider when using the Windows Defender AV Status section of Update Compliance:
-* **Signature out of date** devices are devices with a signature older than 14 days.
-* **No real-time protection** devices are devices that are using Windows Defender AV but have turned off real-time protection.
-* **Recently disappeared** devices are devices that were previously seen by Windows Defender AV and are no longer seen in the past 7 days.
-* **Remediation failed** devices are devices where Windows Defender AV failed to remediate the threat. This could be due to a number of reasons, including a full disk, network error, operation aborted, etc. Manual intervention might be needed from IT team.
-* **Not assessed** devices are devices where either a non-Microsoft AV solution is used or it has been more than 7 days since the device recently disappeared.
-
-## Windows Defender data latency
-Because of the way Windows Defender is associated with the rest of Windows device data, Defender data for new devices might take much longer to appear than other data types. This process could take up to 28 days. 
-
-## Related topics
-
-- [Windows Defender Antivirus pre-requisites](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-antivirus/troubleshoot-reporting#confirm-pre-requisites)

windows/security/threat-protection/microsoft-defender-atp/attack-surface-reduction-rules-in-windows-10-enterprise-e3.md

@@ -11,7 +11,6 @@ ms.pagetype: security
 ms.localizationpriority: medium
 author: denisebmsft
 ms.author: deniseb
-ms.date: 10/15/2018
 ms.reviewer: 
 manager: dansimp
 ms.custom: asr

windows/security/threat-protection/microsoft-defender-atp/attack-surface-reduction.md

@@ -101,7 +101,7 @@ The following sections describe each of the 15 attack surface reduction rules. T
 [Block executable files from running unless they meet a prevalence, age, or trusted list criterion](#block-executable-files-from-running-unless-they-meet-a-prevalence-age-or-trusted-list-criterion) | 01443614-cd74-433a-b99e-2ecdc07bfc25 | Supported
 [Use advanced protection against ransomware](#use-advanced-protection-against-ransomware) | c1db55ab-c21a-4637-bb3f-a12568109d35 | Supported
 [Block credential stealing from the Windows local security authority subsystem (lsass.exe)](#block-credential-stealing-from-the-windows-local-security-authority-subsystem) | 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2 | Supported
-[Block process creations originating from PSExec and WMI commands](#block-process-creations-originating-from-psexec-and-wmi-commands) | d1e49aac-8f56-4280-b9ba-993a6d77406c | Not supported
+[Block process creations originating from PSExec and WMI commands](#block-process-creations-originating-from-psexec-and-wmi-commands) | d1e49aac-8f56-4280-b9ba-993a6d77406c | Supported
 [Block untrusted and unsigned processes that run from USB](#block-untrusted-and-unsigned-processes-that-run-from-usb) | b2b3f03d-6a65-4f7b-a9c7-1c7ef74a9ba4 | Supported
 [Block Office communication application from creating child processes](#block-office-communication-application-from-creating-child-processes) | 26190899-1602-49e8-8b27-eb1d0a1ce869 | Supported
 [Block Adobe Reader from creating child processes](#block-adobe-reader-from-creating-child-processes) | 7674ba52-37eb-4a4f-a9a1-f0f9a1619a2c | Supported
@@ -273,9 +273,6 @@ GUID: 9e6c4e1f-7d60-472f-ba1a-a39ef669e4b2
 
 This rule blocks processes created through [PsExec](https://docs.microsoft.com/sysinternals/downloads/psexec) and [WMI](https://docs.microsoft.com/windows/win32/wmisdk/about-wmi) from running. Both PsExec and WMI can remotely execute code, so there is a risk of malware abusing this functionality for command and control purposes, or to spread an infection throughout an organization's network.
 
-> [!IMPORTANT]
-> File and folder exclusions do not apply to this attack surface reduction rule.
-
 > [!WARNING]
 > Only use this rule if you're managing your devices with [Intune](https://docs.microsoft.com/intune) or another MDM solution. This rule is incompatible with management through [Microsoft Endpoint Configuration Manager](https://docs.microsoft.com/configmgr) because this rule blocks WMI commands the Configuration Manager client uses to function correctly.
 

windows/security/threat-protection/windows-defender-application-control/create-code-signing-cert-for-windows-defender-application-control.md

@@ -27,7 +27,7 @@ ms.date: 02/28/2018
 -   Windows 10
 -   Windows Server 2016
 
-As you deploy Windows Defender Application Control (WDAC) (also part of Windows Defender Device Guard), you might need to sign catalog files or WDAC policies internally. To do this, you will either need a publicly issued code signing certificate or an internal CA. If you have purchased a code signing certificate, you can skip this topic and instead follow other topics listed in the [Windows Defender Application Control Deployment Guide](windows-defender-application-control-deployment-guide.md). 
+As you deploy Windows Defender Application Control (WDAC), you might need to sign catalog files or WDAC policies internally. To do this, you will either need a publicly issued code signing certificate or an internal CA. If you have purchased a code signing certificate, you can skip this topic and instead follow other topics listed in the [Windows Defender Application Control Deployment Guide](windows-defender-application-control-deployment-guide.md). 
 
 If you have an internal CA, complete these steps to create a code signing certificate. 
 Only RSA algorithm is supported for the code signing certificate, and signatures must be PKCS 1.5 padded. 
@@ -98,7 +98,7 @@ Now that the template is available to be issued, you must request one from the c
 >[!NOTE]
 >If a certificate manager is required to approve any issued certificates and you selected to require management approval on the template, the request will need to be approved in the CA before it will be issued to the client.
 
-This certificate must be installed in the user’s personal store on the computer that will be signing the catalog files and code integrity policies. If the signing is going to be taking place on the computer on which you just requested the certificate, exporting the certificate to a .pfx file will not be required because it already exists in your personal store. If you are signing on another computer, you will need to export the .pfx certificate with the necessary keys and properties. To do so, complete the following steps:
+This certificate must be installed in the user's personal store on the computer that will be signing the catalog files and code integrity policies. If the signing is going to be taking place on the computer on which you just requested the certificate, exporting the certificate to a .pfx file will not be required because it already exists in your personal store. If you are signing on another computer, you will need to export the .pfx certificate with the necessary keys and properties. To do so, complete the following steps:
 
 1.  Right-click the certificate, point to **All Tasks**, and then click **Export**.
 

windows/security/threat-protection/windows-defender-application-control/deploy-catalog-files-to-support-windows-defender-application-control.md

@@ -81,7 +81,7 @@ To create a catalog file, you use a tool called **Package Inspector**. You must
     `PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName`
 
 >[!NOTE]
->Package Inspector catalogs the hash values for each discovered binary file. If the applications that were scanned are updated, complete this process again to trust the new binaries’ hash values.
+>Package Inspector catalogs the hash values for each discovered binary file. If the applications that were scanned are updated, complete this process again to trust the new binaries' hash values.
 
 When finished, the files will be saved to your desktop. You can double-click the \*.cat file to see its contents, and you can view the \*.cdf file with a text editor. 
 
@@ -95,16 +95,16 @@ Packages can fail for the following reasons:
     - To diagnose whether USN journal size is the issue, after running through Package Inspector, click Start > install app > PackageInspector stop
         - Get the value of the reg key at HKEY\_CURRENT\_USER/PackageInspectorRegistryKey/c: (this was the most recent USN when you ran PackageInspector start)
         - `fsutil usn readjournal C: startusn=RegKeyValue > inspectedusn.txt`
-        - ReadJournal command should throw an error if the older USNs don’t exist anymore due to overflow
+        - ReadJournal command should throw an error if the older USNs don't exist anymore due to overflow
     - For USN Journal, log size can be expanded using: `fsutil usn createjournal` command with a new size and alloc delta. `Fsutil usn queryjournal` will give the current size and allocation delta, so using a multiple of that may help
     - To diagnose whether Eventlog size is the issue, look at the Microsoft/Windows/CodeIntegrity/Operational log under Applications and Services logs in Event Viewer and ensure that there are entries present from when you began Package Inspector (You can use write time as a justification; if you started the install 2 hours ago and there are only entries from 30 minutes prior, the log is definitely too small)
     - To increase Eventlog size, in Event Viewer you can right click the operational log, click properties, and then set new values (some multiple of what it was previously)
 - Package files that change hash each time the package is installed
     - Package Inspector is completely incompatible if files in the package (temporary or otherwise) change hash each time the package is installed. You can diagnose this by looking at the hash field in the 3077 block events when the package is failing in enforcement.  If each time you attempt to run the package you get a new block event with a different hash, the package will not work with Package Inspector
-- Files with an invalid signature blob or otherwise “unhashable” files
+- Files with an invalid signature blob or otherwise "unhashable" files
     - This issue arises when a file that has been signed is modified post signing in a way that invalidates the PE header and renders the file unable to be hashed by the Authenticode Spec.
-    - WDAC uses Authenticode Hashes to validate files when they are running. If the file is unhashable via the authenticode SIP, there is no way to identify the file to allow it, regardless of if you attempt to add the file to the policy directly, or re-sign the file with a Package Inspector catalog (the signature is invalidated due to file being edited, file can’t be allowed by hash due to authenticode hashing algorithm rejecting it)
-    - Recent versions of InstallShield packages that use custom actions can hit this. If the DLL input to the custom action was signed before being put through InstallShield, InstallShield adds tracking markers to the file (editing it post signature) which leaves the file in this “unhashable” state and renders the file unable to be allowed by Device Guard (regardless of if you try to allow directly by policy or resign with Package Inspector)
+    - WDAC uses Authenticode Hashes to validate files when they are running. If the file is unhashable via the authenticode SIP, there is no way to identify the file to allow it, regardless of if you attempt to add the file to the policy directly, or re-sign the file with a Package Inspector catalog (the signature is invalidated due to file being edited, file can't be allowed by hash due to authenticode hashing algorithm rejecting it)
+    - Recent versions of InstallShield packages that use custom actions can hit this. If the DLL input to the custom action was signed before being put through InstallShield, InstallShield adds tracking markers to the file (editing it post signature) which leaves the file in this "unhashable" state and renders the file unable to be allowed by Windows Defender (regardless of if you try to allow directly by policy or resign with Package Inspector)
 
 ## Catalog signing with SignTool.exe
 
@@ -124,7 +124,7 @@ To sign the existing catalog file, copy each of the following commands into an e
     
    `$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"`
 
-2. Import the code signing certificate that will be used to sign the catalog file. Import it to the signing user’s personal store. 
+2. Import the code signing certificate that will be used to sign the catalog file. Import it to the signing user's personal store. 
 
 3. Sign the catalog file with Signtool.exe:
 

windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-group-policy.md

@@ -24,7 +24,7 @@ ms.date: 02/28/2018
 -   Windows 10
 -   Windows Server 2016
 
-WDAC policies can easily be deployed and managed with Group Policy. A Windows Defender Device Guard administrative template will be available in Windows Server 2016 that allows you to simplify deployment of Windows Defender Device Guard hardware-based security features and Windows Defender Application Control policies. The following procedure walks you through how to deploy a WDAC policy called **DeviceGuardPolicy.bin** to a test OU called *DG Enabled PCs* by using a GPO called **Contoso GPO Test**.
+WDAC policies can easily be deployed and managed with Group Policy. Windows Defender allows you to simplify deployment Windows Defender hardware-based security features and Windows Defender Application Control policies. The following procedure walks you through how to deploy a WDAC policy called **DeviceGuardPolicy.bin** to a test OU called *DG Enabled PCs* by using a GPO called **Contoso GPO Test**.
 
 > [!NOTE]
 > This walkthrough requires that you have previously created a WDAC policy and have a computer running Windows 10 on which to test a Group Policy deployment. For more information about how to create a WDAC policy, see [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md), earlier in this topic.

windows/security/threat-protection/windows-defender-application-control/use-code-signing-to-simplify-application-control-for-classic-windows-applications.md

@@ -31,7 +31,7 @@ This topic covers guidelines for using code signing control classic Windows apps
 
 ## Reviewing your applications: application signing and catalog files 
 
-Typically, WDAC policies are configured to use the application's signing certificate as part or all of what identifies the application as trusted. This means that applications must either use embedded signing—where the signature is part of the binary—or catalog signing, where you generate a “catalog file” from the applications, sign it, and through the signed catalog file, configure the WDAC policy to recognize the applications as signed.
+Typically, WDAC policies are configured to use the application's signing certificate as part or all of what identifies the application as trusted. This means that applications must either use embedded signing—where the signature is part of the binary—or catalog signing, where you generate a "catalog file" from the applications, sign it, and through the signed catalog file, configure the WDAC policy to recognize the applications as signed.
 
 Catalog files can be very useful for unsigned LOB applications that cannot easily be given an embedded signature. However, catalogs need to be updated each time an application is updated. In contrast, with embedded signing, your WDAC policies typically do not have to be updated when an application is updated. For this reason, if code-signing is or can be included in your in-house application development process, it can simplify the management of WDAC (compared to using catalog signing).
 
@@ -45,7 +45,7 @@ To obtain signed applications or embed signatures in your in-house applications,
 
 To use catalog signing, you can choose from the following options:
 
-- Use the Windows Defender Device Guard signing portal available in the Microsoft Store for Business and Education. The portal is a Microsoft web service that you can use to sign your Classic Windows applications. For more information, see [Device Guard signing](https://technet.microsoft.com/itpro/windows/manage/device-guard-signing-portal).
+- Use the Windows Defender signing portal available in the Microsoft Store for Business and Education. The portal is a Microsoft web service that you can use to sign your Classic Windows applications. 
 
 - Create your own catalog files, which are described in the next section. 
 
@@ -53,12 +53,12 @@ To use catalog signing, you can choose from the following options:
 
 Catalog files (which you can create in Windows 10 with a tool called Package Inspector) contain information about all deployed and executed binary files associated with your trusted but unsigned applications. When you create catalog files, you can also include signed applications for which you do not want to trust the signer but rather the specific application. After creating a catalog, you must sign the catalog file itself by using enterprise public key infrastructure (PKI), or a purchased code signing certificate. Then you can distribute the catalog, so that your trusted applications can be handled by WDAC in the same way as any other signed application.
 
-Catalog files are simply Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries’ hash values are updated each time an application is updated, which requires the catalog file to be updated also.
+Catalog files are simply Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries' hash values are updated each time an application is updated, which requires the catalog file to be updated also.
 
 After you have created and signed your catalog files, you can configure your WDAC policies to trust the signer or signing certificate of those files.
 
 > [!NOTE]
-> Package Inspector only works on operating systems that support Windows Defender Device Guard, such as Windows 10 Enterprise, Windows 10 Education, Windows 2016 Server, or Windows Enterprise IoT.
+> Package Inspector only works on operating systems that support Windows Defender, such as Windows 10 Enterprise, Windows 10 Education, Windows 2016 Server, or Windows Enterprise IoT.
 
 For procedures for working with catalog files, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md).
 

windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide.md

@@ -29,20 +29,20 @@ This topic provides a roadmap for planning and getting started on the Windows De
 
 1. Review requirements, especially hardware requirements for VBS. 
 
-2. Group devices by degree of control needed. Do most devices fit neatly into a few categories, or are they scattered across all categories? Are users allowed to install any application or must they choose from a list? Are users allowed to use their own peripheral devices?<br>Deployment is simpler if everything is locked down in the same way, but meeting individual departments’ needs, and working with a wide variety of devices, may require a more complicated and flexible deployment.
+2. Group devices by degree of control needed. Do most devices fit neatly into a few categories, or are they scattered across all categories? Are users allowed to install any application or must they choose from a list? Are users allowed to use their own peripheral devices?<br>Deployment is simpler if everything is locked down in the same way, but meeting individual departments' needs, and working with a wide variety of devices, may require a more complicated and flexible deployment.
 
 3. Review how much variety in software and hardware is needed by roles or departments. The following questions can help you clarify how many WDAC policies to create:
 
    - How standardized is the hardware?<br>This can be relevant because of drivers. You could create a WDAC policy on hardware that uses a particular set of drivers, and if other drivers in your environment use the same signature, they would also be allowed to run. However, you might need to create several WDAC policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment.
 
-   - What software does each department or role need? Should they be able to install and run other departments’ software?<br>If multiple departments are allowed to run the same list of software, you might be able to merge several WDAC policies to simplify management.
+   - What software does each department or role need? Should they be able to install and run other departments' software?<br>If multiple departments are allowed to run the same list of software, you might be able to merge several WDAC policies to simplify management.
          
    - Are there departments or roles where unique, restricted software is used?<br>If one department needs to run an application that no other department is allowed, it might require a separate WDAC policy. Similarly, if only one department must run an old version of an application (while other departments allow only the newer version), it might require a separate WDAC policy.
 
    - Is there already a list of accepted applications?<br>A list of accepted applications can be used to help create a baseline WDAC policy.<br>As of Windows 10, version 1703, it might also be useful to have a list of plug-ins, add-ins, or modules that you want to allow only in a specific app (such as a line-of-business app). Similarly, it might be useful to have a list of plug-ins, add-ins, or modules that you want to block in a specific app (such as a browser).
 
    - As part of a threat review process, have you reviewed systems for software that can load arbitrary DLLs or run code or scripts? 
-     In day-to-day operations, your organization’s security policy may allow certain applications, code, or scripts to run on your systems depending on their role and the context. However, if your security policy requires that you run only trusted applications, code, and scripts on your systems, you may decide to lock these systems down securely with Windows Defender Application Control policies. 
+     In day-to-day operations, your organization's security policy may allow certain applications, code, or scripts to run on your systems depending on their role and the context. However, if your security policy requires that you run only trusted applications, code, and scripts on your systems, you may decide to lock these systems down securely with Windows Defender Application Control policies. 
     
      Legitimate applications from trusted vendors provide valid functionality. However, an attacker could also potentially use that same functionality to run malicious executable code that could bypass WDAC.
 
@@ -70,7 +70,7 @@ This topic provides a roadmap for planning and getting started on the Windows De
 
 ## Known issues
 
-This section covers known issues with WDAC and Device Guard. Virtualization-based protection of code integrity may be incompatible with some devices and applications, which might cause unexpected failures, data loss, or a blue screen error (also called a stop error). 
+This section covers known issues with WDAC. Virtualization-based protection of code integrity may be incompatible with some devices and applications, which might cause unexpected failures, data loss, or a blue screen error (also called a stop error). 
 Test this configuration in your lab before enabling it in production. 
 
 ### MSI Installations are blocked by WDAC