Understanding connectivity scenarios and the deployment script
Over the last couple of months, we have learned a lot about the connectivity scenarios our customers are running and thus we have made improvements to the deployment script. In the past, the deployment script used to make assumptions about the scenario you are using sometimes caused an incorrect result. The new version of the deployment script is available now on Download Center.
Endpoints for the Windows
To start off, let’s review the endpoints which need to be accessible in order for your clients to send telemetry data to Microsoft which will subsequently show up in Windows Analytics:
| Endpoint | Function |
|---|---|
|
Connected User Experience and Telemetry component endpoint. User computers send data to Microsoft through this endpoint. |
|
Enables the compatibility update KB to communicate with Microsoft. |
|
This service provides driver information about whether there will be a driver available post-upgrade for the hardware on the system. If you are using a Windows Compatibility Update published after February 2017 (appraiser.dll version >= 10.0.14979) you don’t need access to these endpoints. |
Scenario 1: Direct connection to the internet
Internally we like to refer to this as the coffee-shop scenario. Client computers can communicate directly to the internet via a routed connection. This scenario is most common in home networks or when your users are on the road (hotel, airport, coffee-shop). Some of our customers are using a direct connection to the internet even in their corporate networks.
This scenario is very simple since there is no proxy involved. If you are using a network firewall which is blocking outgoing traffic, please keep in mind that even though we provide DNS names for the endpoints needed to communicate to the Microsoft telemetry backend, We therefore do not recommend to attempt to whitelist endpoints on your firewall based on IP-addresses.
In order to use the direct connection scenario, set the parameter ClientProxy=Direct in runconfig.bat.
Scenario 2: Connection through the WinHTTP proxy
This is the first and most simple proxy scenario. The WinHTTP stack was designed for use in services and does not support proxy autodetection, PAC scripts or authentication.
In order to set the WinHTTP proxy system-wide on your computers, you need to
- Use the command netsh winhttp set proxy <server>:<port>
- Set ClientProxy=System in runconfig.bat
The WinHTTP scenario is most appropriate for customers who use a single proxy or f. If you have more advanced proxy requirements, refer to Scenario 3.
If you want to learn more about Proxy considerations on Windows, please take a look at this post in the ieinternals blog.
Scenario 3: Connection to the internet by using the logged-in user’s internet connection
In order to accommodate complex proxy scenarios, we also support using the currently logged-in user’s internet connection. This scenario supports PAC scripts, proxy autodetection and authentication. Essentially, if the logged in user can reach the Windows Telemetry endpoints, the telemetry client can send data. If runconfig.bat runs while no user is logged in, telemetry events get written into a buffer which gets flushed when a user logs in.
In order to enable this scenario, you need
- A current quality update Rollup for Windows 7, 8.1 or Windows 10 Version 1511. Updates shipped after October 2016 have the needed code
- Set the reg key HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection\DisableEnterpriseAuthProxy to 0. If the value does not exist, create a new DWORD, name it DisableEnterpriseAuthProxy and set the value to 0. The deployment script will check this is configured correctly.
- Set ClientProxy=User in bat.
Scenario 4: Configuring a proxy just for use by the telemetry client
As you may have seen in the TechNet documentation for the October Windows 7 quality rollup, there is an option to use a separate proxy just for the telemetry client. We are working on supporting this scenario for Windows Analytics and working through a couple issues at the moment. Once these issues have been resolved, we will follow up with a new version of the deployment script and a blog post.
Allowing the deployment script to send diagnostic data to Microsoft
Since the deployment script has become very complex, we configured the latest version (03.02.17) of the deployment script is configured to collect and send diagnostic and debugging data to Microsoft. This is the same data that is collected in the log file, specifically the text log file that captures the events and error codes while running the script– this file is named in the following format: UA_yyyy_mm_dd_hh_mm_ss_machineID.txt.
The log files are created in the drive that is specified in the RunConfig.bat file. By default this is set to: %SystemDrive%\UADiagnostics
This data gives us the ability to determine the status of your machines and to help troubleshoot issues.
This option is turned on by default. However, you must allow https traffic to be sent to the following wildcard endpoints in order for data to be sent to Microsoft:
*vortex*.data.microsoft.com
*settings*.data.microsoft.com
To opt out of sending the diagnostic and debugging data, set the parameter AppInsightsOptIn = false in the RunConfig.bat file in the pilot and/or deployment folder that are available when you download the deployment script. The AppInsightsOptIn parameter is set to true by default.
If you have questions or comments, please use the comments section below.