Deploying Large Applications using Microsoft Intune

In late July, I was asked to do a Proof-Of-Concept (POC) for one of our customers regarding Intune and deployment of large applications. Basically, they wanted to know how well Intune would work with application sizes in the 5 – 20 GB range. Obviously, this story is not going to end well, but please read on…

Increasing the default Win32 application size limit

If you have been deploying applications with Microsoft Intune for more than four minutes, you probably know that the default max size is 8 GB per application. This limit can be increased by submitting a support case from your Intune tenant. Long story short, case submitted, business impact/reason provided, and three weeks later, our tenant was upgraded to support 30 GB per application. My fastest Intune support case yet…

Confirmation email from size limit

Step #1 – Creating the Intune package

Creating a large Win32 package using the Content Prep Tool (IntuneWinAppUtil.exe) is no different from creating a small one, except for it takes a bit longer. Just make sure to use version 1.8.4.0 of the tool or later since earlier version had a bug when creating packages over 4 GB.

For this test I created an Intune package of Adobe Suite 2022. Using the IntuneWinAppUtil.exe it took about 20 minutes to create the package. It's not the fastest tool, but in all fairness, it does a decent job using a standard Zip compression, and also encrypts the package. The resulting size is only 0.5 GB larger than a 7-Zip archive of the same folder (19.9 GB vs 20.4 GB).

The Adobe Suite 2022 package.

Step #2 – Creating the Win32 App in Intune

Next step was to create the Win32 App in Intune, which also uploads the package as part of the process. And this is where my problems started. My Internet connection when doing this POC only had 20 Mbit upload, and the IntuneWin32App PowerShell module from Nickolaj Andersen (@NickolajA), that I typically use to create the packages, would timeout after 15 minutes due to the authentication token not being refreshed during the upload.

To upload the package faster, I decided on subscribing to a Windows 365 Cloud PC with 4 GB RAM, and 256 GB Disk. Subscribing to the Cloud PC only took a few minutes, but it took 5 days for Windows 365 to actually provision it. I'm assuming due to heavy load or bugs on the Windows 365 platform, because the support person that responded to my ticket had no clue whatsoever. Anyway, once I had the Cloud PC, I synced the Intune package via OneDrive to the Cloud PC, and then uploaded it from there. But even though I got about 130 Mbit upload when uploaded from the Cloud PC, the IntuneWin32App PowerShell module would still time out due to token refresh. So, I ended up uploading the Intune Package via the MEM portal, from the Cloud PC, which went fairly quick. I guess you can call the Cloud PC UaaS (Upload as a Service).

Now the good news: In the midst of all this, Mr. Jose (@schenardie) reached out to me, offering his help to create a fork of the IntuneWin32App PowerShell module that used AzCopy.exe to upload the package, including a token refresh. Happiness! With the updated module I could create the Win32 App from both the MEM portal and PowerShell. Yay!

Total Win32 App creation time of Adobe Suite 2022 from my Cloud PC was 2 hours and 4 minutes.

Note #1: You may have to test different upload caps values (–cap-mbps) in the Invoke-AzcopyBlobUpload.ps1 script.

Note #2: A good 20 minute of the above times is the machine preparing the package for upload.

Note #3: When uploading the Intune package via the MEM portal on my Cloud PC, I got about 140 mbit upload speed.

Step #3 – Deploying Adobe Suite 2022 using Intune

As if I hadn't had my fair share of problems along the way already, actually deploying the 20 GB Adobe Suite application from Intune turned out to be a royal pain. Intune have a default download timeout of 10 minutes, and unless my client has about 300 mbit dedicated download speed, there is no way a 20 GB package will download in that time.

What happens when the timeout is reached is that the download stops, and the client will continue to download later, much later. In my first attempts it took about 2 days to get the package down over a 60 mbit link. By poking the registry keys for the app, I could force it to download all 20 GB in a few hours, but it would be nice if Intune offered a setting to increase that initial download time. For the fun of it, I did submit a support case on this issue, but nothing useful have emerged yet from that.

It's also fascinating to see how DO is downloading multiple 1 MB blocks from multiple sources. Here is a ProcMon trace I was running during download:

Step #4 – Speeding up Things

While the initial download can be quite slow, the more clients that downloads the package, the faster the local sharing via DO will be. Also, you can leverage the use of a local Microsoft Connected Cache server for the Win32 apps that will improve performance. Here is the Adobe Suite 2022 package inside the MCC cache on one of our cache servers:

The cached Adobe Suite 2022 package