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…
Long story short: While you can request support for larger than 8 GB applications in Microsoft Intune, the platform is not very good at handling apps larger than 2-3 GB in general, and sometimes not even that, depending on your Internet connection, Delivery Optimization (DO) settings, and availability of cache servers. Read on for more info and workarounds….
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…
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 188.8.131.52 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).
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:
Real World Note: MCC won't cache Intune content like Win32 apps until it's been requested at least three times, so don't be surprised if it does not start caching immediately 🙂
Here is a post on how to setup a Microsoft Connected Cache server and monitor the results:
Setup Microsoft Connected Cache (MCC) for Windows Autopilot / Win32 App Deployments
Such a great post. I will be using some of the tricks here, as I have begun to setup autopilot this week.
Nice post! I also noticed about the blocks downloading too. I have noticed small apps can take 15 mins to 1 hour for net new deployments. For larger apps, I have seen up to 24 hours. I’m guessing it take a long time for large packages to replicate on the backend. MEM seems fine for some apps but maybe not all apps.