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 https://aka.ms/MSConnectedCacheSignup.
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;
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.
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:
The hardware recommendations are just that, recommendations depending on the number of devices connected to the MMC service.
| Component | Small Enterprise | Large Enterprise |
| Network | 1 Gbps | 5Gbps |
| Disk | 1 SSD 50GB | 1 SSD 200GB |
| Memory | 4GB | 8GB |
| CPU | 4cores | 8cores |
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.
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!
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.
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:
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.
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!
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?
The devices would be enrolled in Intune with a Device Enrolment Manager account which licenses the device. More information can be found here: https://learn.microsoft.com/en-us/mem/intune/enrollment/device-enrollment-manager-enroll