Packaging Pitfalls, Part 10: How to Decode IntuneWin Packages

Creating .intunewin packages for Microsoft Intune is usually a straightforward process. You prepare your source, wrap it, upload it and expect everything to work.

But in reality, even well-prepared packages can fail once deployed. Installations may not start, detection rules may not trigger, or the application behaves differently than expected without any clear explanation.

At this point, troubleshooting becomes difficult because you no longer see what’s actually inside the package.

What’s the challenge

The .intunewin format is not just a simple archive. When the package is created, all source files are compressed and encrypted together with metadata, which makes it efficient for delivery but hard to inspect.

As a result, you can’t open it like a regular archive, you can’t validate the content after packaging, and you’re debugging without visibility. In many cases, you’re working with assumptions instead of facts.

This becomes a real problem when something goes wrong. Required files may be missing, installation or uninstall commands may contain errors, scripts may reference incorrect paths, or detection logic may not match the actual installation result. Another common case is when changes are made after packaging, but the package itself is not rebuilt.

Without access to the actual package content, these issues are difficult to identify and confirm.

How we approach it

Instead of rebuilding the package immediately, we first make it visible. When something doesn’t behave as expected, we decode the .intunewin package using IntuneWinAppUtilDecoder.exe.

Use the following command:

IntuneWinAppUtilDecoder.exe <FullPathToIntunewinFile> [/s | /silent]

This allows us to extract the original source files, review the full folder structure, verify scripts and binaries, and confirm what is actually delivered to Intune.

Once the package is decoded, identifying the issue becomes much faster. Typical findings include missing or outdated files, incorrect script references, wrong execution parameters, or inconsistencies between expected and actual content.

Instead of starting over, you fix the exact problem.

Rebuilding the package

After reviewing and fixing the content, the next step is to rebuild the .intunewin package.

For this, we use the same tool in reverse to create a new package with the corrected files.

Working this way helps you avoid unnecessary rework and speeds up troubleshooting.

Instead of rebuilding packages blindly, you:

• understand what is actually inside the package
• identify issues faster
• fix only what is broken
• keep control over the final result

Conclusion

Working with .intunewin packages requires more than just wrapping and uploading. When something breaks, having visibility into the package content is key to resolving issues efficiently.

If you need support with Intune packaging or patch management, the Apptimized team is always here to help. Just reach out to us.