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

 

 

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

The 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:

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

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:

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

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:

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

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.

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

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.

(4134)

comments
  • Rkast
    Posted at 20:51 March 27, 2019
    Rkast
    Reply
    Author

    Great insights with these Analytics. This gives admins more insights in the environment/endpoints. Thanks for sharing this info. Will certainly config this for customers. Does it require 1809 as minimum? And are Analytics configurations necessary of r does it work out of the box as per your article?

  • Kenneth
    Posted at 12:14 May 7, 2019
    Kenneth
    Reply
    Author

    Hi Oliver,

    Microsoft documentation states that you should deploy a configuration script and schedule it to run once in a while. I’m missing those steps in this article.

    Will Windows Analytics work when only deploying these settings and not the script?

    Thanks in advance,

    Kenneth

    • Oliver Kieselbach
      Posted at 10:24 August 14, 2019
      Oliver Kieselbach
      Reply
      Author

      Hi Kenneth,

      Yes, it will work without the script as long as you use Windows 10. Windows 10 has a built in scheduled task to trigger the telemetry for this. If you still dealing with Windows 7 and want to use Windows Analytics for migration preparation (upgrade readiness) you have to use the script and you should trigger it regularly (scheduled task) on these devices as they do not have built in capabilities for that.
      best,
      Oliver

  • Aditya
    Posted at 23:49 June 19, 2019
    Aditya
    Reply
    Author

    Hello Sir, Great article!! I followed instructions and chose the ‘Data Type’ both, as ‘String’ as well as ‘Integer’. However, I get an error as ‘Remediation Failed’. With ‘Integer’ I tried values as 1 and 0. With String I followed instructions for ADMX policies pushed ‘String’ as :

    OMA-URi: ./Device/Vendor/MSFT/Policy/Config/System/ConfigureTelemetryOptInSettingsUx
    String:

    OMA-URi: ./Device/Vendor/MSFT/Policy/Config/System/LimitEnhancedDiagnosticDataWindowsAnalytics

    String:

    However, it was not successful. The policy was assigned to Device group. I tried ./Device as well as ./Vendor as mentioned in the article. No Success. Can you please throw some more light over the policy. Am I missing any details?

    • Oliver Kieselbach
      Posted at 10:19 August 14, 2019
      Oliver Kieselbach
      Reply
      Author

      Hi,
      all OMA-URI values are Integer except the Commercial ID. You need to have 1809 to apply all the settings.
      best,
      Oliver

  • Biljana Janeva
    Posted at 07:56 July 10, 2019
    Biljana Janeva
    Reply
    Author

    Hi Oliver,

    I have these settings applied on my devices, and somehow devices that were in Windows analytics from 1709 (when names were displayed by default) are not able to send their name in Analytics. However all new enrolled devices, applying the same CSPs are displaying names correctly. Any idea how to force this? Devices are joined to Azure AD and on 1809.
    Best,
    Biljana

    • Oliver Kieselbach
      Posted at 10:12 August 14, 2019
      Oliver Kieselbach
      Reply
      Author

      Sorry didn’t experience this. I would check if the registry settings is applied on the devices not sending. Maybe the CSP reporting is somehow telling you it is applied but the setting is not really applied in registry.
      best,
      Oliver

  • Leave a Reply

    This site uses Akismet to reduce spam. Learn how your comment data is processed.