Windows Analytics onboarding with Intune

Windows Analytics provides a key component in a modern managed environment. If we use Windows Update for Business we have no way of monitoring key performance metrics of our environment without Windows Analytics.

Windows Analytics is based on an Azure Monitor Log Analytics instance which provides three key solutions.

Update Compliance to monitor Quality Updates, Features Updates and Delivery Optimization performance.

Upgrade Readiness is used to get insights into your app environment and to plan a mitigation strategy for successful feature upgrades.

Device Health is used to gather crash data to get proactive and resolve app and drivers issues in your environment.

UPDATE: Retirement of Windows Analytics in favor of Desktop Analytics on January 31st, 2020 – Update Compliance will stay!!!

To get the client data into the Log Analytics instance to let the Windows Analytics solutions provide you the insights, we need to onboard our corporate clients. To setup Log Analytics with the Windows Analytics solutions follow this Microsoft article Windows Analytics in the Azure Portal. In this guide I will walk through the MDM settings set by Microsoft Intune. Keep in mind that these settings can also be controlled with GPOs which we will not show here. We will look at every setting and the pitfalls they may have and how to overcome these. This is a guide for corporate devices, for personal devices you might want different settings and more control for the user. In a corporate device scenario you take control over the settings.

The first and most important setting is the telemetry level which needs to be set to Basic to enable Windows Update for Business and to get Update Compliance and Upgrade Readiness to work. For the Device Health we need more data to support this solution (e.g. crash data of apps) and this requires telemetry level Enhanced. If Microsoft Intune provides an UI to configure certain settings I’m always a fan to use the UI elements for this instead of custom profiles. To configure the setting go to Device configuration – Profiles > Device Restriction – Properties > Device restrictions > Reporting and Telemetry

Additional Microsoft documentation can be found here: Configure Windows diagnostic data in your organization

A similar control setting will be available in Office 365 ProPlus as well with Version 1904 – Overview of privacy controls for Office 365 ProPlus.

In addition we need further settings to make sure everything works as expected. These settings can only be set by custom OMA-URI settings. I’ll walk through every single one and why it is important:

Lets start with the Commercial ID which represents the logical identifier for your client data. Every client will be configured with your Commercial ID. This way Microsoft can identify your data and provide them to your Log Analytics instance. For a detailed data flow look here: Windows Analytics and privacy

To get the Commercial ID follow your Log Analytics workspaces yourworkspacename > Overview > WaaSUpdateInsights(yourworkspacename) > WaaSUpdateInsights(yourworkspacename) – Update Compliance Settings

Additional Microsoft documentation can be found here: Enrolling devices in Windows Analytics

Use the following setting to configure Commercial ID:

Setting: CommercialID
OMA-URI: ./Vendor/MSFT/DMClient/Provider/MS DM Server/CommercialID
Value: <your-commercial-id> (string)

All the additional following settings are based on the Policy CSP – System policies.

The next setting ConfigureTelemetryOptInSettingsUx is one of the most important settings. This might not be obvious to the most but I’ll explain why. During a lot of modern management project we have onboarded a lot of clients to Windows Analytics but we found that the Device Health often did not reflect the numbers of clients we have onboarded.

Why does Device Health not reflect the correct device number?

Without the setting and a telemetry level of enhanced the Windows UI for telemetry level is not disabled it just limits the max level to Enhanced. Every user has the right to lower the setting to basic if they want to, the UI is not disabled.

Now if an onboarding experience does not use Windows Autopilot for device enrollment, every user is prompted to answer some questions during the initial user enrollment setup – Out of the box experience (OOBE). One question is about the telemetry level and quite a few users are sensitive in answering these kind of questions and often choose the lowest available level here, which is Basic. This leads to the fact that even when you as an Admin configure Enhanced the client reports only basic telemetry level.

To make sure this will not happen during rollouts without Windows Autopilot usage, we need to make sure the setting still falls back to Enhanced and the UI is blocked afterwards. A blocked UI is necessary as the user can also go into Settings and lower the telemetry level.

Use the following setting to configure the enforcement and disable of the UI (supported since 1803):

Setting:  
ConfigureTelemetryOptInSettingsUx 
OMA-URI: ./Vendor/MSFT/Policy/Config/System/ConfigureTelemetryOptInSettingsUx
Value: 1 (Integer)

Another setting which is important for most customers especially in the EU is the ability to Limit the telemetry diagnostics data to the level which is needed to use Windows Analytics but not more. A requirement by the GDPR is to limit data collection to the minimum to run services but not more. Microsoft did this by introducing this setting and limiting data collection to Windows Analytics data only.

Use the following setting to limit the Enhanced data level (supported since 1709):

Setting:  
LimitEnhancedDiagnosticDataWindowsAnalytics 
OMA-URI: ./Vendor/MSFT/Policy/Config/System/LimitEnhancedDiagnosticDataWindowsAnalytics
Value: 1 (Integer) 

Another consequence of GDPR was the changed default behavior at some point in time regarding the device names. Microsoft changed the default to not display the device names in log analytics data. For troubleshooting purpose it is often necessary, especially in the Windows Update for Business scenario where we don’t have other data sources to track if everything is working fine. To change the default behavior back to show device names use the following setting (supported since 1809) :

Setting:  
AllowDeviceNameInDiagnosticData 
OMA-URI: ./Vendor/MSFT/Policy/Config/System/AllowDeviceNameInDiagnosticData
Value: 1 (Integer) 

The last setting is all about user experience. When we set the device telemetry level and block users from changing this setting we as IT take the control of the corporate device and don’t want unnecessary user notifications during first boot experience like this:

The following setting should “in theory” prevent this notification from appearing but unfortunately it doesn’t work. I’ll hope this will be fixed soon and it starts working. UPDATE 27/08/2019: The following setting works if it is assigned to an AAD device group and the Enrollment Status Page (ESP) is enabled in your tenant. Otherwise the setting will be set too late in the process and the dialog is still shown. It must be set before the user first logs on the Desktop. To configure it set the ConfigureTelemetryOptInChangeNotification (supported since 1709):

Setting:  
ConfigureTelemetryOptInChangeNotification 
OMA-URI: ./Vendor/MSFT/Policy/Config/System/ConfigureTelemetryOptInChangeNotification
Value: 1 (Integer) 

This represents a best practice guide for corporate devices which are 1809 or higher to make sure IT has all necessary data for Windows Analytics in a cloud-only modern managed device scenario.

I wish successful deployments of Windows Analytics in your modern cloud managed environments.

There is an additional great article about this topics from Peter van der Woude, check it out also:
The different ways of enrolling devices in Windows Analytics