DO: Microsoft Connected Cache in Configuration Manager + Intune

To minimize internet bandwidth usage, Intune-managed devices should be configured to take advantage of Delivery Optimization (DO). This distributed caching solution leverages peer-to-peer content sharing, making it particularly effective in the cloud environment. A significant enhancement to this system is Microsoft Connected Cache (MCC), formerly known as Delivery Optimization In-Network Cache (DOINC). This new feature adds another layer of efficiency by enabling on-premises caching of content, further reducing external bandwidth demands.

Prerequisites and limitations

Supported Clients

Microsoft Connected Cache and Delivery Optimization support clients running a supported version of Windows 10 or later.

Licensing

Each device accessing content from a Connected Cache-enabled distribution point requires one of the following license subscriptions:

• Windows Enterprise E3 or E5, included in Microsoft 365 F3, E3, or E5
• Windows Education A3 or A5, included in Microsoft 365 A3 or A5
• Windows Virtual Desktop Access (VDA) E3 or E5

Distribution Point Requirements

To use Connected Cache in Configuration Manager, an on-premises distribution point is required, with these configurations:

• Operating System: Windows Server 2016 or later
• Framework: Microsoft .NET Framework version 4.7.2 or later. For more details, refer to the .NET Framework system requirements.
• Web Server: The default website must be enabled on port 80.
• IIS Configuration: Do not preinstall the IIS Application Request Routing (ARR) feature. Connected Cache will install and configure ARR. Microsoft cannot guarantee that ARR's configuration by Connected Cache will not conflict with other applications using this feature on the server.
• Proxy Server: Connected Cache can use an unauthenticated proxy server for internet access.
• Dedicated Role: Do not use a distribution point that has other site roles, such as a management point. Enable Connected Cache only on a site system server that has the distribution point role.

Network Access Requirements

The distribution point must have internet access to the Microsoft cloud. The specific URLs required can vary depending on the content enabled in the cloud. Ensure that endpoints for Delivery Optimization are also allowed.

Internet access requirements - Configuration Manager | Microsoft Learn

For co-managed clients and Intune Win32 apps, ensure the distribution point can access the endpoints specific to those scenarios.

Network requirements for PowerShell scripts and Win32 apps .

Clients primarily need access to the distribution point with the Connected Cache. However, it's recommended to also allow clients access to the internet endpoints for the content as a fallback to the original source. Therefore, it's necessary to open TCP port 80 from the endpoints to the Connected Cache server on the distribution point for MDM endpoints.

Port requirements - For peer-to-peer traffic, Delivery Optimization uses 7680 for TCP/IP or 3544 for NAT traversal (optionally Teredo). For client-service communication, it uses HTTP or HTTPS over port 80/443.

Proxy requirements - To use Delivery Optimization, you must allow Byte Range requests. For more information,

Proxy requirements for Windows Update .

Firewall requirements - Allow the following hostnames through your firewall to support Delivery Optimization. For communication between clients and the Delivery Optimization cloud service: *.do.dsp.mp.microsoft.com

For Delivery Optimization metadata: *.dl.delivery.mp.microsoft.com , *.emdl.ws.microsoft.com

How it works

Once clients are configured to utilize the Connected Cache server, they cease to directly fetch Microsoft cloud-managed content from the internet. Instead, they request this content from a cache server that resides on the distribution point. This on-premises server caches the content using the IIS Application Request Routing (ARR) feature. Subsequently, when there are subsequent requests for the same content, the cache server can swiftly respond. In instances where the Connected Cache server is inaccessible, clients revert to downloading the content from the internet. Additionally, clients leverage Delivery Optimization to retrieve portions of the content from peers within their network.

1. Microsoft Intune configures Delivery Optimization (DO) settings on devices, including specifying the Microsoft Connected Cache (MCC) server name.
2. Device A performs a check for Windows Updates and obtains the address for the content delivery network (CDN).
3. Device A then requests content from the MCC.
4. If the requested content is not available in the cache, the MCC retrieves it from the CDN.
5. In cases where the MCC is inaccessible or fails to respond, the device proceeds to download the content directly from the CDN.
6. Devices A, B, and C continue leveraging DO to acquire missing segments of content from their peers within the network.

Supported Content?

• Windows Updates
• Office 365 ProPlus (Setup and Updates)
• Microsoft Store Apps
• Intune Win32 Apps
• Microsoft Edge (Setup and Updates)

Setup MCC:

Enable the distribution point as a Microsoft Connected Cache server

Once you've enabled the distribution point to function as a Microsoft Connected Cache server, the next step is to proceed with the installation process to confirm its successful setup. You can monitor this process through the distmgr.log file, which provides detailed entries from the initiation to the completion of the installation

When examining the distmgr.log, the installation process is encapsulated within a PowerShell script. This script includes checks for prerequisites, performs backups as needed, and initiates the installation procedure. The entire execution of this PowerShell script is logged in DoincSetup.log. Upon completion of all tasks, the results are reflected in both log files.

Other important aspects to review include the CacheNodeService website, Server Farms in IIS, and the DOINC folder located on the designated drive. Each of these elements should bear a unique identifier in their naming conventions.

Additionally, in the Task Scheduler, there are two tasks established for maintenance and ensuring continuous operation.

Configure DO and MCC for MDM devices

Considering a potential enterprise setup involving Delivery Optimization (DO) and Microsoft Connected Cache (MCC) for cloud-only Intune-managed devices

In considering a potential enterprise setup with DO and MCC for cloud-only Intune-managed devices, I will simply configure the DO setting DOCacheHost to point to the MCC of the ConfigMgr DP with MCC enabled. We will explore co-management later on. (Diag.1)

Delivery Optimization Configuration

To enable devices to utilize DO groups, connected cache, and peers, it's essential to create a Delivery Optimization policy. Here's an example of configuring these settings using the Settings Catalog policy type with Microsoft Intune

Choose settings from the list according to your network architecture, download mode, VPN, hardware devices, and other relevant factors.

Settings chosen for my test :

Setting | Value

DO Cache Host : 192.168.1.90

DO Delay Background Download From Http : 300

DO Delay Cache Server Fallback Background : 300

DO Delay Cache Server Fallback Foreground : 60

DO Delay Foreground Download From Http : 60

DO Download Mode : Group (2)

DO Group Id Source : AAD

DO Max Cache Age : 7

DO Max Cache Size : 20

DO Min Battery Percentage Allowed To Upload : 40

DO Min Disk Size Allowed To Peer : 32

DO Min File Size To Cache : 5

DO Min RAM Allowed To Peer : 4

DO Modify Cache Drive : %SystemDrive%

DO Restrict Peer Selection By : Subnet mask

Refer to Policy CSP - DeliveryOptimization to define the required values for your organization

DOCacheHost approach:

The DOCacheHost value could be distributed via DHCP option ID 235 instead of the static list available in the current Intune DO configuration profile for dynamic assignment. This approach offers more flexibility, especially for enterprises with many sites and multiple MCC servers as it covers roaming users. This simple setup should provide dynamic assignmentDO cache server (MCC).

In that case DO Group Id Source must be configured with DHCP value:

Other parameters are available depending on the design. For more details: DO Group Id Source

It's time to initiate a test to verify whether my client is configured correctly and is effectively utilizing the DOCacheHost setting.

Monitoring Delivery Optimization

In our example, we are using three machines: 192.168.1.147, named (A) in Diag1, 192.168.1.146, named (B), and 192.168.1.145, named (C). All tests, captures, and other activities are performed on machine A, which is currently downloading the Windows Update. Machines B and C have already downloaded the updates and Microsoft applications such as Office 365."

To make it even clearer and more detailed:

"In our example, we are using three machines:

1. Machine 192.168.1.147, named (A) in Diag1,
2. Machine 192.168.1.146, named (B),
3. Machine 192.168.1.145, named (C).

All tests, captures, and other activities are conducted on machine A, which is currently downloading the Windows Update. Machines B and C have already downloaded the updates and Microsoft applications such as Office 365. Additionally, our MCC is in standalone mode, installed on a ConfigMgr DP, and configured with the IP address 192.168.1.90."

Checking download in Background:

Get-DeliveryOptimizationStatus returns a real-time snapshot of all current Delivery Optimization jobs

Detailed information on the individual content downloads, including :

• Status: Downloading
• Priority: Background
• CacheServerConnectionCount: 1
• DownloadMode: Group
• CacheHost: 192.168.1.90

In the Wireshark trace, we can see the content downloaded filter on MCC IP address. There are several frame exchanges between our MCC and machine A, but what interests us is the frame where there is information about "Partial content," clearly showing the download URL of the content.

to confirm that in DoSvc log I used Get-DeliveryOptimizationLog

As you can see in the log there are other content requested from our Cache Connected Server but let's us concentrated on content ID: 9683b414-b9ac-40b1-81e8-4340320f1b5e for the rest of the analysis

In the MCC server, the content shown in the capture represents all parts of the requested content from machine A. it looks like the content is split into several chunks of 1MB each.

Bellow stats from IIS : Farm for tlu.dl.delivery.mp.microsoft.com whigh is responsible of Windows Updates.

disk cache statistics : from Node Health

The following Wireshark captures demonstrate that our configuration parameter "DO Group Id Source" is functioning correctly. The machines successfully discover the group from AAD for the 3 machines, whose members use the IGMPv3 protocol for multicast group management and LLMNR for multicast name resolution.

Internet Group Management Protocol (IGMP) Version 3

Link-local Multicast Name Resolution (LLMNR) address

Checking download in Foreground :

Foreground refers to User-initiate or Interactive actions. In this scenario I triggered Microsoft 365 Apps from Company portal:

Get-DeliveryOptimizationStatus returns a real-time snapshot of all current Delivery Optimization jobs

Detailed information on the individual content downloads, including :

• Status: Downloading
• Priority: Foreground
• CacheServerConnectionCount: 1
• DownloadMode: Group
• CacheHost: 192.168.1.90

The content is 1.68GB, which means the machine has downloaded approximately 1.7GB from the MCC server.

Highlights

1. The timestamp in DoLog is in UTC, which can be confusing.
2. The flow must also be opened in the physical firewall if necessary.
3. This design can be extended to on-premises devices using ConfigMgr and take advantage of the cache server to ensure that the cache content is populated by both on-premise and cloud-managed devices. The same applies to co-managed devices, which can utilize the same MCC.
4. In my configuration, I've set up a fixed DOCacheHost server and DOGroupIDSource linked to AAD, given that my LAB setup operates from a single site where roaming users aren't a concern. However, for enterprises, leveraging DO settings via DHCP provides versatility. This approach allows for effective management of groups, ensuring each has sufficient peers and minimizes WAN traffic within internal network.

Conclusion

Several other articles have covered Delivery Optimization (DO), but my focus is on detailing the installation process and especially on monitoring and tracking logs throughout the entire process. This includes comprehensive logging and monitoring to ensure smooth operation and troubleshoot any issues that may arise.