Implement Microsoft Connected Cache with SCCM
At Ignite 2019, Microsoft announced the Connected Cache (previously known as Delivery Optimization In-Network Cache (DOINC)). I’ll take a closer look at it now. But what do you really need it for?
- How does the Connected Cache work?
- What will be supported?
- The requirements
- Activating the Microsoft Connected Cache
- Verifying Microsoft Connected Cache
- Distributing the settings without SCCM
- Configuring Connected Cache with Group Policy
- Configuring Connected Cache via Intune
- DHCP Optionen for Connected Cache
- Personal conclusion
Let’s take a classic scenario, a company uses Autopilot and Intune for provisioning. Now that the hardware is written off, 100 new devices are purchased and provisioned. Doesn’t sound unusual yet, does it? Let’s take a look at some data:
- Microsoft 365 Apps for Enterprise / Office 365 ProPlus has just over 2GB of installation files
- The last cumulative updates e.g. 05/2020 (KB4556799) about 367.2 MB for the 1909 x64
- One GB for half a dozen Windows Store apps, for example the GUI for the UWP drivers or the Local Experience Packs.
- Let’s assume another 9GB for other software
The total is about 12.5 GB times 100, that is 1.25 TB, which the clients download. If the 100 Mbit line is not in use, this is done in about 27 hours. If you’re lucky, the proxy will store some of the data.
The numbers can be used to play as many games as you wish, but 10 GB is quite typical. What can help is Microsoft WhiteGlove, but that is not the point. Why is there no Simple Caching Solution from Microsoft?
But there is, that is what this article is about. I admit the previous example is a little bold. Depending on the configuration of the Delivery Optimization, peer caches or a possibly existing branch cache are also used for some things. But not for everything. The Microsoft Connected Cache is supposed to fill this gap and be automatically managed by the cloud. So a “set up and forget” solution. Unfortunately, it is not yet available as a stand-alone version for Windows Server or Linux, but it is included in the System Center Configuration Center.
How does the Connected Cache work?
- The clients are configured by SCCM for Connected Cache and Delivery Optimization. This includes the Cache Server. In the future, this can also happen with Group Policy or DHCP option. More about this later.
- The clients check for Windows updates and get back the CDN URL of the download.
- The clients check if the Cache Server already has the information.
- If the server does not have the information, it gets the missing parts from the Microsoft CDN
- If the cache server is not available, the clients get the data directly from the CDN
- Since the data is now in the Connected Cache and also in the peer cache of the clients, other clients can obtain the data directly via Delivery Optimization.
What will be supported?
The following functions are currently supported:
- Microsoft Store and Store 4 Business applications
- Windows features on demand, for example language packs
- Windows Updates 4 Business
- Microsoft Office Click-to-Run
- Microsoft Endpoint Protection
- Microsoft Edge (Chromium Base)
Configuration Manager 1910 should also support Intune Win32 apps.
- The intended server must have at least Windows Server 2012 as operating system
- The default website (IIS page) must be accessible via HTTP on port 80
- The distribution point must have direct access to the Internet. Support for authentication-free proxy is planned in Connected Cache 2002.
- The clients need at least Windows 10 1709 to use the function
Please do not install any functions (such as IIS functions like ARR) before.
Activating the Microsoft Connected Cache
Open the SCCM console and navigate under “Administration” to the item “Distribution Points”. Select the desired Distribution Point, open the context menu with the right mouse button and select “Properties”.
In the properties dialogue you will find the checkbox “Enable this distribution point to be used as Microsoft Connected Cache server” in the “General” tab. Activate it and configure the location and scope according to your needs. It is better to be a bit too large for the cache in your environment. In my test lab, I choose 50GB due to resource limitations. The default value is 100GB cache size.
The actual installation runs in the background take a few minutes, enough to fetch a coffee and drink. Depending on the performance of the system, with SSD for the OS and HDD for the data disk, it took more than 15 minutes. After that, I followed my advice…
Next, you must adapt the corresponding device policy in SCCM. To do this, go to the “Client Settings” under Administration and open the properties of the corresponding policy. Under “Delivery Optimization”, set the option “Enable devices managed by Configuration Manager to use Microsoft Connected Cache servers for content download” to “Yes”.
Verifying Microsoft Connected Cache
Before you get started right now, of course, the policy must first be distributed to all clients. This also requires a reason to use the cache. There is little to see before that happens.
Check usage on the client
On the client, you can use the “Get-DeliveryOptimizationStatus” PowerShell command. You can see the number of bytes delivered through the cache under the BytesFromCacheServer property. However, this Commandlet is only supported on Windows 10 1809 or later. Also, not all return values are available in every version of Windows 10. Under 1809, for example, the CacheHost is not included in the output but seems to be used. Importantly, the Get-DeliveryOptimizationStatus command only reflects an actual snapshot.
In the 20H1 Release Preview there is also a GUI for display the usage of Microsoft Connected Cache:
Since this machine is the only one with this release of the preview, the utilization is rather low. Especially since certain programs like Microsoft Office and Edge were already installed.