Phil Wilcock posted a blog last week with details about “non-peerable” content, pointing to Microsoft’s official documentation about what is and isn’t “peerable.” Interestingly, the Microsoft documentation is missing an entry for one specific type of content: MSI apps. These are delivered using the Enterprise Desktop App Management CSP, which historically has used BITS to download the installation files needed. We can see that during in OOBE on Windows 10, looking at the output from BITSADMIN /LIST /ALLUSERS /VERBOSE:

This shows that the content isn’t peerable, since the source location doesn’t provide the necessary BITS content information (hashes) to enable peer-to-peer sharing using BranchCache.

When doing some unrelated research on peer-to-peer behaviors on Windows 11, I had disabled the Delivery Optimization service (not supported or recommended), I noticed that the MSI download behavior changed: It’s now using Delivery Optimization. How exactly do you see that? Well, the failure is a pretty good indication:

But when looking at the machine more deeply, I can see a recorded error:

The 0x80070422 error translates to error 1058, “the service cannot be started.” Makes sense since I had disabled the Delivery Optimization service. The event log shows the same thing:

I had filed a bug against this Enterprise Desktop App Management CSP to get it to switch to Delivery Optimization several years ago, but I honestly never expected it to happen.

Most things that use Delivery Optimization for downloading content will fall back to either use BITS or a direct download, but in this case the Enterprise Desktop App Management CSP in Windows 11 doesn’t do that — the download just fails. Overall, that’s fine, you really should not disable Delivery Optimization.

But that raises the next question: Does this actually improve things? The goal overall would be to share the MSI content via Delivery Optimization’s peer-to-peer capabilities. Does that at least work now with this Windows 11 change? Sadly, no, because the content is “non-peerable” because it is downloaded from an https: URL, which Delivery Optimization does not support.

Intune could change this to use an HTTP URL (since it can still validate the content using the FileHash to make sure it hasn’t been tampered with), but it seems unlikely that this will be done since those MSIs would still be sent in “clear text” across the internet — someone could snoop the content. (This isn’t an issue with Win32 apps since they are encrypted.)

So we’re left with another type of “non-peerable” content.

While we’re talking about MSIs, it’s worth mentioning that Autopilot v2 (Autopilot device preparation) no longer has any restriction on mixing Win32 apps with MSIs. It will make sure that MSIs install prior to the installation of Win32 apps. So there is some implicit ordering here: If you have any apps that are available as single-file MSIs, you can ensure those get installed first.

Another interesting difference with MSIs: The Enterprise Desktop App Management CSP is pretty smart when it comes to downloading and installing multiple MSIs. It starts downloading all assigned MSI files in parallel, and then starts installing them as the downloads complete (similar to how ConfigMgr does things). That’s not how Win32 apps work: Intune Management Extension (IME) serializes the apps: download app 1, install app 1, download app 2, install app 2, etc. As a result, there are periods of time when no downloads are being done, which increases the overall duration. Maybe one of these days IME will do more parallelization to address this.