On Optimizing Large Deployments of Windows Analytics
One of the more crucial pillars to ongoing success with managing initial Windows 10 deployments, as well as ongoing WaaS (Windows as a Service) servicing is the ability to leverage organization intelligence and key data to optimize ongoing updates and servicing and get in front of potential issues before they become widespread and disruptive. Specifically, analytics - as of now: Windows Analytics. 
Telemetry
Windows Analytics is built from telemetry. Telemetry has been the key to Microsoft understanding the true insights of Windows usage and the vast Windows application ecosystem in the consumer space. Microsoft then took these lessons to the enterprise making available the very tools that made us successful transition to WaaS available free for our enterprise customers. However, telemetry involves the transmission of data and there is a level of trust required from our customers (not to mention laws and regulations from various governments and compliance bodies. Microsoft has gone to great lengths to comply with all regulations even at times, suspending collection in order to make proper adjustments when needed. I would recommend the following resources for further reading:
Windows Analytics and privacy https://docs.microsoft.com/en-us/windows/deployment/update/windows-analytics-privacy
Learn about security and privacy at Microsoft data centers https://www.microsoft.com/datacenters
Confidence in the trusted cloud https://azure.microsoft.com/en-us/support/trust-center/
In addition, with versions of Windows 10 1709 and later, a special level of telemetry was created that allows you to submit additional telemetry beyond basic, but only that which is required specifically for Windows Analytics. This new value as well as all the other values are documented and regularly updated here: /en-us/windows/privacy/configure-windows-diagnostic-data-in-your-organization Without telemetry, other metrics would have to be leveraged and have been in the past. These insights are often flawed depending on the metric. For example, take support call volume – a common usage metric but it can be flawed in the sense that the products/components that are either the more difficult or defected are inferred to be used more. That is not always the case.
Telemetry Decisions
Due to the varying degrees of telemetry as well as the factor that certain analytical solutions have specific telemetry requirements, the assumption is made that your organization’s various privacy, governance, and legal stakeholders have signed off on a telemetry level adequate for use as it is obviously a fundamental piece of an analytics solution. Microsoft has listened With this , it also important to note that recent factors involving the GDPR play into this as now in European Union nations, there are certain data types that cannot be collected regardless of organizational decisions and those limits are now reflected in the telemetry engines as well.
The Upgrade Readiness Deployment Script - A *Pilot* Script
One useful piece of the Analytics onboarding process is the Upgrade Readiness deployment script. While truly only a real pre-requisite for piloting Upgrade Readiness, it is a great start to evaluating Windows Analytics in a PoC or Pilot environment while at the same time, learning what additional configuration items might be required at scale for your wider deployment (proxy configuration, client telemetry engine updates, etc.) The script is very useful in the pilot phase as it allows you to get in front of any potential large scale issues that may be cumbersome to trouble once widely deployed. What the script essential does is:
- Verifies that the Telemetry engine and specifically AppRaiser Module are up to date: This is crucial not only on down-level clients (Windows 7 and 8.1 but also older Windows 10 clients.)
- Connectivity: Verifies that connectivity to the telemetry cloud endpoints. In addition, also verifies appropriate access through proxies both authenticated and unauthenticated.
- Setting the Corporate ID: Crucial in order to get the information into the right Analytics tenant.
- Setting Telemetry Levels and Options: Setting the appropriate level needed depending on solution(s) leveraged.
Finally, the script culminates in a collection and uploading of a full set of telemetry data dependent on telemetry level.
Deployment Pushing out a script can be avoided at scale in favor of more optimal configuration management. While the script also uploads insights regarding script successes and failures, those insights are more useful during piloting for identifying potentially common causes of deployment failures – most commonly pending reboots – which is one of the items checked in the onboarding script. As documented in /en-us/windows/deployment/update/windows-analytics-get-started now scaled deployments can leverage management infrastructures to stamp these configuration items on windows endpoints.
- CommercialID Value
- AllowTelemetry Value (Windows 10)
- Optionally setting the LimitEnhancedDiagnosticDataWindowsAnalytics value (1709 and later)
- Setting the AllowDeviceNameInTelemetry (Windows 10) parameter. For Windows 10 1803 and later, this value must be explicitly set to ensure device name is collected.
- CommercialDataOptIn (Pre-Windows 10 Clients)
- IEDataOptin (if using Site Discovery)
In lieu of the deployment script, you can also deploy this configuration at scale using your current management environment including:
Group Policy: The old-fashioned way. Ensuring the Proper ADMX has been imported, the path is Computer Configuration – Administrative Templates – Windows Components – Data Collection and Preview Builds. 
MDM via the Policy CSP: The reference is here: /en-us/windows/client-management/mdm/policy-configuration-service-provider Specifically, the primary items are:
OMA-URI -> ./Vendor/MSFT/Policy/Config/System/AllowTelemetry
OMA-URI - /Vendor/MSFT/DMClient/Provider/ProviderID/CommercialID
Configuration Manager (1706 and later.) Full information here: /en-us/sccm/core/clients/manage/monitor-windows-analytics The process is pretty straight forward: • Create NEW - Client Settings - Windows Analytics • Then apply the settings via Custom Device Settings Then, ensuring the scheduled tasks are in place to establish that there is a periodic full upload of telemetry. Upon deploying the script, you might have noticed the scheduled tasks including these commands:
CompatTelRunner.exe -m:generaltel.dll -f:DoCensusRun
CompatTelRunner.exe -m:appraiser.dll -f:DoScheduledTelemetryRun ent
A full sync of telemetry data for analytics happens under the following conditions:
- When a new version of appraiser is installed (i.e. if the machine installs a monthly Quality Update. However the cadence for updating the AppRaiser module is usually every 2-3 months.)
or - When you run those two commands as System (via Configuration Manager or other management system:)
CompatTelRunner.exe -m:generaltel.dll -f:DoCensusRun
CompatTelRunner.exe -m:appraiser.dll -f:DoScheduledTelemetryRun ent
or - Finally, re-running the UR Script will also automatically upload a full data set.