Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Proxy requirements
Devices require direct access to the Delivery Optimization cloud service endpoint: *.prod.do.dsp.mp.microsoft.com. Configure your proxy to allow traffic to this endpoint. While Delivery Optimization can use the automatic proxy discovery capability of WinHttp to handle proxy communication, direct access to this endpoint ensures optimal P2P connectivity and performance.
Proxy bypass is recommended when the proxy performs any of the following:
- TLS inspection.
- Scans or modifies response content.
- Hides the client's true public IP address in a way that can negatively impact P2P connectivity.
- Cannot be otherwise configured to avoid the behaviors listed above.
Bypassing this endpoint helps ensure that Delivery Optimization can accurately identify peer devices and establish efficient P2P connections.
Note
If allowing direct internet access isn't an option, try using Group DownloadMode '2' to define the peering group. Learn more about using Group DownloadMode.
TLS inspection requirements
Delivery Optimization uses certificate pinning when connecting to its cloud service endpoints. A proxy that performs TLS inspection (also called SSL inspection or HTTPS interception) replaces the server certificate with one signed by the proxy's own certificate authority. This breaks Delivery Optimization's certificate validation, causing service connections to fail.
Important
TLS inspection must be disabled for Delivery Optimization and Microsoft Connected Cache endpoints. There's no workaround — Delivery Optimization won't accept a substitute certificate for these connections.
Endpoints to exempt from TLS inspection
Ensure the following endpoints are on your proxy or firewall's TLS inspection bypass list:
| Endpoint | Used by | Why exemption is required |
|---|---|---|
geo.prod.do.dsp.mp.microsoft.com |
DO geo service and MCC initialization | Certificate pinning — MCC reports "Geo certificate verification failed" if intercepted |
array*.prod.do.dsp.mp.microsoft.com |
DO cloud service (peer discovery, configuration) | Certificate pinning — connection fails if the certificate is replaced |
For a complete list of endpoints used by Delivery Optimization and Microsoft Connected Cache, see Microsoft Connected Cache content and services endpoints.
Impact of TLS inspection on Delivery Optimization
When TLS inspection is active on Delivery Optimization endpoints, you may experience:
- Peer-to-peer (P2P) downloads fail. Delivery Optimization can't connect to the cloud service to discover peers, so all downloads fall back to CDN-only.
- Microsoft Connected Cache (MCC) discovery fails. MCC uses the same cloud service for initialization. If the geo service connection fails, MCC can't complete its setup.
- Downloads fall back to HTTP-only. While content still downloads, you lose the bandwidth savings from P2P and MCC.
Verify TLS inspection isn't intercepting DO traffic
To confirm your proxy isn't intercepting Delivery Optimization connections, run the Delivery Optimization Troubleshooter with the -HealthCheck switch. This checks connectivity to DO service endpoints and reports certificate validation failures. For details, see Delivery Optimization Troubleshooter.
If the health check reports certificate validation failures for the DO service endpoint, TLS inspection is likely active and needs to be bypassed.
Cloud proxy configuration (Zscaler, similar)
If you use Zscaler or a similar cloud proxy:
- Bypass the DO service hostnames (
*.do.dsp.mp.microsoft.com) from TLS inspection and allow that traffic directly to the internet. - Content CDN URLs (
*.dl.delivery.mp.microsoft.com) can optionally go through the proxy, but must not have their content modified. - Verify that the proxy doesn't alter the client's source IP address for DO service calls — Delivery Optimization uses the client's IP for geo-location and peer matching.
Note
Delivery Optimization service calls (to *.do.dsp.mp.microsoft.com) cannot go through a proxy that alters the client's IP address, because the service uses the IP for geo-location and peer matching. Content payload downloads (actual update files) can go through a proxy.
How Delivery Optimization uses WinHttp
When Delivery Optimization downloads content from HTTP sources, it uses WinHttp's automatic proxy discovery capability to handle complex proxy configurations. Delivery Optimization enables this by setting the WINHTTP_ACCESS_TYPE_AUTOMATIC_PROXY flag in all HTTP calls.
Delivery Optimization provides WinHttp with a token for the currently signed-in user. WinHttp then uses this token to automatically authenticate the user against the proxy configured.
Configuring your proxy
To enable Delivery Optimization to use your proxy, configure it through Windows Proxy settings (WinINET, historically Internet Explorer proxy settings).
Set the Windows Proxy as device-wide to ensure the device can access the proxy server even when no user is signed in. In this case, the proxy is accessed with the "NetworkService" context if proxy authentication is required.
Note
We don't recommend using netsh winhttp set proxy ProxyServerName:PortNumber. This command offers no auto-detection of the proxy, no support for explicit PAC URLs, and no authentication to the proxy. It's also ignored by WinHTTP for requests that use auto-discovery with an interactive user token.
Proxy behavior by user context:
- When a user is signed in, the system uses the Windows Proxy.
- When no user is signed in and both Windows Proxy and netsh configurations are set, the netsh configuration takes precedence. This can result in download failures such as HTTP_E_STATUS_PROXY_AUTH_REQ or HTTP_E_STATUS_DENIED errors.
If your proxy configuration uses a static proxyServerName:Port, you can import the proxy setting from Internet Explorer using:
netsh winhttp import proxy source=ie
However, the same limitations mentioned previously apply to this imported configuration.
Setting a device-wide Windows Proxy
You can configure a device-wide proxy by using either Mobile Device Management (MDM) or Group Policy, depending on your environment. Both methods apply proxy settings to all users on the device, ensuring Delivery Optimization can access the proxy server in all contexts, including when no user is signed in.
Using MDM (Mobile Device Management)
To set proxy settings for all users through MDM (such as Intune), use the Network Proxy CSP. This method applies device-wide proxy settings that work for all user contexts, including interactive users and background services like NetworkService.
Using Group Policy
If you manage devices through Active Directory, you can apply proxy settings to all users on the device by enabling the Computer Configuration > Administrative Templates > Windows Components > Internet Explorer > Make proxy settings per-machine (rather than per-user) policy.
When you enable this policy, proxy settings apply uniformly to all users on the device. This means all users must use the same proxy configuration set at the device level, and users cannot override it with their own proxy settings. If you disable this policy or leave it 'Not Configured', users can establish their own individual proxy settings.
Microsoft Connected Cache behind a proxy
If you use Microsoft Connected Cache, you can configure the Connected Cache server to use a proxy for outbound internet connections.
The Connected Cache server's proxy settings are separate from Delivery Optimization's proxy configuration. While Delivery Optimization clients need proxy settings to reach the cloud service (as described above), the Connected Cache server itself may also need proxy settings to reach Microsoft's content servers.
Connected Cache supports using an unauthenticated proxy for outbound connections. For detailed configuration steps, see Microsoft Connected Cache Proxy settings.
Proxy connection timing behavior
When Delivery Optimization operates behind a proxy, initial downloads may take longer to begin. This happens because Delivery Optimization must perform proxy discovery and user authentication through Windows networking components before content transfer starts.
Understand the following about Delivery Optimization's connection behavior with proxies:
- Multiple connections: Delivery Optimization establishes several connections between the client and different Delivery Optimization cloud services.
- Connection reuse: Delivery Optimization uses WinHTTP's connection pooling to reuse connections. When a connection is idle for approximately 60 seconds, it closes. Subsequent requests must establish new connections, which can add time to downloads.
This additional setup time is normal and expected behavior, and doesn't indicate a problem with your proxy configuration.
Summary of settings behavior
The following tables show how Delivery Optimization handles different proxy configurations depending on the user context. The tables distinguish between two scenarios: when a user is actively signed in, and when downloads occur without an interactive user (using NetworkService context, typically for background or scheduled downloads).
When an interactive user is signed in:
| Configuration method | Delivery Optimization uses proxy |
|---|---|
| Internet Explorer proxy (current user) | Yes |
| Internet Explorer proxy (device-wide) | Yes |
| netsh proxy | No |
| Both Internet Explorer proxy (current user) and netsh proxy | Yes, Internet Explorer proxy is used |
| Both Internet Explorer proxy (device-wide) and netsh proxy | Yes, Internet Explorer proxy is used |
When no user is signed in (NetworkService context):
| Configuration method | Delivery Optimization uses proxy |
|---|---|
| Internet Explorer proxy (current user) | No |
| Internet Explorer proxy (device-wide) | Yes |
| netsh proxy | Yes |
| Both Internet Explorer proxy (current user) and netsh proxy | Yes, netsh proxy is used |
| Both Internet Explorer proxy (device-wide) and netsh proxy | Yes, netsh proxy is used |
Tip
For the most reliable proxy configuration, use device-wide Internet Explorer proxy settings. This method works in both user contexts and ensures Delivery Optimization can access the proxy whether a user is signed in or not.