Use Microsoft Connected Cache to Accelerate OS Downloads
Is your feature request related to a problem? Please describe. With Microsoft rolling out standalone Connected Cache in preview, it would be helpful to have the ability to utilize network-local Connected Cache Nodes when downloading the Windows ESD image and drivers hosted by Windows Update. This would drastically reduce outbound network usage for large deployment loads (ex. only need to "download" Windows ESD once for 100+ device stagings).
Describe the solution you'd like
Before downloading content from Microsoft's CDN, check for DHCP option code 235 (DOCacheHost) on the client which, if configured for Connected Cache, will contain the local Connected Cache Node's FQDN or IP address (Source). If the value is set, rearrange the content download URL to use the connected cache endpoint:
http://[HostMachine-IP-address]/filestreamingservice/files/<file-hash>/<file-name>?cacheHostOrigin=<original-MS-download-server-FQDN> (Source)
If the file has not yet been cached by the Connected Cache Node, it will fetch the file from Microsoft's CDN, cache it on the node, and serve it to OSDCloud as if you had downloaded directly from the CDN. Future requests for that file would then be served directly from the Connected Cache Node.
Make use of this feature optional to allow administrators to choose not to use this solution (ex. option code 235 is in use elsewhere).
Describe alternatives you've considered Running a cache solution that sits on the entire network is also an option, though this would present extra setup/maintenance burden to administrators and might not always be allowed in a corporate environment. For example, LANCache or a similar solution can serve this purpose but would require extra configuration, an extra server separate from any existing Connected Cache node, and redirection of all DNS on the network in order to function effectively.
Additional context I work as an administrator for a medium/large Microsoft shop, and we are currently testing Connected Cache for use across our global footprint. Being able to cache Windows install files for OSDCloud would markedly reduce bandwidth load (especially in some global offices with less-than-stellar internet service) and improve download speeds.
Sounds like a great idea. Are you willing to make the code changes and submit a PR?
Hi @AptLogic, I'm just curious if you know for certain that Connected Cache actually caches ESD files? I only ask because Minecraft Education content takes a long time to install on our devices, so I suspect MCC does not cache everything you think it might.
Personally, I prefer to use more up to date ISOs from the 365 admin center. I will be looking for a method of caching these ISOs for iPXE network booting OSD purposes, and am currently planning to use Caddy alongside the MCC deployed Nginx container.
@skyblaster from the testing I have done fetching ESDs from the connected cache node in my org, it appears to be caching the ESD file (no d/l activity on the cache node on subsequent requests for the file). I would think ESDs would be natively supported for caching since that's (from my understanding) the same mechanism that Windows Update uses to retrieve patches, though I may be completely wrong here so grain of salt. The only snag I've found is that the MCC node won't report direct ESD downloads in its metrics (ie. fetching by direct HTTP file download from the cache host, not via Windows Update proper), but still seems to be caching and serving the content. I know there's some limits to what MCC will cache, to my knowledge app installs may only pull from cache if being installed via Intune or MS Store. Without knowing more about your specific setup, I can't really guess why that specific install/download is taking longer than expected. I've also found that MCC will appear to limit content download speeds per device even if no other device is trying to download from the cache.
@OSDeploy I can certainly give it a try! May take me a bit since I have a backlog of work I'm trying to grind through right now (hence the 3 week radio silence) but this is definitely on my list.
I couldn't figure out how to get WinPE to query for option 235, however I do have a working example which makes use of Oliver Kieselbach's C++ DhcpOption.exe binary. [1]
@OSDeploy Before I write up a PR, would you accept a submission based on this binary? Also, would this be something you would rather see added to the OSD or OSDCloud module? I see DOCacheHost being quite useful as a global variable. As stated earlier, I would like to also cache driver packs from our MCC servers (bound to another port so as not to conflict with the MCC service).
Hey guys, just wanted to bump this and see where we are on getting that PR in and merged. Thanks @skyblaster for doing the heavy lifting :)
I'm actually testing a proof-of-concept with OSDCloud v2 at this very moment. I didn't want to make any announcements until David officially released v2, since I'm making some assumptions as to how it is to be built, and they're not all likely to be correct.
If you want to take a peek at the code, I have this for adding the binary into the WinPE image: https://github.com/OSDeploy/osdws-gallery/compare/main...skyblaster:osdws-gallery:mcc
And then this as the OSDCloud script to validate the cache host and re-write the OS image URL: https://github.com/OSDeploy/OSDCloud/compare/main...skyblaster:OSDCloud:mcc-poc
As a first test, I only focused on the OS image. It would probably be better to simplify the discovery script and then break out the URL manipulation into the respective steps step-validate-iswindowsimageready, etc.
Testing of the above example works well in my environment.
Function step-validate-connectedcache will:
- Transparently continue if
DhcpOption.exedoes not exist in the WinPE image - Transparently continue if
DhcpOption.exe 235returns a null value - Skip over invalid caching nodes if a comma-separated string is returned. Example: ( $docachehost = "example.com,10.10.0.20" ), where example.com returns a 404 error.
- Successfully download an OS image from the caching node
Hey guys, just wanted to bump this and see where we are on getting that PR in and merged. Thanks @skyblaster for doing the heavy lifting :)
I've been in Scotland the last week, just got home a few hours ago ... I'll need to decompress before looking into this ...
@AptLogic, I've been meaning to ask. Do you use OSDCloud in network boot scenarios? If you're using USB media, then your ESD will be cached on the drive, so the bandwidth savings will be fairly minimal. For network booting, I see this mod as being very relevant.
EDIT. Also, no changes to the previously shared scripts, but I did sync the repos to the following branches for anyone wanting to test: https://github.com/skyblaster/OSDCloud/tree/mcc-poc2 https://github.com/skyblaster/osdws-gallery/tree/mcc
Hey @skyblaster, we use almost exclusively network boot, at least in the US. We have other regional IT departments that we want to move over to PXE OSDCloud, and being able to leverage a cache in some of those environments will be a big pull factor in getting them on board.