Delivery Optimization with Intune and Microsoft Connected Cache (MCC)

Intune managed devices must be configured to leverage Delivery Optimization (DO) to reduce the overall internet bandwidth usage. It is a distributed cache solution using peer to peer transfers for content downloads. It is a very well designed solution especially for the cloud era. The latest addition to that concept is the so called Microsoft Connected Cache (MCC) formerly known as DOINC (Delivery Optimization In-Network Cache).

Let’s start with a short introduction into Delivery Optimization. As already mentioned it is designed for the cloud era which means it does not rely on peer discovery based on broadcast like BranchCache does. It utilizes the cloud (Microsoft Delivery Optimization Services) for peer discovery. The cloud tracks peers based on a defined grouping strategy. This way clients requesting content can get peer lists belonging to their group.

1. Microsoft Intune configures Delivery Optimization (DO) settings on the devices, including the Microsoft Connected Cache (MCC) server name (DOCacheHost)
2. Device A checks for Windows Updates and gets the address for the content delivery network (CDN)
3. Device A requests content from the MCC
4. If the cache does not have the content, the MCC gets the content from the CDN
5. If the MCC is unavailable or fails to respond, the device downloads the content from the CDN
6. Devices A,B, and C still use DO to get missing pieces of content from their other peers

Okay clear, the MCC acts as a transparent proxy to cache content.

Which content is supported?

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

Looks like a complete list, right? Actually for an Intune managed device this should represent the complete list of content you have to deal with regularly. If we get the DO implementation right we can enjoy great working peer to peer content delivery supported by an additional cache server.

Where do I get the MCC now?

During time of writing this article the MCC can only be installed on a Configuration Manager Distribution Point.

I won’t get into details about the MCC installation for Configuration Manager here, my MVP fellow Peter van der Woude wrote a good blog post about it here: Microsoft Connected Cache in ConfigMgr with Win32 apps of Intune, you can just follow his instructions to get the MCC up and running.

At Ignite 2019 they announced the Microsoft Connected Cache managed in Azure, which is a standalone version of the MCC. Meaning it can be installed without ConfigMgr and is based on a lightweight Linux container. This is a major announcement in my opinion as it can probably deployed easily and may run on a lot of devices finally. During writing, this was only available as private preview and not for public preview to test this out. The biggest advantage on using a Linux container means, we don’t have to pay additional licenses to spin up a MCC device. If we want to deploy a MCC later it should be fairly easy to find a device which can run Ubuntu Server 16.04. Of course it is also supported on Windows Server 2019. These are the two supported OSs at the time they announced it at Ignite 2019. I assume more Linux distributions will follow as soon as it is released public. If you like to learn more about the MCC, I really suggest to watch the great Ignite 2019 session “Stay current while minimizing network traffic: The power of Delivery Optimization” from Narkis Engler and Andy Rivas (thumbs up!).

Looking at a possible enterprise setup with DO and MCC for cloud-only Intune managed devices

I did various implementations for Delivery Optimization in cloud-only environments. I’m going to use my typical DO setup which relies on DHCP option to distribute the DOGroupID and add a MCC to the design. As I’m not able to use the standalone Linux container version I will use a MCC on a ConfigMgr Distribution Point (DP). To be clear I will not use a co-managed device, the device will still be a cloud-only device, managed by Intune standalone. I will just point the DO setting DOCacheHost to the MCC of the ConfigMgr DP with the enabled MCC. This way the MCC will behave the same as a standalone version later. No ConfigMgr client will be used to update the DOCacheHost setting based on the Boundary Groups.

Why do I want to test this out?

What I’m especially curious about is the DHCP option to build a dynamic value assignment of DOCacheHost. Similar to the ConfigMgr DOCacheHost value assignment with the help of the boundary groups concept (see ConfigMgr docs here).

At the mentioned Ignite session there was the information that the DOCacheHost will be configurable by DHCP Option ID, like we already have for the DOGroupID. See the copied slide from the Ignite session:

Finally the Windows 10 version 20H1 release is scheduled for March/April 2020 and most of the features should be in a final state in the latest Insider version right now. This lets us build a fully functional lab environment with an Insider Windows 10 VM, MCC on ConfigMgr used same way like a standalone installation, and DOCacheHost value distributed via DHCP option ID 235 instead of the static list available in the current Intune DO configuration profile:

Prerequisites

As already mentioned we need some components for this:

• ConfigMgr Distribution Point with MCC installed
• Windows 10 Insider VM (I used the build 19577)
• Microsoft DHCP Server with pre-defined option ID 235
• Microsoft Intune DO configuration

Gathering the missing MDM config info to do the actual configuration

First, I installed the Windows 10 Insider VM and had a look at the new DO GPO settings. Bingo, here I found the indicator of the new DOCacheHostSource setting using the DHCP option 235:

By looking into the registry we can verify the according MDM setting for DOCacheHostSource:

I constructed the custom configuration profile by building the OMA-URI and setting the value to 2 to use the Cache Server Hostname delivered by the DHCP option 235 instead of a configured DOCacheHost value in the Intune configuration profile:

OMA-URI:
./Vendor/MSFT/Policy/Config/DeliveryOptimization/DOCacheHostSource
Value: 2 (Integer)

Next, I needed to setup the DHCP option ID 235 like my regular DHCP option ID 234, which I use to distribute the DOGroupID to my clients. I added an additional predefined option:

Then I configured on the DHCP scope a new scope option by adding the new predefined option with the IP of the ConfigMgr DP/MCC in my case the 192.168.1.51:

In my lab I use also the DHCP option ID 234 for DOGroupID distribution. My DO config for the clients is Download Mode 2 (Group Mode) and the Group ID source DHCP user option:

This simple setup should provide dynamic assignment of DO group ID and DO cache server (MCC). This is the scenario I use the most, as it covers roaming users and provides most flexibility in grouping your devices cleverly together. Now it is time to start a test to see if my client gets configured and finally uses the DOCacheHost setting from DHCP.

Let’s start with the client MDM setting. Checking the MDM Diagnostics HTML Report I found my setting applied on the device:

I can see on the Intune service side that the policy is applied successfully:

MDM setting is working, now let’s have a look if we can trace if the DO config is actually used by the Intune managed device during content downloads. Luckily Microsoft extended the DO PowerShell cmdlets and also added more information in their generated output. So, I started Windows Update and a Microsoft Store download and had a look at the log files.

We can use the following command to get the last 100 log file messages for Delivery Optimization:

Get-DeliveryOptimizationLog | select Message -Last 100

after a quick look I spotted this:

This is a clear indicator that my MDM setting is recognized and used by the DO components. What made me very happy is the following lines I spotted in addition:

Here we can see the GroupID is also provided by DHCP and the DOGroupID is actually listed there as clear text. This is a major enhancement for troubleshooting and analysis. In the past this value was encoded and it was always cumbersome to deal with it during troubleshooting. Thanks for that!

Finally I’m also glad about the new PowerShell cmdlet:

Get-DeliveryOptimizationLogAnalysis [-ListConnections]

For a quick summary check on the client this is very helpful, here the output of my lab Insider VM:

In addition you find two more cmdlets for DO which are super helpful:

Enable-DeliveryOptimizationVerboseLogs
Get-DeliveryOptimizationStatus -PeerInfo

If you like the graphical representation of DO statistics you can also have a look at the Windows Update Delivery Optimization Activity Monitor in Settings. Microsoft added a separate category for the Microsoft Cache Server:

You can read about some more network throttling enhancements in Windows 10 Version 20H1 here in the section Delivery Optimization:

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/pilot-new-features-with-the-windows-insider-program-for-business/ba-p/1220464

The setup is done and working, I could easily see improved content download times with a second VM. The MCC and the dynamic assignment is working as expected. I’ll probably update the blog post as soon as we get the MCC as Linux container to include the details of the install and Azure portal reporting. For know, I’m happy to see that we can have dynamic DO settings assignment via DHCP and can also use existing ConfigMgr DPs if they have installed the MCC component. The way of distributing the DO settings via DHCP options gives enough flexibility to control your grouping to have always enough peers in one group and prevent possible WAN traffic in you internal network. Roaming users can instantly benefit from a MCC on a larger site and still use normal DO peer to peer as it works in parallel.

For me this is something I’m looking forward to. Taking care of bandwidth utilization is a very important part of every modern management project and DO is the key technology here. I hope this helps people understanding DO a little more and demonstrates that a very flexible DO concept can be implemented.

For some Microsoft recommendations about Windows servicing and Delivery Optimization settings I can recommend to have a look here:

Real-world practices to optimize Windows 10 update deployments
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/real-world-practices-to-optimize-windows-10-update-deployments/ba-p/1227825

Happy caching and bandwidth optimization!