fixing conflicts

This commit is contained in:
Dani Halfin
2020-05-05 17:46:51 -07:00
658 changed files with 8303 additions and 6333 deletions

View File

@ -14,7 +14,7 @@ manager: laurawi
ms.topic: article
ms.custom: seo-marvel-apr2020
---
# How to make Features on Demand and language packs available when you're using WSUS/SCCM
# How to make Features on Demand and language packs available when you're using WSUS or Configuration Manager
> Applies to: Windows 10
@ -26,6 +26,6 @@ In Windows 10 version 1709 and 1803, changing the **Specify settings for optiona
In Windows 10 version 1809 and beyond, changing the **Specify settings for optional component installation and component repair** policy also influences how language packs are acquired, however language packs can only be acquired directly from Windows Update. It's currently not possible to acquire them from a network share. Specifying a network location works for FOD packages or corruption repair, depending on the content at that location.
For all OS versions, changing the **Specify settings for optional component installation and component repair** policy does not affect how OS updates are distributed. They continue to come from WSUS or SCCM or other sources as you have scheduled them, even while optional content is sourced from Windows Update or a network location.
For all OS versions, changing the **Specify settings for optional component installation and component repair** policy does not affect how OS updates are distributed. They continue to come from WSUS, Configuration Manager, or other sources as you have scheduled them, even while optional content is sourced from Windows Update or a network location.
Learn about other client management options, including using Group Policy and administrative templates, in [Manage clients in Windows 10](https://docs.microsoft.com/windows/client-management/).

View File

@ -107,7 +107,7 @@ When users start scanning in Windows Update through the Settings panel, the foll
|MU|7971f918-a847-4430-9279-4a52d1efe18d|
|Store|855E8A7C-ECB4-4CA3-B045-1DFA50104289|
|OS Flighting|8B24B027-1DEE-BABB-9A95-3517DFB9C552|
|WSUS or SCCM|Via ServerSelection::ssManagedServer <br>3DA21691-E39D-4da6-8A4B-B43877BCB1B7 |
|WSUS or Configuration Manager|Via ServerSelection::ssManagedServer <br>3DA21691-E39D-4da6-8A4B-B43877BCB1B7 |
|Offline scan service|Via IUpdateServiceManager::AddScanPackageService|
#### Finds network faults
@ -118,9 +118,9 @@ Common update failure is caused due to network issues. To find the root of the i
- The WU client uses SLS (Service Locator Service) to discover the configurations and endpoints of Microsoft network update sources WU, MU, Flighting.
> [!NOTE]
> Warning messages for SLS can be ignored if the search is against WSUS/SCCM.
> Warning messages for SLS can be ignored if the search is against WSUS or Configuration Manager.
- On sites that only use WSUS/SCCM, the SLS may be blocked at the firewall. In this case the SLS request will fail, and can't scan against Windows Update or Microsoft Update but can still scan against WSUS/SCCM, since it's locally configured.
- On sites that only use WSUS or Configuration Manager, the SLS may be blocked at the firewall. In this case the SLS request will fail, and cant scan against Windows Update or Microsoft Update but can still scan against WSUS or Configuration Manager, since its locally configured.
![Windows Update scan log 3](images/update-scan-log-3.png)
## Downloading updates

Binary file not shown.

Before

Width:  |  Height:  |  Size: 37 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 171 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 280 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 123 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 92 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 130 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 29 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 83 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 86 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 56 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 56 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 642 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 9.3 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 796 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 150 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 50 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 135 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 30 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 110 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 120 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 29 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 345 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 68 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 157 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 47 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 32 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 76 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 28 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 14 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 16 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 21 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 68 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 71 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 31 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 70 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 4.7 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 103 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 73 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 35 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 203 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 46 KiB

Binary file not shown.

Before

Width:  |  Height:  |  Size: 48 KiB

View File

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

View File

@ -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://www.microsoft.com/en-us/download/details.aspx?id=101086). 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.|

View File

@ -40,8 +40,6 @@ Refer to the following list for what each state means:
Microsoft uses diagnostic data to determine whether devices that use Windows Update are ready for a feature update in order to ensure a smooth experience. When Microsoft determines a device is not ready to update due to a known issue, a *compatibility hold* is generated to delay the device's upgrade and safeguard the end-user experience. Holds are released over time as diagnostic data is analyzed and fixes are addressed. Details are provided on some, but not all compatibility holds on the Windows 10 release information page for any given release.
To learn how compatibility holds are reflected in the experience, see [Update compliance perspectives](update-compliance-perspectives.md#deployment-status).
### Opting out of compatibility hold
Microsoft will release a device from a compatibility hold when it has determined it can safely and smoothly install a feature update, but you are ultimately in control of your devices and can opt out if desired. To opt out, set the registry key **HKLM\Software\Microsoft\Windows NT\CurrentVersion\502505fe-762c-4e80-911e-0c3fa4c63fb0** to a name of **DataRequireGatedScanForFeatureUpdates** and a value of **0**.

View File

@ -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,113 +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 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 solutions 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)
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.
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)
> [!IMPORTANT]
> 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.
## 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.
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.
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.
> [!NOTE]
> 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.
![Update Compliance Settings page](images/UC_commercialID.png)
### Configure devices using the Update Compliance Configuration Script
>**Important**
>
>Regenerate your Commercial ID only if your Original ID key 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.
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:
#### 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**.
- 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.
![Commercial ID Group Policy location](images/UC_commercialID_GP.png)
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).
#### 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).
### Configure devices manually
### 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).
>[!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.
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).

View File

@ -19,11 +19,9 @@ ms.custom: seo-marvel-apr2020
# Monitor Windows Updates with Update Compliance
> [!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 define and review security compliance policies using [Microsoft Endpoint Manager](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager), which allows finer control over security features and updates.
> * 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.
> 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. Two planned feature removals for Update Compliance Windows Defender Antivirus reporting and Perspectives are now scheduled to be removed beginning Monday, May 11, 2020.
> * The retirement of Windows Defender Antivirus reporting will begin Monday, May 11, 2020. 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 be retired Monday, May 11, 2020. 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.
Update Compliance enables organizations to:
@ -33,30 +31,15 @@ Update Compliance enables organizations to:
Update Compliance is offered through the Azure portal, and is included as part of Windows 10 licenses listed in the [prerequisites](update-compliance-get-started.md#update-compliance-prerequisites).
Update Compliance uses Windows 10 and Windows Defender Antivirus diagnostic data for all of its reporting. It collects system data including update deployment progress, [Windows Update for Business](waas-manage-updates-wufb.md) configuration data, Windows Defender Antivirus data, and Delivery Optimization usage data, and then sends this data to a secure cloud to be stored for analysis and usage in [Azure Log Analytics](https://docs.microsoft.com/azure/log-analytics/query-language/get-started-analytics-portal).
Update Compliance uses Windows 10 diagnostic data for all of its reporting. It collects system data including update deployment progress, [Windows Update for Business](waas-manage-updates-wufb.md) configuration data, and Delivery Optimization usage data, and then sends this data to a customer-owned [Azure Log Analytics](https://docs.microsoft.com/azure/log-analytics/query-language/get-started-analytics-portal) workspace to power the experience.
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)<BR>
[Use Update Compliance to monitor Windows Updates](update-compliance-using.md)
* [Get started with Update Compliance](update-compliance-get-started.md)
* [Use Update Compliance to monitor Windows Updates](update-compliance-using.md)
* [Update Compliance Schema Reference](update-compliance-schema.md)

View File

@ -20,8 +20,8 @@ ms.custom: seo-marvel-apr2020
The **Needs attention!** section provides a breakdown of all Windows 10 device and update issues detected by Update Compliance. The summary tile for this section counts the number of devices that have issues, while the blades within break down the issues encountered. Finally, a [list of queries](#list-of-queries) blade in this section contains queries that provide values but do not fit within any other main section.
>[!NOTE]
>The summary tile counts the number of devices that have issues, while the blades within the section break down the issues encountered. A single device can have more than one issue, so these numbers might not add up.
> [!NOTE]
> The summary tile counts the number of devices that have issues, while the blades within the section break down the issues encountered. A single device can have more than one issue, so these numbers might not add up.
The different issues are broken down by Device Issues and Update Issues:
@ -40,8 +40,8 @@ The different issues are broken down by Device Issues and Update Issues:
Selecting any of the issues will take you to a [Log Analytics](https://docs.microsoft.com/azure/log-analytics/query-language/get-started-analytics-portal) view with all devices that have the given issue.
>[!NOTE]
>This blade also has a link to the [Setup Diagnostic Tool](https://docs.microsoft.com/windows/deployment/upgrade/setupdiag), a standalone tool you can use to obtain details about why a Windows 10 feature update was unsuccessful.
> [!NOTE]
> This blade also has a link to the [Setup Diagnostic Tool](https://docs.microsoft.com/windows/deployment/upgrade/setupdiag), a standalone tool you can use to obtain details about why a Windows 10 feature update was unsuccessful.
## List of Queries

View File

@ -1,71 +0,0 @@
---
title: Update Compliance - Perspectives
ms.reviewer:
manager: laurawi
description: This article contains an overview of Update Compliance Perspectives, which provide elaborations on specific queries.
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
ms.custom: seo-marvel-apr2020
---
# Perspectives
> [!IMPORTANT]
> On March 31, 2020, the Perspectives feature of Update Compliance will be removed 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.
![Perspectives data view](images/uc-perspectiveupdatedeploymentstatus.png)
Perspectives are elaborations on specific queries hand-crafted by developers which data views that provide deeper insight into your data. Perspectives are loaded whenever clicking into more detailed views from both the Security Update Status section and Feature Update Status section of Update Compliance.
There is only one perspective framework; it is for **Update Deployment Status**. The same framework is utilized for both feature and quality updates.
The first blade is the **Build Summary** blade. This blade summarizes the most important aspects of the given build being queried, listing the total number of devices, the total number of update failures for the build, and a breakdown of the different errors encountered.
The second blade is the **Deferral Configurations** blade, breaking down Windows Update for Business deferral settings (if any).
## Deployment status
The third blade is the **Deployment Status** blade. This defines how many days it has been since the queried version has been released, and breaks down the various states in the update funnel each device has reported to be in. The possible states are as follows:
| State | Description |
| --- | --- |
| Update Completed | When a device has finished the update process and is on the queried update, it will display here as Update completed. |
| In Progress | Devices that report they are "In Progress" are one of the various stages of installing an update; these stages are reported in the Detailed Deployment Status blade. |
| Deferred | When a device's Windows Update for Business deferral policy dictates that the update is not yet applicable due to deferral, it will report as such in this blade. |
| Progress stalled | Devices that report as "Progress stalled" have been stuck at "In progress" for more than 7 days. |
| Cancelled | The update was canceled. |
| 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. |
| Unknown | Devices that do not report detailed information on the status of their updates will report Unknown. This is most likely devices that do not use Windows Update for deployment. |
| Update paused | These devices have Windows Update for Business pause enabled, preventing this update from being installed. |
| Failed | A device is unable to install an update. This failure could be linked to a serious error in the update installation process or, in some cases, a [compatibility hold](update-compliance-feature-update-status.md#compatibility-holds). |
## Detailed deployment status
The final blade is the **Detailed Deployment Status** blade. This blade breaks down the detailed stage of deployment a device is in, beyond the generalized terms defined in Deployment Status. The following are the possible stages a device can report:
| State | Description |
| --- | --- |
| Update deferred | When a device's Windows Update for Business policy dictates the update is deferred. |
| Update paused | The device's Windows Update for Business policy dictates the update is paused from being offered. |
| Update offered | The device has been offered the update, but has not begun downloading it. |
| Pre-Download tasks passed | The device has finished all necessary tasks prior to downloading the update. |
| 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) |
| Download Started | The update has begun downloading on the device. |
| Download Succeeded | The update has successfully completed downloading. |
| Pre-Install Tasks Passed | Tasks that must be completed prior to installing the update have been completed. |
| Install Started | Installation of the update has begun. |
| Reboot Required | The device has finished installing the update, and a reboot is required before the update can be completed.
| Reboot Pending | The device has a scheduled reboot to apply the update. |
| Reboot Initiated | The scheduled reboot has been initiated. |
| Update Completed/Commit | The update has successfully installed. |
> [!NOTE]
> Interacting with any rows in the perspective view will automatically apply the given value to the query and execute it with the new parameter, narrowing the perspective to devices that satisfy that criteria. For example, clicking "Not configured (-1)" devices in Deferral Configurations will filter the query to only contain devices that do not have a deferral configuration. These filters can also be applied to queries via the filter sidebar.

View File

@ -0,0 +1,55 @@
---
title: Privacy in Update Compliance
ms.reviewer:
manager: laurawi
description: an overview of the Feature Update 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
---
# Privacy in Update Compliance
Update Compliance is fully committed to privacy, centering on these tenets:
- **Transparency:** Windows 10 diagnostic data events that are required for Update Compliance's operation are fully documented (see the links for additional information) so you can review them with your company's security and compliance teams. The Diagnostic Data Viewer lets you see diagnostic data sent from a given device (see [Diagnostic Data Viewer Overview](https://docs.microsoft.com/windows/configuration/diagnostic-data-viewer-overview) for details).
- **Control:** You ultimately control the level of diagnostic data you wish to share. In Windows 10, version 1709 we added a new policy to Limit enhanced diagnostic data to the minimum required by Windows Analytics.
- **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.
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.
## 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)
- [Configure Windows diagnostic data in your organization](https://docs.microsoft.com/windows/configuration/configure-windows-diagnostic-data-in-your-organization)
- [Diagnostic Data Viewer Overview](https://docs.microsoft.com/windows/configuration/diagnostic-data-viewer-overview)
- [Licensing Terms and Documentation](https://www.microsoftvolumelicensing.com/DocumentSearch.aspx?Mode=3&DocumentTypeId=31)
- [Confidence in the trusted cloud](https://azure.microsoft.com/support/trust-center/)
- [Trust Center](https://www.microsoft.com/trustcenter)

View File

@ -0,0 +1,46 @@
---
title: Update Compliance Schema - WaaSDeploymentStatus
ms.reviewer:
manager: laurawi
description: WaaSDeploymentStatus schema
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
---
# WaaSDeploymentStatus
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.|
|**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. |
|**OriginBuild** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`18363.719` |The build originally installed on the device when this Update Session began. |
|**OSBuild** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`18363.719` |The build currently installed on the device. |
|**OSRevisionNumber** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`719` |The revision of the OSBuild installed on the device. |
|**OSServicingBranch** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Semi-Annual` |The Servicing Branch or [Servicing Channel](https://docs.microsoft.com/windows/deployment/update/waas-overview#servicing-channels) the device is on. Dictates which Windows updates the device receives and the cadence of those updates. |
|**OSVersion** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`1909` |The version of Windows 10. This typically is of the format of the year of the version's release, following the month. In this example, `1909` corresponds to 2019-09 (September). This maps to the `Major` portion of OSBuild. |
|**PauseState** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`NotConfigured` |The on-client Windows Update for Business Pause state. Reflects whether or not a device has paused Feature Updates.<br><li> **Expired**: The pause period has expired.<li> **NotConfigured**: Pause is not configured.<li> **Paused**: The device was last reported to be pausing this content type.<li> **NotPaused**: The device was last reported to not have any pause on this content type. |
|**RecommendedAction** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) | |The recommended action to take in the event this device needs attention, if any. |
|**ReleaseName** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`KB4551762` |The KB Article corresponding to the TargetOSRevision, if any. |
|**TargetBuild** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`18363.720` |The target OSBuild, the update being installed or considered as part of this WaaSDeploymentStatus record. |
|**TargetOSVersion** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`1909` |The target OSVersion. |
|**TargetOSRevision** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`720` |The target OSRevisionNumber. |
|**TimeGenerated** |[datetime](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/datetime) |`3/22/2020, 1:00:01.318 PM`|A DateTime corresponding to the moment Azure Monitor Logs ingested this record to your Log Analytics workspace. |
|**UpdateCategory** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Quality` |The high-level category of content type this Windows Update belongs to. Possible values are **Feature** and **Quality**. |
|**UpdateClassification** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Security` |Similar to UpdateCategory, this more specifically determines whether a Quality update is a security update or not. |
|**UpdateReleasedDate** |[datetime](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/datetime) |`3/22/2020, 1:00:01.318 PM`|A DateTime corresponding to the time the update came available on Windows Update. |

View File

@ -0,0 +1,35 @@
---
title: Update Compliance Schema - WaaSInsiderStatus
ms.reviewer:
manager: laurawi
description: WaaSInsiderStatus schema
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
---
# WaaSInsiderStatus
WaaSInsiderStatus records contain device-centric data and acts as the device record for devices on Windows Insider Program builds in 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. Insider devices have fewer fields than [WaaSUpdateStatus](update-compliance-schema-waasupdatestatus.md).
|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. |
|**OSArchitecture** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`amd64` |The architecture of the Operating System. |
|**OSName** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Windows 10` |The name of the Operating System. This will always be Windows 10 for Update Compliance. |
|**OSVersion** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`1909` |The version of Windows 10. This typically is of the format of the year of the version's release, following the month. In this example, `1909` corresponds to 2019-09 (September). This maps to the `Major` portion of OSBuild. |
|**OSBuild** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`18363.720` |The currently-installed Windows 10 Build, in the format `Major`.`Revision`. `Major` corresponds to which Feature Update the device is on, whereas `Revision` corresponds to which quality update the device is on. Mappings between Feature release and Major, as well as Revision and KBs, are available at [aka.ms/win10releaseinfo](https://docs.microsoft.com/windows/release-information/). |
|**OSRevisionNumber** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`720` |An integer value for the revision number of the currently-installed Windows 10 OSBuild on the device. |
|**OSEdition** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Enterprise` |The Windows 10 Edition or SKU. |
|**OSFamily** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Windows.Desktop` |The Device Family of the device. Only `Windows.Desktop` is currently supported. |
|**OSServicingBranch** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Semi-Annual` |The Servicing Branch or [Servicing Channel](https://docs.microsoft.com/windows/deployment/update/waas-overview#servicing-channels) the device is on. Dictates which Windows updates the device receives and the cadence of those updates. |
|**TimeGenerated** |[datetime](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/datetime)|3/22/`2020, 1:00:01.318 PM`|A DateTime corresponding to the moment Azure Monitor Logs ingested this record to your Log Analytics workspace. |
|**LastScan** |[datetime](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/datetime)|3/22/`2020, 2:00:00.436 AM`|A DateTime corresponding to the last time the device sent data to Microsoft. This does not necessarily mean all data that is needed to populate all fields Update Compliance uses was sent, this is more like a "heartbeat". |

View File

@ -0,0 +1,46 @@
---
title: Update Compliance Schema - WaaSUpdateStatus
ms.reviewer:
manager: laurawi
description: WaaSUpdateStatus schema
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
---
# WaaSUpdateStatus
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) |
|**FeatureDeferralDays** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`0` |The on-client Windows Update for Business Deferral Policy days.<br> - **<0**: A value below 0 indicates the policy is disabled. <br> - **0**: A value of 0 indicates the policy is enabled, but the deferral period is 0 days.<br> - **1+**: A value of 1 and above indicates the deferral setting, in days. |
|**FeaturePauseDays** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`0` |*Deprecated* This provides the count of days left in a pause |
|**FeaturePauseState** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`NotConfigured` |The on-client Windows Update for Business Pause state. Reflects whether or not a device has paused Feature Updates.<br><li> **Expired**: The pause period has expired.<li> **NotConfigured**: Pause is not configured.<li> **Paused**: The device was last reported to be pausing this content type.<li> **NotPaused**: The device was last reported to not have any pause on this content type. |
|**QualityDeferralDays** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`0` |The on-client Windows Update for Business Deferral Policy days.<br><li> **<0**: A value below 0 indicates the policy is disabled. <li> **0**: A value of 0 indicates the policy is enabled, but the deferral period is 0 days. <li> **1+**: A value of 1 and above indicates the deferral setting, in days. |
|**QualityPauseDays** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`0` |**Deprecated**. This provides the count of days left in a pause period.|
|**QualityPauseState** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`NotConfigured` |The on-client Windows Update for Business Pause state. Reflects whether or not a device has paused Quality Updates.<br><li>**Expired**: The pause period has expired.<li> **NotConfigured**: Pause is not configured.<li>**Paused**: The device was last reported to be pausing this content type.<li>**NotPaused**: The device was last reported to not have any pause on this content type. |
|**NeedAttentionStatus** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) | |Indicates any reason a device needs attention; if empty, there are no [Device Issues](https://docs.microsoft.com/windows/deployment/update/update-compliance-need-attention#device-issues) for this device. |
|**OSArchitecture** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`amd64` |The architecture of the Operating System. |
|**OSName** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Windows 10` |The name of the Operating System. This will always be Windows 10 for Update Compliance. |
|**OSVersion** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`1909` |The version of Windows 10. This typically is of the format of the year of the version's release, following the month. In this example, `1909` corresponds to 2019-09 (September). This maps to the `Major` portion of OSBuild. |
|**OSBuild** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`18363.720` |The currently-installed Windows 10 Build, in the format `Major`.`Revision`. `Major` corresponds to which Feature Update the device is on, whereas `Revision` corresponds to which quality update the device is on. Mappings between Feature release and Major, as well as Revision and KBs, are available at [aka.ms/win10releaseinfo](https://docs.microsoft.com/windows/release-information/). |
|**OSRevisionNumber** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`720` |An integer value for the revision number of the currently-installed Windows 10 OSBuild on the device. |
|**OSCurrentStatus** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Current` |*Deprecated* Whether or not the device is on the latest Windows Feature Update available, as well as the latest Quality Update for that Feature Update. |
|**OSEdition** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Enterprise` |The Windows 10 Edition or SKU. |
|**OSFamily** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Windows.Desktop` |The Device Family of the device. Only `Windows.Desktop` is currently supported. |
|**OSFeatureUpdateStatus** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Up-to-date` |Indicates whether or not the device is on the latest available Windows 10 Feature Update. |
|**OSQualityUpdateStatus** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Up-to-date` |Indicates whether or not the device is on the latest available Windows 10 Quality Update (for its Feature Update). |
|**OSSecurityUpdateStatus**|[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Up-to-date` |Indicates whether or not the device is on the latest available Windows 10 Quality Update **that is classified as containing security fixes**. |
|**OSServicingBranch** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Semi-Annual` |The Servicing Branch or [Servicing Channel](https://docs.microsoft.com/windows/deployment/update/waas-overview#servicing-channels) the device is on. Dictates which Windows updates the device receives and the cadence of those updates. |
|**TimeGenerated** |[datetime](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/datetime)|`3/22/2020, 1:00:01.318 PM`|A DateTime corresponding to the moment Azure Monitor Logs ingested this record to your Log Analytics workspace. |
|**LastScan** |[datetime](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/datetime)|`3/22/2020, 2:00:00.436 AM`|A DateTime corresponding to the last time the device sent data to Microsoft. This does not necessarily mean all data that is needed to populate all fields Update Compliance uses was sent, this is more like a "heartbeat". |

View File

@ -0,0 +1,34 @@
---
title: Update Compliance Schema - WUDOAggregatedStatus
ms.reviewer:
manager: laurawi
description: WUDOAggregatedStatus schema
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
---
# WUDOAggregatedStatus
WUDOAggregatedStatus records provide information, across all devices, 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), over the past 28 days.
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 |
|-|-|-|-|
|**DeviceCount** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`9999` |Total number of devices in this aggregated record. |
|**BWOptPercent28Days** |[real](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/real) |`68.72` |Bandwidth optimization (as a percentage of savings of total bandwidth otherwise incurred) as a result of using Delivery Optimization *across all devices*, computed on a rolling 28-day basis. |
|**BWOptPercent7Days** |[real](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/real) |`13.58` |Bandwidth optimization (as a percentage of savings of total bandwidth otherwise incurred) as a result of using Delivery Optimization *across all devices*, computed on a rolling 7-day basis. |
|**BytesFromCDN** |[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) |`254139` |Total number of bytes downloaded from a CDN versus a Peer. This counts against bandwidth optimization.|
|**BytesFromGroupPeers** |[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) |`523132` |Total number of bytes downloaded from Group Peers. |
|**BytesFromIntPeers** |[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) |`328350` |Total number of bytes downloaded from Internet Peers. |
|**BytesFromPeers** |[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) |`43145` |Total number of bytes downloaded from peers. |
|**ContentType** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`Quality Updates` |The type of content being downloaded.|
|**DownloadMode** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`HTTP+LAN (1)` |Device's Delivery Optimization [Download Mode](https://docs.microsoft.com/windows/deployment/update/waas-delivery-optimization-reference#download-mode) configuration for this device. |
|**TimeGenerated** |[datetime](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/datetime)|`1601-01-01T00:00:00Z` |A DateTime corresponding to the moment Azure Monitor Logs ingested this record to your Log Analytics workspace.|

View File

@ -0,0 +1,57 @@
---
title: Update Compliance Schema - WUDOStatus
ms.reviewer:
manager: laurawi
description: WUDOStatus schema
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
---
# WUDOStatus
> [!NOTE]
> Currently all location-based fields are not working properly. This is a known issue.
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).
|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. |
|**City** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) | |Approximate city device was in while downloading content, based on IP Address. |
|**Country** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) | |Approximate country device was in while downloading content, based on IP Address. |
|**ISP** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) | |The Internet Service Provider estimation. |
|**BWOptPercent28Days** |[real](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/real) |`68.72` |Bandwidth optimization (as a percentage of savings of total bandwidth otherwise incurred) as a result of using Delivery Optimization *for this device*, computed on a rolling 28-day basis. |
|**BWOptPercent7Days** |[real](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/real) |`13.58` |Bandwidth optimization (as a percentage of savings of total bandwidth otherwise incurred) as a result of using Delivery Optimization *for this device*, computed on a rolling 7-day basis. |
|**BytesFromCDN** |[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) |`254139` |Total number of bytes downloaded from a CDN versus a Peer. This counts against bandwidth optimization. |
|**BytesFromGroupPeers** |[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) |`523132` |Total number of bytes downloaded from Group Peers. |
|**BytesFromIntPeers** |[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) |`328350` |Total number of bytes downloaded from Internet Peers. |
|**BytesFromPeers** |[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) |`43145` |Total number of bytes downloaded from peers. |
|**ContentDownloadMode** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`0` |Device's Delivery Optimization [Download Mode](https://docs.microsoft.com/windows/deployment/update/waas-delivery-optimization-reference#download-mode) configuration for this content. |
|**ContentType** |[int](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/int) |`Quality Updates` |The type of content being downloaded. |
|**DOStatusDescription** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) | |A short description of DO's status, if any. |
|**DownloadMode** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`HTTP+LAN (1)` |Device's Delivery Optimization [Download Mode](https://docs.microsoft.com/windows/deployment/update/waas-delivery-optimization-reference#download-mode) configuration for this device. |
|**DownloadModeSrc** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Default` |The source of the DownloadMode configuration. |
|**GroupID** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) | |The DO Group ID. |
|**NoPeersCount** |[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) | |The number of peers this device interacted with. |
|**OSName** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`Windows 10` |The name of the Operating System. This will always be Windows 10 for Update Compliance. |
|**OSVersion** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`1909` |The version of Windows 10. This typically is of the format of the year of the version's release, following the month. In this example, `1909` corresponds to 2019-09 (September). This maps to the `Major` portion of OSBuild.  |
|**PeerEligibleTransfers** |[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) |`0` |Total number of eligible transfers by Peers. |
|**PeeringStatus** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`On` |The DO Peering Status |
|**PeersCannotConnectCount**|[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) |`0` |The number of peers this device was unable to connect to. |
|**PeersSuccessCount** |[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) |`0` |The number of peers this device successfully connected to. |
|**PeersUnknownCount** |[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) |`0` |The number of peers for which there is an unknown relation. |
|**LastScan** |[datetime](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/datetime)|`1601-01-01T00:00:00Z` |A DateTime corresponding to the last time the device sent data to Microsoft. This does not necessarily mean all data that is needed to populate all fields Update Compliance uses was sent, this is more like a "heartbeat". |
|**TimeGenerated** |[datetime](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/datetime)|`1601-01-01T00:00:00Z` |A DateTime corresponding to the moment Azure Monitor Logs ingested this record to your Log Analytics workspace. |
|**TotalTimeForDownload** |[string](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/string) |`0:00:00` |The total time it took to download the content. |
|**TotalTransfers** |[long](https://docs.microsoft.com/azure/kusto/query/scalar-data-types/long) |`0` |The total number of data transfers to download this content. |

View File

@ -0,0 +1,29 @@
---
title: Update Compliance Data Schema
ms.reviewer:
manager: laurawi
description: an overview of Update Compliance data schema
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
---
# Update Compliance Schema
When the visualizations provided in the default experience don't fulfill your reporting needs, or if you need to troubleshoot issues with devices, it's valuable to understand the schema for Update Compliance and have a high-level understanding of the capabilities of [Azure Monitor log queries](https://docs.microsoft.com/azure/azure-monitor/log-query/query-language) to power additional dashboards, integration with external data analysis tools, automated alerting, and more.
The table below summarizes the different tables that are part of the Update Compliance solution. To learn how to navigate Azure Monitor Logs to find this data, see [Get started with log queries in Azure Monitor](https://docs.microsoft.com/azure/azure-monitor/log-query/get-started-queries).
|Table |Category |Description |
|--|--|--|
|[**WaaSUpdateStatus**](update-compliance-schema-waasupdatestatus.md) |Device record |This table houses 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. |
|[**WaaSInsiderStatus**](update-compliance-schema-waasinsiderstatus.md) |Device record |This table houses device-centric data specifically for devices enrolled to the Windows Insider Program. Devices enrolled to the Windows Insider Program do not currently have any WaaSDeploymentStatus records, so do not have Update Session data to report on update deployment progress. |
|[**WaaSDeploymentStatus**](update-compliance-schema-waasdeploymentstatus.md) |Update Session record |This table tracks a specific update 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. |
|[**WUDOStatus**](update-compliance-schema-wudostatus.md) |Delivery Optimization record |This table provides information, for a single device, on their bandwidth utilization across content types in the event they use [Delivery Optimization](https://support.microsoft.com/help/4468254/windows-update-delivery-optimization-faq). |
|[**WUDOAggregatedStatus**](update-compliance-schema-wudoaggregatedstatus.md) |Delivery Optimization record |This table aggregates all individual WUDOStatus records across the tenant and summarizes bandwidth savings across all devices enrolled to Delivery Optimization. |

View File

@ -23,49 +23,4 @@ The **Overall Security Update Status** blade provides a visualization of devices
The **Latest Security Update Status** and **Previous Security Update Status** tiles are stacked to form one blade. The **Latest Security Update Status** provides a visualization of the different deployment states devices are in regarding the latest update for each build (or version) of Windows 10, along with the revision of that update. The **Previous Security Update Status** blade provides the same information without the accompanying visualization.
The various deployment states reported by devices are as follows:
## Deployment status
Deployment status summarizes detailed status into higher-level states to get a quick sense of the status the given device was last reported to be in relative to this specific update. Note that with the latency of deployment data, devices might have since moved on from the reported deployment status.
|Deployment status |Description |
|---------|---------|
|Failed | The device encountered a failure during the update process. Note that due to latency, devices reporting this status may have since retried the update. |
|Progress stalled | The device started the update process, but no progress has been reported in the last 7 days. |
|Deferred | The device is currently deferring the update process due to Windows Update for Business policies. |
|In progress | The device has begun the updating process for this update. This status appears if the device is in any stage of the update process including and after download, but before completing the update. If no progress has been reported in the last 7 days, devices will move to **Progress stalled**.** |
|Update completed | The device has completed the update process. |
|Update paused | The device is prevented from being offered the update due to updates being paused on the device. |
|Unknown | No record is available for this device relative to this update. This is a normal status if an update has recently been released or if the device does not use Windows Update. |
## Detailed status
Detailed status provides a detailed stage-level representation of where in the update process the device was last reported to be in relative to this specific update. Note that with the latency of deployment data, devices might have since moved on from the reported detailed status.
|Detailed status |Description |
|---------|---------|
|Scheduled in next X days | The device is currently deferring the update with Windows Update for Business policies but will be offered the update within the next X days. |
|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) |
|Update deferred | The device is currently deferring the update with Windows Update for Business policies. |
|Update paused | The device is prevented from being offered the update due to updates being paused on the device. |
|Update offered | The device has been offered the update by Windows Update but has not yet begun to download it. |
|Download started | The device has begun downloading the update. |
|Download succeeded | The device has finished downloading the update but has not yet begun installing the update. |
|Install started | The device has begun installing the update. |
|PreInstall task passed | The device has passed checks prior to beginning the rest of the installation process after a restart. |
|Reboot required | The device requires a restart to install the update, but one has not yet been scheduled. |
|Reboot pending | The device is pending a restart to install the update. |
|Reboot initiated | The device reports "Reboot initiated" just before actually restarting specifically to apply the update. |
|Commit | The device, after a restart, is committing changes relevant to the update. |
|Finalize succeeded | The device has finished final tasks after a restart to apply the update. |
|Update successful | The device has successfully applied the update. |
|Cancelled | The update was canceled at some point in the update process. |
|Uninstalled | The update was successfully uninstalled from the device. |
|Rollback | The update failed to apply during the update process, causing the device to roll back changes and revert to the previous update. |
The rows of each tile in this section are interactive; selecting them will navigate you to the query that is representative of that row and section.

View File

@ -22,9 +22,8 @@ In this section you'll learn how to use Update Compliance to monitor your device
Update Compliance:
- Provides detailed deployment data for Windows 10 security, quality, and feature updates.
- Reports when devices have issues related to updates that need attention.
- Shows Windows Defender AV status information for devices that use it and meet the [prerequisites](update-compliance-get-started.md#update-compliance-prerequisites).
- Provides detailed deployment monitoring for Windows 10 Feature and Quality updates.
- Reports when devices need attention due to issues related to update deployment.
- Shows bandwidth usage and savings for devices that are configured to use [Delivery Optimization](waas-delivery-optimization.md).
- Provides all of the above data in [Log Analytics](#using-log-analytics), which affords additional querying and export capabilities.

View File

@ -1,48 +0,0 @@
---
title: Update Compliance - Windows Defender AV Status report
ms.reviewer:
manager: laurawi
description: This article is an overview of the Windows Defender AV Status report, which shows data about signature and threat status.
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
ms.custom: seo-marvel-apr2020
---
# 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 define and review security compliance policies using [Microsoft Endpoint Manager](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager), which allows finer control over security features and updates.
![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)

View File

@ -6,7 +6,6 @@ description: This article provides a summary of references and descriptions for
keywords: oms, operations management suite, wdav, updates, downloads, log analytics
ms.prod: w10
ms.mktglfcycl: deploy
audience: itpro
author: jaimeo
ms.localizationpriority: medium
@ -111,7 +110,7 @@ Download mode dictates which download sources clients are allowed to use when do
| Group (2) | When group mode is set, the group is automatically selected based on the device's Active Directory Domain Services (AD DS) site (Windows 10, version 1607) or the domain the device is authenticated to (Windows 10, version 1511). In group mode, peering occurs across internal subnets, between devices that belong to the same group, including devices in remote offices. You can use GroupID option to create your own custom group independently of domains and AD DS sites. Starting with Windows 10, version 1803, you can use the GroupIDSource parameter to take advantage of other method to create groups dynamically. Group download mode is the recommended option for most organizations looking to achieve the best bandwidth optimization with Delivery Optimization. |
| Internet (3) | Enable Internet peer sources for Delivery Optimization. |
| Simple (99) | Simple mode disables the use of Delivery Optimization cloud services completely (for offline environments). Delivery Optimization switches to this mode automatically when the Delivery Optimization cloud services are unavailable, unreachable or when the content file size is less than 10 MB. In this mode, Delivery Optimization provides a reliable download experience, with no peer-to-peer caching. |
|Bypass (100) | Bypass Delivery Optimization and use BITS, instead. You should only select this mode if you use WSUS and prefer to use BranchCache. You do not need to set this option if you are using SCCM. If you want to disable peer-to-peer functionality, it's best to set **DownloadMode** to **0** or **99**. |
|Bypass (100) | Bypass Delivery Optimization and use BITS, instead. You should only select this mode if you use WSUS and prefer to use BranchCache. You do not need to set this option if you are using Configuration Manager. If you want to disable peer-to-peer functionality, it's best to set **DownloadMode** to **0** or **99**. |
>[!NOTE]
>Group mode is a best-effort optimization and should not be relied on for an authentication of identity of devices participating in the group.
@ -120,7 +119,7 @@ Download mode dictates which download sources clients are allowed to use when do
By default, peer sharing on clients using the group download mode is limited to the same domain in Windows 10, version 1511, and the same domain and Active Directory Domain Services site in Windows 10, version 1607. By using the Group ID setting, you can optionally create a custom group that contains devices that should participate in Delivery Optimization but do not fall within those domain or Active Directory Domain Services site boundaries, including devices in another domain. Using Group ID, you can further restrict the default group (for example, you could create a sub-group representing an office building), or extend the group beyond the domain, allowing devices in multiple domains in your organization to be peers. This setting requires the custom group to be specified as a GUID on each device that participates in the custom group.
[//]: # (SCCM Boundary Group option; GroupID Source policy)
[//]: # (Configuration Manager Boundary Group option; GroupID Source policy)
>[!NOTE]
>To generate a GUID using Powershell, use [```[guid]::NewGuid()```](https://blogs.technet.microsoft.com/heyscriptingguy/2013/07/25/powertip-create-a-new-guid-by-using-powershell/)
@ -136,7 +135,7 @@ Starting in Windows 10, version 1803, set this policy to restrict peer selection
- 4 = DNS Suffix
- 5 = Starting with Windows 10, version 1903, you can use the Azure Active Directory (AAD) Tenant ID as a means to define groups. To do this set the value for DOGroupIdSource to its new maximum value of 5.
When set, the Group ID is assigned automatically from the selected source. If you set this policy, the GroupID policy will be ignored. The option set in this policy only applies to Group (2) download mode. If Group (2) isn't set as Download mode, this policy will be ignored. If you set the value to anything other than 0-4, the policy is ignored.
When set, the Group ID is assigned automatically from the selected source. If you set this policy, the GroupID policy will be ignored. The option set in this policy only applies to Group (2) download mode. If Group (2) isn't set as Download mode, this policy will be ignored. If you set the value to anything other than 0-5, the policy is ignored.
### Minimum RAM (inclusive) allowed to use Peer Caching

View File

@ -55,7 +55,7 @@ The following table lists the minimum Windows 10 version that supports Delivery
| Windows Defender definition updates | 1511 |
| Office Click-to-Run updates | 1709 |
| Win32 apps for Intune | 1709 |
| SCCM Express Updates | 1709 + Configuration Manager version 1711 |
| Configuration Manager Express Updates | 1709 + Configuration Manager version 1711 |
<!-- ### Network requirements

View File

@ -53,7 +53,7 @@ You can control when updates are applied, for example by deferring when an updat
Windows Update for Business offers you the ability to turn on or off both driver and Microsoft product updates.
- Drivers (on/off): When "on," this policy will not include drivers with Windows Update.
- Disable Drivers (on/off): When "on," this policy will not include drivers with Windows Update.
- Microsoft product updates (on/off): When "on" this policy will install updates for other Microsoft products.

View File

@ -113,7 +113,7 @@ Use **Computer Configuration\Administrative Templates\Windows Components\Windows
### Enable client-side targeting
Specifies the target group name or names that should be used to receive updates from an intranet Microsoft update service. This allows admins to configure device groups that will receive different updates from sources like WSUS or SCCM.
Specifies the target group name or names that should be used to receive updates from an intranet Microsoft update service. This allows admins to configure device groups that will receive different updates from sources like WSUS or Configuration Manager.
This Group Policy setting can be found under **Computer Configuration\Administrative Templates\Windows Components\Windows update\Enable client-side targeting**.
If the setting is set to **Enabled**, the specified target group information is sent to the intranet Microsoft update service which uses it to determine which updates should be deployed to this computer.

View File

@ -125,7 +125,7 @@ Looking to learn more? These informative session replays from Microsoft Ignite 2
[BRK3027: Deploying Windows 10: Making the update experience smooth and seamless](https://myignite.techcommunity.microsoft.com/sessions/64612#ignite-html-anchor)
[BRK3039: Windows 10 and Microsoft Office 365 ProPlus lifecycle and servicing update](https://myignite.techcommunity.microsoft.com/sessions/66763#ignite-html-anchor)
[BRK3039: Windows 10 and Microsoft Microsoft 365 Apps for enterprise lifecycle and servicing update](https://myignite.techcommunity.microsoft.com/sessions/66763#ignite-html-anchor)
[BRK3211: Ask the Experts: Successfully deploying, servicing, managing Windows 10](https://myignite.techcommunity.microsoft.com/sessions/65963#ignite-html-anchor)

View File

@ -46,6 +46,7 @@ This section lists the error codes for Microsoft Windows Update.
| 0x80243FFD | `WU_E_NON_UI_MODE` | Unable to show UI when in non-UI mode; WU client UI modules may not be installed. |
| 0x80243FFE | `WU_E_WUCLTUI_UNSUPPORTED_VERSION` | Unsupported version of WU client UI exported functions. |
| 0x80243FFF | `WU_E_AUCLIENT_UNEXPECTED` | There was a user interface error not covered by another `WU_E_AUCLIENT_*` error code. |
| 0x8024043D | `WU_E_SERVICEPROP_NOTAVAIL` | The requested service property is not available. |
## Inventory errors

View File

@ -165,7 +165,7 @@ Check that your device can access these Windows Update endpoints:
Whitelist these endpoints for future use.
## Updates aren't downloading from the intranet endpoint (WSUS/SCCM)
## Updates aren't downloading from the intranet endpoint (WSUS or Configuration Manager)
Windows 10 devices can receive updates from a variety of sources, including Windows Update online, a Windows Server Update Services server, and others. To determine the source of Windows Updates currently being used on a device, follow these steps:
1. Start Windows PowerShell as an administrator
2. Run \$MUSM = New-Object -ComObject "Microsoft.Update.ServiceManager".
@ -205,7 +205,7 @@ From the WU logs:
In the above log snippet, we see that the Criteria = "IsHidden = 0 AND DeploymentAction=*". "*" means there is nothing specified from the server. So, the scan happens but there is no direction to download or install to the agent. So it just scans the update and provides the results.
Now if you look at the below logs, the Automatic update runs the scan and finds no update approved for it. So it reports there are 0 updates to install or download. This is due to bad setup or configuration in the environment. The WSUS side should approve the patches for WU so that it fetches the updates and installs it on the specified time according to the policy. Since this scenario doesn't include SCCM, there's no way to install unapproved updates. And that is the problem you are facing. You expect that the scan should be done by the operational insight agent and automatically trigger download and install but that won't happen here.
Now if you look at the below logs, the Automatic update runs the scan and finds no update approved for it. So it reports there are 0 updates to install or download. This is due to bad setup or configuration in the environment. The WSUS side should approve the patches for WU so that it fetches the updates and installs it on the specified time according to the policy. Since this scenario doesn't include Configuration Manager, there's no way to install unapproved updates. And that is the problem you are facing. You expect that the scan should be done by the operational insight agent and automatically trigger download and install but that wont happen here.
```console
2018-08-06 10:58:45:992 480 5d8 Agent ** START ** Agent: Finding updates [CallerId = AutomaticUpdates Id = 57]

View File

@ -7,30 +7,29 @@ ms.mktglfcycl: manage
author: jaimeo
ms.localizationpriority: medium
ms.author: jaimeo
ms.reviewer:
ms.reviewer:
manager: laurawi
ms.topic: article
---
# Enforcing compliance deadlines for updates
# Enforcing compliance deadlines for updates
>Applies to: Windows 10
> Applies to: Windows 10
Deploying feature or quality updates for many organizations is only part of the equation for managing their device ecosystem. The ability to enforce update compliance is the next important part. Windows Update for Business provides controls to manage deadlines for when devices should migrate to newer versions.
Deploying feature or quality updates for many organizations is only part of the equation for managing their device ecosystem. The ability to enforce update compliance is the next important part. Windows Update for Business provides controls to manage deadlines for when devices should migrate to newer versions.
The compliance options have changed for devices on Windows 10, version 1709 and above:
- [For Windows 10, version 1709 and above](#for-windows-10-version-1709-and-above)
- [For prior to Windows 10, version 1709](#prior-to-windows-10-version-1709)
- [Prior to Windows 10, version 1709](#prior-to-windows-10-version-1709)
## For Windows 10, version 1709 and above
With a current version of Windows 10, it's best to use the new policy introduced in June 2019 to Windows 10, version 1709 and above: **Specify deadlines for automatic updates and restarts**. In MDM, this policy is available as four separate settings:
- Update/ConfigureDeadlineForFeatureUpdates
- Update/ConfigureDeadlineForQualityUpdates
- Update/ConfigureDeadlineGracePeriod
- Update/ConfigureDeadlineNoAutoReboot
- Update/ConfigureDeadlineForFeatureUpdates
- Update/ConfigureDeadlineForQualityUpdates
- Update/ConfigureDeadlineGracePeriod
- Update/ConfigureDeadlineNoAutoReboot
This policy starts the countdown for the update installation deadline from when the update is published, instead of starting with the "restart pending" state as the older policies did.
@ -38,23 +37,19 @@ The policy also includes a configurable grace period to allow, for example, user
Further, the policy includes the option to opt out of automatic restarts until the deadline is reached by presenting the "engaged restart experience" until the deadline has actually expired. At this point the device will automatically schedule a restart regardless of active hours.
### Policy setting overview
|Policy|Description |
|-|-|
| (For Windows 10, version 1709 and above) Specify deadlines for automatic updates and restarts | Similar to the older "Specify deadline before auto-restart for update installation," but starts the deadline countdown from when the update was published. Also introduces a configurable grace period and the option to opt out of automatic restarts until the deadline is reached. |
| (Windows 10, version 1709 and above) Specify deadlines for automatic updates and restarts | Similar to the older "Specify deadline before auto-restart for update installation," but starts the deadline countdown from when the update was published. Also introduces a configurable grace period and the option to opt out of automatic restarts until the deadline is reached. |
### Suggested configurations
### Suggested configurations
|Policy|Location|Quality update deadline in days|Feature update deadline in days|Grace period in days|
|-|-|-|-|-|
|(For Windows 10, version 1709 and above) Specify deadlines for automatic updates and restarts | GPO: Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify deadlines for automatic updates and restarts | 7 | 7 | 2 |
|(Windows 10, version 1709 and above) Specify deadlines for automatic updates and restarts | GPO: Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify deadlines for automatic updates and restarts | 7 | 7 | 2 |
When **Specify deadlines for automatic updates and restarts** is set (For Windows 10, version 1709 and above):
When **Specify deadlines for automatic updates and restarts** is set (Windows 10, version 1709 and above):
- **While restart is pending, before the deadline occurs:**
@ -69,7 +64,7 @@ When **Specify deadlines for automatic updates and restarts** is set (For Window
![The notification users get for an impending restart 15 minutes prior to restart](images/wufb-restart-imminent-warning.png)
- **If the restart is still pending after the deadline passes:**
- Within 12 hours before the deadline passes, the user receives this notification that the deadline is approaching:
![The notification users get for an approaching restart deadline](images/wufb-pastdeadline-restart-warning.png)
@ -81,22 +76,21 @@ When **Specify deadlines for automatic updates and restarts** is set (For Window
## Prior to Windows 10, version 1709
Two compliance flows are available:
Two compliance flows are available:
- [Deadline only](#deadline-only)
- [Deadline with user engagement](#deadline-with-user-engagement)
### Deadline only
### Deadline only
This flow only enforces the deadline where the device will attempt to silently restart outside of active hours before the deadline is reached. Once the deadline is reached the user is prompted with either a confirmation button or a restart now option.
This flow only enforces the deadline where the device will attempt to silently restart outside of active hours before the deadline is reached. Once the deadline is reached the user is prompted with either a confirmation button or a restart now option.
#### End-user experience
Once the device is in the pending restart state, it will attempt to restart the device during non-active hours. This is known as the auto-restart period, and by default it does not require user interaction to restart the device.
Once the device is in the pending restart state, it will attempt to restart the device during non-active hours. This is known as the auto-restart period, and by default it does not require user interaction to restart the device.
>[!NOTE]
>Deadlines are enforced from pending restart state (for example, when the device has completed the installation and download from Windows Update).
> [!NOTE]
> Deadlines are enforced from pending restart state (for example, when the device has completed the installation and download from Windows Update).
#### Policy overview
@ -105,9 +99,6 @@ Once the device is in the pending restart state, it will attempt to restart the
|Specify deadline before auto-restart for update installation|Governs the update experience once the device has entered pending restart state. It specifies a deadline, in days, to enforce compliance (such as imminent installation).|
|Configure Auto-restart warning notification schedule for updates|Configures the reminder notification and the warning notification for a scheduled installation. The user can dismiss a reminder, but not the warning.|
#### Suggested configuration
|Policy|Location|3-day compliance|5-day compliance|7-day compliance|
@ -130,13 +121,13 @@ Notification users get for a feature update deadline:
![The notification users get for an impending feature update deadline](images/wufb-feature-notification.png)
### Deadline with user engagement
### Deadline with user engagement
This flow provides the end user with prompts to select a time to restart the device before the deadline is reached. If the device is unable to restart at the time specified by the user or the time selected is outside the deadline, the device will restart the next time it is active.
This flow provides the end user with prompts to select a time to restart the device before the deadline is reached. If the device is unable to restart at the time specified by the user or the time selected is outside the deadline, the device will restart the next time it is active.
#### End-user experience
Before the deadline the device will be in two states: auto-restart period and engaged-restart period. During the auto-restart period the device will silently try to restart outside of active hours. If the device can't find an idle moment to restart, then the device will go into engaged-restart. The end user, at this point, can select a time that they would like the device to try to restart. Both phases happen before the deadline; once that deadline has passed then the device will restart at the next available time.
Before the deadline the device will be in two states: auto-restart period and engaged-restart period. During the auto-restart period the device will silently try to restart outside of active hours. If the device can't find an idle moment to restart, then the device will go into engaged-restart. The end user, at this point, can select a time that they would like the device to try to restart. Both phases happen before the deadline; once that deadline has passed then the device will restart at the next available time.
#### Policy overview
@ -145,15 +136,15 @@ Before the deadline the device will be in two states: auto-restart period and en
|Specify engaged restart transition and notification schedule for updates|Governs how the user will be impacted by the pending restart. Transition days, first starts out in Auto-Restart where the device will find an idle moment to restart the device. After 2 days engaged restart will commence and the user will be able to choose a time|
|Configure Auto-restart required notification for updates|Governs the notifications during the Auto-Restart period. During Active hours, the user will be notified that the device is trying to restart. They will have the option to confirm or dismiss the notification|
#### Suggested configuration
#### Suggested configuration
|Policy| Location| 3-day compliance| 5-day compliance| 7-day compliance |
|-|-|-|-|-|
|Specify engaged restart transition and notification schedule for updates|GPO: Computer Configuration > Administrative Templates > Windows Components > Windows Update > Specify Engaged restart transition and notification schedule for updates|State: Enabled<br>**Transition** (Days): 2<br>**Snooze** (Days): 2<br>**Deadline** (Days): 3|State: Enabled<br>**Transition** (Days): 2<br>**Snooze** (Days): 2<br>**Deadline** (Days): 4|State: Enabled<br>**Transition** (Days): 2<br>**Snooze** (Days): 2<br>**Deadline** (Days): 5|
#### Controlling notification experience for engaged deadline
#### Controlling notification experience for engaged deadline
|Policy| Location |Suggested Configuration
|Policy| Location |Suggested Configuration
|-|-|-|
|Configure Auto-restart required notification for updates |GPO: Computer Configuration > Administrative Templates > Windows Components > Windows Update > Configure Auto-restart required notification for updates|State: Enabled <br>**Method**: 2- User|
@ -175,4 +166,3 @@ Notification users get for a feature update deadline:
![The notification users get for an impending feature update deadline](images/wufb-feature-update-deadline-notification.png)