Your Image

Welcome to my corner of the web, where a love for automation meets a passion for perfecting the art of BBQ. As an aficionado in MEM, Enterprise Mobility, #Windows365, Identity, and the M365 security stack, I'm always knee-deep in code, tinkering with #MEM #MSIntune, and mastering #Powershell.

Join me on this nerdy adventure where we explore the intersection of technology and flavor, one efficient process and one mouth-watering grill recipe at a time!"

Microsoft Connected Cache

The battle for Bandwidth

Recently I’ve been having some trouble battling with Delivery Optimisation. It’s balancing act between effective deployments for Windows Updates, Drivers and software whilst ensuring stable connectivity across the network. With thousands of endpoints on each network it can be difficult to ensure that the fibre connection is not saturated. In recent times, configurations have been applied to different sections of my network to stagger when updates are pulled by devices from the web, this was the only real way to ensure stability especially one patch Tuesday. But with the introduction Microsoft Connected Cache (MCC) I am able to leverage a more efficient peer to peer technology to ensure that Apps and Updates are deployed across the LAN without saturating the network.

Previously DOINC would use a BranchCache as a broadcast source to determine which peers to service, but with the move to cloud services this is no longer a requirement. (hooray!) MCC now uses the Microsoft Delivery Optimisation Services for discovering peers on the network, ofcourse MCC Still utilised the DOINC technology.


Microsoft Connected Cache is currently a preview feature. For more information, see Supplemental Terms of Use for Microsoft Azure Previews.

Microsoft are currently still accepting Enterprise and Education customers to join the early preview. You can register here

It’s all so confusing!

It can be a little confusing when first looking at the network diagram for MCC, but behind the confusing terminology, arrows going left and right it’s just a caching server that your clients will look to for content. Simply put, devices are grouped with DHCP Scopes, a configuration to the MCC Service is applied via Intune and the devices then use peer to peer to deliver content. I’ve broken down the flow of the product below;

  1. Microsoft end-user devices make range requests for content from the MCC node.
  2. The MCC node pulls content from the CDN, seeds its local cache stored on disk, and delivers the content to the client.
  3. Subsequent requests from end-user devices for content will now come from cache.
  4. If the MCC node is unavailable, the client pulls content from CDN to ensure uninterrupted service for your subscribers.

What can I cache?

The great thing about MCC is that it supports a huge array of Microsoft Content and more is being added as Intune as matures. You can also implement some custom downloads using DO-Downloader more info can be found HERE about that.

  • Windows Updates
    • Feature Updates
    • Quality Updates
    • Driver Updates
  • Intune Driver Updates
  • Office 365 (Installation Files and Updates)
  • Microsoft Store Apps
  • Intune Win32 Apps
  • Microsoft Edge (Setup, Updates and Extensions)


To get up and running with Microsoft Connected Cache you’re going to need to meet the license and hardware requirements.


You will require one of the following license subscriptions for each device that gets content from a Connected Cache-enabled distribution point:

  • 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
Supported Operating Systems
  • Windows Server 2019 with Hyper-v role and network switched
  • Windows 10 with Hyper-v feature enabled

The hardware recommendations are just that, recommendations depending on the number of devices connected to the MMC service.

ComponentSmall EnterpriseLarge Enterprise
Network1 Gbps5Gbps
Disk1 SSD 50GB 1 SSD 200GB

Getting started

Getting started with MCC is easy, we need to do a little configuration within Azure, an automated deployment within Windows and configure a Intune configuration policy and finally testing on the devices. But don’t worry, I’m here to guide you through the process.

As the product is currently still in Preview there is no cost involved, this may change in the future. I will update the blog accordingly.

First lets hop over into the Microsoft Azure Portal and go to the Marketplace and search for Cache in the search bar, you can also use the URL HERE to go directly to the Marketplace.

Creating the MCC Resource

Lets go ahead and create the Cache Resource, you will be asked to select your Microsoft Subscription, the Resource Group you would like to attach the Nodes to and the Location. Currently there are only 3 locations available EU North, US West and Asia Pacific Korea Central. Choose a location best fitting for your needs.

Enter your Connected Cache Resource Name, this is important as it will be used to group your Nodes for configuration later. I have a simple naming convention I like to use, But feel free to use whatever you use!

Node Deployment

Now that we have our MCC Resource all setup, we need to add our Nodes. The nodes will be connected to your on-prem caching server. I already have 3 nodes configured, but I will setup a 4th node for this demonstration.

From inside your MCC Resource, Select Cache Nodes > Select Create Cache Node

Now enter a Cache Node Name – It’s important to keep these names simple but distinguishable so that you know which node is servicing which DHCP Scoped Group. Don’t worry, later we will go over how to setup these groups and scope them.

Now that your node has been created in Azure we need to grab the Provisioning Package, this contains the automated deployment scripts for the EFLOW node in our Windows Server.

Create a Folder where we will store all our provisioning files.

Enter your Windows Host IP Address and the size of your cache drive in GB, for this demonstration I am using 50GB but this will likely be much larger in production, click Save then Provision Server, it may take a few minutes to generate the scripts, once done Download the Provisioning Package and copy your provisioning command.

Deploying your MCC Node in Windows

For the purposes of this article I am going to assume you already have a Windows Server 2019/22 or Windows 10 machine setup with Hyper-V enabled, and it connected to your network. If you would like a guide on building a machine for MCC, please let me know in the comments.


Now the fun part, we’re going to use the provisioning package supplied by Microsoft to automate the deployment of the EFLOW VM and registration in Azure. This is fantastic that Microsoft provide this as it cuts down on the amount of work we need to do, especially if you aren’t familiar with Linux as this is what the node uses.

You should have your MCC Scripts downloaded and in a folder on your Windows client. I have mine saved in “C:\MCC“. Navigate to that Folder and Run PowerShell as Administrator, you should see the following files:


The files provided by Microsoft are not signed, so depending on your company security policies you may need to modify your execution policy. This can be done with PowerShell;

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process

We’re going to be running the provisionmcc.ps1 script with our command supplied when creating the node in Azure. Go ahead and copy paste the command into the PowerShell Window and press Enter.

You will be prompted to allow the script tun run, type R and press Enter.

The Provisioning Process will begin. You will be asked to enter some information during the first phase of the script. These are all specific to your environment such as the IP settings and VM Settings like Memory, CPU and Storage. But if you’re having any issues feel free to contact me.

The installation process can take quite a bit of time to completed depending on your network speed, the script will download the required files from Microsoft. It took around 15 minutes for my deployment. So go grab a coffee and let it do it’s thing! Below is the steps the script will run through during provisioning:

  • Installs Azure CLI
  • Downloads, installs, and deploys EFLOW Hyper-V Machine
  • Enables Microsoft Updates for EFLOW
  • Creates a virtual machine
  • Enables the firewall and opens ports 80 and 22 for inbound and outbound traffic. Port 80 is used by MCC, and port 22 is used for SSH communications.
  • Configures Connected Cache tuning settings.
  • Creates the necessary FREE Azure resource – IoT Hub/IoT Edge.
  • Deploys the MCC container to server.

Installation Complete

The script should have completed without error and your EFLOW VM should be connected to Azure. You can check this by going to your Microsoft Connected Cache Resource in Azure then Cache Nodes – There you will see the the device status of your EFLOW VM. We can also use PowerShell from our MCC Host to query the EFLOW Client.


Connect-EflowVm; sudo -s;iotedge list

You can see that the MCC Services are all connected successfully to the Azure! Nice.

With our EFLOW Edge Agent running and successfully connected to Azure this completes the first portion of this Microsoft Connected Cache Deployment guide. In the next post I will cover how we can configure our DNS Groups and push out our MCC Settings to Intune Clients.

Quick Note

I hope this article has been helpful, this is my first technical writeup so some feedback would be greatly apprechiated. I’m still very new to writing like this, so I hope it’s not too boring!


  1. How is the e5 license applied by user or to a device?

    Any tips on how to tell if it’s working from the client side?

Leave a Reply

Your email address will not be published. Required fields are marked *