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.
[…] a comment on Windows Analytics on-boarding with Intune Windows Analytics onboarding with Intune Windows Analytics onboarding with […]
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.
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.
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 :
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?
all OMA-URI values are Integer except the Commercial ID. You need to have 1809 to apply all the settings.
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,
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.
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?
these are the requirements for the settings:
AllowDeviceNameInDiagnosticData is supported on 1809+
LimitEnhancedDiagnosticDataWindowsAnalytics is supported on 1709+
ConfigureTelemetryOptInSettingsUx is supported on 1803+
ConfigureTelemetryOptInChangeNotification is supported on 1803+
Microsoft docs of the settings are here: https://docs.microsoft.com/en-us/windows/client-management/mdm/policy-csp-system
So for the full feature set you need to have Windows 10 Version 1809 or higher.
Windows Analytics needs only to be setup like shown in this guide: https://docs.microsoft.com/en-us/windows/deployment/update/windows-analytics-azure-portal
This is more a setup of log analytics and adding the Windows Analytics solutions to it, nothing more. Next step is onboarding the clients like this guide describes.