After waiting for what felt like forever, Microsoft Connected Cache for Enterprise and Education is now in public preview. And needless to say, I was eager to get my hands on the product and test it out in the lab.
What is Connected Cache?
Connected Cache is a software-only caching solution that helps organisations by storing (compatible) packages locally and distributing them to clients locally. The result? Reduced consumption of internet links and faster distribution of content to client devices.
Connected Cache isn’t a new concept; it’s been available to run on ConfigMgr Distribution points for some time. However, this is the long-awaited standalone version that I’m putting to the test – and I’ll take you through what I did step-by-step.
First, the ‘need to know’ stuff.
What are the three main prerequisites to using Connected Cache?
- You must be licenced for Windows 10/11 E3/E5/F3/A3/A5 (or Microsoft 365 E3/E5/F3/A3/A5)
- You will need an Azure Subscription
- You need a Cache Node Machine – this can be running Windows 11 or Server 2022 or higher, or Linux (Ubuntu 22.04 or Red Hat 8.* or 9.*) And it needs:
a) At least 4GB of free memory
b) Port 80 to be free, i.e. not in use on the host
Anything else you need to know?
Yes – for additional details of prerequisites see:
https://learn.microsoft.com/en-us/windows/deployment/do/mcc-ent-prerequisites
Will it cost you anything?
No, and then possibly yes. According to the Microsoft Documentation, the Azure Resources used for Connected Cache will be free to you during this public preview. But (and there had to be a ‘but’) once out of preview, there may be a cost associated with using those resources. So, watch this space.
So, here I (we) go: Building the Cache Node
My first step was to build the Cache Node. To do this, I created a Hyper-V VM (virtual machine) with 4vCpus, 6GB Ram and 128GB disk (with TPM enabled).
As I planned to use Windows 11, I’d also need Windows Subsystem for Linux – which relies on nested virtualisation. So, before I fired up the VM, I made sure nested virtualisation was enabled using an Admin PowerShell session and running:
Set-VMProcessor -VMName -ExposeVirtualizationExtensions $true
Next, I installed Windows 11, ran updates, and gave the machine a static IP.
I then created a local user account and assigned it local admin rights. I also made sure that the administrators group had logon as service rights in the local group policy. Tip: You can use group managed service accounts for this too.
The Microsoft Documents don’t currently specify the exact permissions needed for this user account, so local admin may be overkill, we’ll have to wait for the current docs to be updated to confirm this though.
Finally, I installed the Windows Subsystem for Linux using
wsl.exe -install -no-distribution
and restarted the machine to complete installation. Now, this step can be tricky if there are pending reboots, so make sure your box is up to date first!
What next: Creating Azure Resources
My next step was to head into the Azure portal (portal.azure.com) to create the Azure Resource, which manages the Cache Nodes.
In the Search Bar, I then searched for Connected Caches for Enterprise & Education and selected Create Connected Cache for Enterprise & Education.
Here, I selected our subscription, resource group, location (which is very limited at this stage) and gave the resource a name.
Note: This step is me just setting up the ‘controller’ for lack of a better word, rather than setting up a cache that’s running in the Melbourne or Sydney Office (that will come later).
Onto creating a Connected Cache, and configuring it
From here, I clicked Review + Create, and then waited a couple of seconds for validation before clicking Create. Now, this step almost tricked me as you get a Green Tick for the validation! Hopefully Microsoft might consider changing the original button to just Validate rather than Validate + Create.
Anyway, this step brought up the standard ‘Azure Deployment is in Progress’ screen, and before long I was able to press ‘go to resource.’
I then expanded out the Cache Node Management and clicked on Cache Nodes and Create Cache Node.
Now, I was able to create an object for each local Node that we might have (think different offices or locations).
At this point, I gave the Node a name (I went with the always-catchy name: LABHV03-MCC) and specified Windows as the OS.
From here, I clicked Create and waited a minute before hitting refresh. And hey presto – I could now see my shiny new Cache Node object with the status of Not Configured.
By clicking on the Node Name, I could enter some configuration settings, mainly Cache Drive Size (and proxy settings if wanted – which I didn’t). In this example I entered 70GB, clicked Save and moved to the Provisioning Tab.
(Please note that the MCC Installation is approx. 8GB – so take that into account when defining this so you don’t use up all your available disk space. You need to make sure you leave room for OS updates and any other applications also on your machine.)
On the Provisioning Tab there’s a PowerShell command that will be generated (see the pic below). This took a while. Tip: Ensure you select the correct user type!
While waiting for the command to generate, I downloaded the provisioning package and extracted that on the Node I set up first (C:MCC-SWL-Installer), but obviously, you’ll choose your own location.
From here, I opened an Admin PowerShell prompt (lesson learned: don’t use PS7 when you do this as the scheduled tasks don’t create correctly).
To define some variables that will be used by the provisioning command that’s busy generating in the background of Azure, I ran the following (change to suit your scenario):
$user = "connectedcachemcc" $pw = ConvertTo-SecureString "PASSWORDOFLOCALACCOUNT" -AsPlainText -Force $myLocalAccountCredential = [pscredential]::New($user,$pw) set-executionpolicy unrestricted
I then refreshed the Connected Cache provisioning page and grabbed the resultant Cache Node Provisioning command (ensuring I selected the right account type – of course!).
Note: You’ll also want to change the directory to the folder you extracted the provisioning package from: C:MCC-SWL-Installer, and then run the command copied from the portal. This command is a one-use command (per successful registration), and each Node will have a different command.
Running the command extracted an Ubuntu image and loaded the Connected Cache container. It took about 30 minutes to complete, and I received a ‘0’ return code indicating success.
I also checked the Connected Caches Portal to make sure the Node was reporting as healthy.
Optimising delivery!
Next, I edited my Delivery Optimisation policies and added in the IP/FQDN of the Connected Cache node.
I moved on to syncing my devices to bring down the updated policy and downloaded some Win32 apps. To test the outcome, I used an in-place Upgrade Media Pre Cache Win32 Application and Asphalt 8 from the Microsoft Store.
The first machine to download it took a normal amount of time. On the second machine, I monitored the network utilisation on both the Cache Node and the test VM, and noticed the throughput from the Cache Node ‘send’ matched the ‘receive’. Nice!
I also checked the Delivery Optimisation activity monitor on my test devices and found that in some cases I was getting 90+% Cache Usage! However, that was a test where I knew the content would be cached – but pulling down non-peerable content (like MSIX Installers and Windows Package Manager installs) will bring that statistic down.
So, what do I think?
This is a wonderful product, that I’m sure will only get better as time goes on. Connected Cache will most definitely help organisations reduce the load on their internet link when pulling content from Microsoft.
And hopefully it will stay free, too!
Want to learn more?
For more (official) information please read the Official Microsoft Documentation:
https://learn.microsoft.com/en-us/windows/deployment/do/mcc-ent-edu-overview
