As many of us have been waiting on the standalone version of the Connected Cache offering since it was first announced at Ignite last year, I’m posting this to give an idea of how you can easily test the current version of Connected Cache that’s included with Configuration Manager, while still managing policies via the Endpoint Manager Admin Center. Let’s start off with the obvious question – what if you don’t have Configuration Manager deployed in order to test this capability out?
Well, for that we revisit the Windows and Office Deployment Lab Kit, which includes way more than we need, but is a no fuss way of getting things up and running if you don’t want the responsibility of setting things up from scratch. The only virtual machines you need for the scenario I’m covering are HYD-CM1, HYD-DC1 and HYD-GW1, you can safely delete the other VMs it creates. In the image below you will see that that there are twelve Windows Autopilot VMs that are being used for this post and the upcoming post in this series.
As these VMs are deployed onto a multi network adapter workstation, I’ve made some changes to the default networking settings for the external switch on HYD-GW1, and added a second network adapter. What are these changes? First of all, I’ve dropped the throughput of the gigabit network adapter on the external switch for HYD-GW1 to 10Mb/s.
Yes, you are reading that correctly 10Mb/s. There are two reasons for doing this, the first being that working from home means I don’t want anything faster saturating an connection that is already getting used quite heavily. The second is that it effectively forces more traffic to come from other Delivery Optimization sources if they are available. Once you see the results table later in the post you will see what I mean. There is just under 3.5GB of apps (a mix of Win32 via Intune, Edge release+beta+dev, M365 Apps for Enterprise beta channel and Store apps) being deployed to each VM, but only about 100MB per VM of that is coming from the Internet because there are better options available.
The second change I made was adding a second network adapter to the HYD-CM1 VM, exposing it to other devices on the network, not just the Windows Autopilot VMs. This effectively keeps the Connected Cache content fresh, for the next time I want to do some similar testing. The second network adapter does not have it’s throughput restricted like I have with the external switch in use by HYD-GW1, because I want it to be able to pull down what it needs as fast as it can, while minimizing the chance that the VMs have to fall back to Internet based downloads.
We still need to enable Connected Cache on the HYD-CM1, and this is pretty easy. What I’ve done prior to enabling it is creating and mounting a virtual disk to CM1, in this case dynamically expanding up to 200GB, and assigned it drive letter D:. You need to give the process a few minutes to complete, and you can run the tests listed on Troubleshoot Connected Cache. All you really need to start is to check the Enable the distribution point to be used as a Microsoft Connected Cache server checkbox and configure the drive option to suit your needs.
Let’s move on to the results for twelve identically configured Autopilot VMs on the same virtual network, with a high speed prepopulated Connected Cache, and a throttled internet connection. Enough time was allowed between signing in to each VM that the previous VM had completed or mostly completed it’s application installations, but there was nothing strict about the timekeeping. Think of it as being a background task I was checking in on occasionally. I could have used a better scenario as an example, such as I simulated receiving new devices and was going through the unboxing etc., but also requiring distracting caffeine and meal breaks, but let’s be honest, the timing of sign ins on new VMs wasn’t spaced out evenly.
If we take a look at the results, the first thing you will notice is that I’ve got two columns purporting to be data directly from Microsoft. What you will notice though is that they are all about 100MB larger than what came from Connected Cache. I know that first row isn’t accurate, because in total there was less than 4GB of traffic on HYD-GW1’s external connection. It could be the non-standard configuration I have, but it looks suspiciously like Connected Cache traffic is also being counted in the from MS traffic, so let’s assume that’s the case based on the evidence. The other thing is that the Connected Cache data closely matches as what HYD-CM1 was showing as outbound traffic, right around 20GB, matching what we see in the table.
What settings am I using? Take a look at the image below for more details, but the important ones are giving Peer DO settings 60 seconds of delay before falling back to HTTP, and let’s admit it, a probably excessive 3600 seconds for delaying from Connected Cache to HTTP. Remember though, it’s excessive because I didn’t want that 10Mb/s network adapter slowing everything down.
So what are the takeaways, and how can you apply them? The first is that you won’t see these exact results, and nor will the next time I test this. While there are definitely some patterns we can see, such as the more PCs that are running as other machines come online and require the same apps, the less we need to rely on Connected Cache. However, in most environments, including deployment labs, the test PCs, whether virtual or physical tend to get wiped regularly, so having Connected Cache as the initial source provides a huge benefit. In a regular office environment with devices coming and going, you will have a better chance of DO being able to deliver what you need quickly, even if you are the only person in the office with a device that’s turned on.
For part two, I’ll follow the same non-rigid process, but without the benefit of Connected Cache. If there is anything in particular you want to know about other parts of the configuration let me know. I think I might need to adjust the Delay HTTP download times to give peer distribution more, but I’ll start with the same settings and adjust if needed and report on those results.
intunedin.net 