Large individual files and the Intune Win32 Content Prep Tool

Asher Jebbink
4 min readFeb 28, 2022

Update 2022–12–08: Microsoft fixed the Win32 Content Prep tool so that this isn’t an issue anymore. Version 1.8.4 is the first version with the fix.

At the time of writing, the Intune Win32 Content Prep Tool has a known overall package size limit of 8GB. I have found the tool also has an [undocumented?] limit on the size of an individual file that it can process. This size is at least 2.5GB.

If you try and prepare a package that contains a large file you will receive the following error:

Intune Win32 Content Prep Tool — ERROR System.IO.IOException: Stream was too long.

Solutions online mention using an Azure Storage Blob to host the files instead and have the installation script perform the download (in this scenario Intune only hosts/serves the install script). This wasn’t suitable for my scenario so I had to come up with a different solution.

Split and Re-Join

The solution I ended up going with was splitting large files before packaging for Intune and then re-joining them as part of the installation. I extended the scripts to be generic so they could be utilised for future package with the same issue and these are shared below:

Splitting

This is performed once by the administrator creating the Intune package. The script is run on their device prior to using the Intune Win32 Content Prep tool.

The split script accepts 3 parameters:

  1. SourceFolder (required) — the full path to the folder that the script will search through for large files. The script will search through all child folders.
  2. MaximumFileSizeInBytes (optional) — this maximum size that a single file is allowed to be. This is the value used to determine whether a file needs to be split into smaller chunks or not. If you do not provide a value the default of 250MB is used.
  3. DeleteSourceFileAfterSplitting (optional) — By default this is set to “false”. After a file is split into smaller chunks, specify whether the script will delete the original (large) file, or not. You’ll need to remove the large file from your folder (either manually or via this switch) before trying to package the folder using the Intune Win32 Content Prep tool (otherwise the tool will continue to fail on the large file again). Also, there’s no point in providing the same file twice.

Example folder setup before splitting:

2 large files, one is in a subfolder of the parent folder. 2 small files, too, to show they don’t get split up

Script execution:

Splitting into 1GB chunks and deleting the source files after splitting

The resulting file structure (new “_split” folders at each level where a split occurred):

A new “_spit” folder is created at the same level a large file was split. The source files are also gone. The small files remain untouched.

Inside one of the “_split” folders:

The original name of the file is used when splitting. This is to ensure the file keeps the same name when it is re-joined later. Split files use the following naming convention:
<original file name>__<incremental sequence number>.split
The incremental sequence numbering starts at 1.

Re-Joining

Re-joining is completed on the client side as part of the application deployment/installation. Each client has to perform the re-join themselves once the application content has been downloaded via Intune.

The re-join script accepts 2 parameters:

  1. SourceFolder (optional) — the full path of the folder to search for split files in. If you do not provide a value then the folder that the script is stored in is used. This is useful later on when you are calling this script from an Intune deployment: the script as well as the split files will already be in the same directory, so this parameter doesn’t need to be specified
  2. DeleteSplitFilesAfterJoining (optional) — By default this is set to “false”. After a file is re-joined into its original, large file, should the script delete the smaller split files or not.

Script execution:

Re-joining the chunks into the original files

Resulting folder structure (note: it’s exactly the same as when we started, before splitting and joining):

The folder and file structure is now exactly the same as before we started

The re-join PowerShell script obviously needs to be included in your Intune Application deployment package so that the client device can re-join the files at install time. You must also tell your application installation script to run the re-join script before performing any work with the files. The easiest way to accomplish this is to include the Rejoin-FromIntune.ps1 file in the root of your packaged folder and call it via . .\Rejoin-FromIntune.ps1

--

--