Let’s rewind a bit. I cut my teeth in network security with the Marines back when “zero trust” meant trusting no one to configure their router correctly. Later, in the healthcare world, I had to keep remote clinics updated using SCCM without accidentally nuking their limited bandwidth. We’re talking about places where a large patch could bring the whole network to its knees. That’s when I discovered the magic of caching.

Fast-forward to today: I live in the world of Intune, and Delivery Optimization (DO) is one of my favorite tricks for speeding up deployments without hammering the internet pipe. Let’s break it down and explore how to make Delivery Optimization and Microsoft Connected Cache your new best friends.

What Even Is Delivery Optimization?

Think of Delivery Optimization as a smarter way to download content on Windows 10/11. Instead of each device reaching out to Microsoft individually, DO lets devices talk to each other and share the goods locally. It pulls updates and apps from the cloud, from peers, or from a local cache server whichever is fastest.

This is perfect when you’re deploying Microsoft 365 Apps, Win32 apps, or a mountain of Windows updates to a fleet of devices. Don’t worry, DO is polite it dynamically falls back to the cloud if no peers are available.

How DO Actually Works (Without the Acronyms Overload)

When a device needs an update, it grabs metadata from Microsoft, then checks in with the DO cloud service using several different types of modes: “Hey, any neighbors got this file?” It looks for:

  • Peers in the same group (configured by subnet, tenant ID, etc.)
  • A local Microsoft Connected Cache server
  • Microsoft’s CDN (if all else fails)

The content comes down in chunks, mixing and matching sources based on speed and availability. The end-user? Blissfully unaware.

How Delivery Optimization Works (High-Level): When a client needs, say, a Windows update, it contacts Microsoft’s service to get the metadata and content URL as usual. With DO enabled, the client then asks the DO cloud service for peer candidates (other devices in the org that have or are downloading that content). It also checks if a Connected Cache server is configured. The client will then download content in chunks: some chunks from peers on the LAN or in the same group, some from the local cache server, and any remaining from the CDN. This is all transparent to the end-user. If a peer or cache is slow or unavailable, DO automatically switches to another source or back to the cloud, so reliability is maintained.

Setting Up DO via Intune: The Easy Button

Intune offers a built-in template (and as of April 2025, a Settings Catalog profile format) specifically for Delivery Optimization settings.

Create a DO Profile Head to Devices > Configuration profiles in Intune and create a new one using the Delivery Optimization template. Alternatively, you can use the Settings Catalog for these options.

Key Settings to Know In an effort to keep this blog semi-short, I’ll just touch on some key ones to configure. For a better explanation of the settings, use the Microsoft Docs. I’ll also add all of those times your math teacher said “you’ll use math later on in life”…. Well, when you get in here and start configuring you will know they were talking about (lots of math).

  • Download Mode – This is the core setting that controls peer-to-peer behavior. For example, LAN (mode 1) restricts peer sharing to the same NAT/local network, Group (mode 2) enables broader grouping (e.g. via domain or Entra Tenant ID) which can even peer across remote networks if group IDs match, and Internet (mode 3) allows getting peers beyond the local network (including via cloud). Typically for Intune-managed devices, I’ve used Mode 2 (Group) or Mode 1 (LAN) is used to enable peer sharing within the organization. If you have a Connected Cache server, you still enable peer modes the cache acts as an additional source, not a replacement for P2P.
  • Restrict Peer Selection – You may limit peer discovery to the same subnet or configure Local Peer Discover to ensure only specific sets of devices share content.
  • Foreground vs. Background Jobs This one’s sneaky.
    • Foreground = User-initiated (like the Windows Update screen or Store).
    • Background = Silent installs or scheduled pushes (think Intune required app deployment).
  • Simple Peer Limits and Policies – You can control upload limits, disk space usage, battery thresholds, etc. I usually leave these at default unless there’s a specific use case.
  • Cache Related Settings – If you are deploying a Connected Cache (discussed later), here is where you specify the hostname or IP of your cache server (DO Cache Host).

Setting Up Microsoft Connected Cache (MCC): Your Local Update Sidekick

Now let’s level up. Microsoft Connected Cache is a free Azure service that acts like a mini Microsoft CDN living in your environment. This is perfect for branch offices, remote sites, or anywhere that needs updates without wrecking the WAN.

Create the Connected Cache Resource in Azure

  • First, ensure you have an Azure subscription where you have sufficient permissions. Connected Cache is a free service, but it requires a subscription to manage the resources.
  • Go to Create a resource and search for Connected Caches for Enterprise and Education
  • Create the Resource: Click Create and fill in the basics:

Add a Cache Node

Head into your Connected Cache resource and go to Cache Node Management

Click + Create Cache Node

Choose Windows as your host OS and give it a name.

You’ll see the new node show up as “Not Configured” don’t panic. That’s normal.

Configure Cache Node Settings

Click on your cache node in the list to open its configuration pane. Here, you’ll need to specify:

  • Cache Drive Folder – For Windows, the cache is stored in a path within the WSL container. The default (and required) path is /var/mcc. (You don’t change this for Windows nodes)
  • Cache Drive Size – Allocate how much disk space the cache can use, in GB. Minimum is 50 GB. I recommend more if you’re caching big update payloads.
    • There is a known issue with the size of the cache that is supposed to be fix when this feature goes GA. The size can more than double since it’s a Dynamic VHDX. More information here.
  • Proxy settings – Only needed if your server uses one. I skipped it.
  • Provisioning – I will be using a local account. I guess I need to set up a domain at some point. That sounds like a next weekend project.
  • Updates – The cache software can auto-update. You can choose Fast or Slow ring. Slow allows you to specify a maintenance window (day/time of month) when updates occur. For a test environment, you can leave it as fast or default.

Save the configuration after entering these details. The cache node’s state might briefly change as it accepts the config. Once it is configured in Azure, we move to deploying it on the actual VM.

Deploy the Cache Container (on Windows Server 2022+)

Now it’s time to install the container:

  • Spin Up a Windows Server with WSL enabled. Also ensure the Windows Subsystem for Linux (WSL) is enabled on that server, since the cache runs as a Linux container on Windows. (Enabling WSL requires a reboot and an admin PowerShell command like wsl –install if not already enabled.) Since WSL is required, be sure your server supports nested virtualization.
  • Download the Provisioning Package from Azure and move it to your server. Extract the package to a folder on the server, e.g. C:\MCCInstaller\
  • Copy the Provisioning Command: In the Azure portal’s Provisioning tab, you’ll also see a PowerShell command pre-filled with parameters (customer ID, cache node ID, keys, etc.). This is the command that actually registers and sets up the container on your VM. Copy this entire command text and save it (you will run it in a moment on the VM).
  • Prepare a Service Account: The cache container on Windows cannot run as Local System; it requires a user context for security isolation. You have two options:
    • Create a gMSA (Group Managed Service Account) in your domain to run the container.
    • Use a local user account on the server as the runtime account.

Either account will need “log on as a batch job” permissions.

  • Run Setup on the VM: On the Windows server, open PowerShell as Administrator and navigate to the extracted provisioning package directory (cd C:\MCCInstaller). Before running the script, ensure execution policy will allow it. I am borrowing the variables used already to fill in the script.

Your output should look similar. It’s pretty clear on how to resolve errors.

If something goes wrong, don’t stress. Common fixes: reboot the server, make sure WSL is installed, or double-check your permissions.

Wrapping Up (For Now)

This post got a bit long (whoops), so I’ll cover troubleshooting tips and logs in a follow-up post. But if you’ve made it this far, congrats you’re now equipped to optimize updates like a pro.

Author Dustin Gullett

You Might Also Like

Intune Primary User Mix Up

Need-to-Know Entra Device Group Info? This Script Has Your Back

This Is Not Just Another LAPS Post…Promise!