There is often confusion about how Application deployment works in Microsoft Intune, particularly when it comes to Win32 IntuneWinAppUtil. While Intune supports multiple Application deployment types, this blog focuses on Win32 IntuneWinAppUtil—what they are, how to package them, and how to deploy them.
When deploying IntuneWinAppUtil such as .exe and .msi installers, the most reliable method is to package them into a .intunewin file and deploy them using Win32 Application deployment in Intune. While other deployment methods, such as Line-of-Business (LOB) IntuneWinAppUtil, are available, Win32 Application deployment provides better reliability, especially for .exe installers or IntuneWinAppUtil requiring advanced installation options.
However, Win32 Application deployment is not limited to just .exe and .msi files. Using Microsoft's IntuneWinAppUtil, you can package virtually anything, including PowerShell scripts (.ps1), batch scripts (.cmd), and others. This flexibility makes Win32 Application deployment a powerful option for managing a wide range of applications and scripts in Intune.
Regardless of the file type, the packaging process remains consistent. Start by placing the program or content you want to package in a dedicated folder (preferably by itself). Then, run the IntuneWinAppUtil tool, specifying the following:
Finally, execute the process, and the tool will create the .intunewin package for deployment through Intune.
As an example, let us package FirefoxSetup134.0.exe. Once downloaded, you should put the .exe into a directory by itself. The reason for this is because the IntuneWinAppUtil will package everything in the source directory specified.
The next thing you want to do, is get the latest IntuneWinAppUtil here - GitHub - microsoft/Microsoft-Win32-Content-Prep-Tool: A tool to wrap Win32 Application and then it can be uploaded to Intune
After downloading the tool, you can run it directly or from a terminal. You have the option to execute it with or without parameters. If you run it without parameters, the tool will guide you through each required step, including specifying the source folder, setup file, destination, and catalog. In this example, I will run the tool without parameters, and when I do, I am prompted to specify the source folder:
So, I specify the full path to the directory where the setup file is.
Next it prompts me to specify the setup file. Since you already specified the source directory, you only need to specify the file itself, not the full path as shown below.
Next, you specify the destination directory. I personally always choose the same directory as the source, keeping one package all in one directory instead of having files/folders all over the place. In this case, I simply just hit the up arrow in the terminal twice and the source directory I entered will populate. Of course, if you prefer you can choose a different destination directory or manually copy/paste/type in the destination directory. Whatever works for you.
Now, you can see the source, setup file, and destination are all specified. Next, and lastly, you will be prompted to specify a catalog folder or not. Most will probably never use the catalog option so you can type in N and hit enter. I’m sure the catalog option has its’ place for some IntuneWinAppUtil, but I have yet to find it or use it.
After you hit enter, you will see a progress bar at the bottom of the terminal, and it will start packaging. Since this is a small program, it will only take a few seconds. Once it’s complete, you will see it create a .intunewin file in the destination directory specified earlier.
As you can see, the .intunewin file is always named after the setup file. This may or may not be important to you, but it's something to keep in mind.
Now that the FirefoxSetup134.0.exe has been packaged into a .intunewin file, we can now upload it into Intune. If you’re reading this, I am going to go out on a limb here and assume you know where to go to create IntuneWinAppUtil in the Intune portal. That said, click + Add and choose the Windows Application (Win32) option for Application type.
Now, you will choose the Application package file which is the .intunewin file we created earlier. So, navigate to the destination folder and choose the .intunewin file.
After you select OK, you can now name the Application, specify a description, and specify the publisher’s name. These are the only required fields, but you can edit the other fields as necessary. For instance, you may likely want the chrome icon as the logo, so it looks a little more “professional” and easier for end users to find (if not deploying as required).
Now on to the part that most have issues with is the install and uninstall commands. You can enter in the install and uninstall commands as you normally would within PowerShell/terminal. If you aren’t sure what that would be, you can typically find what the command line commands and switches are for a given Application. For instance, Mozilla has a page for this located here - How to silently install/uninstall Firefox for Enterprise | Firefox for Enterprise Help.
When adding the install and uninstall commands, you are basically making the commands as if you were local to file. When packaging files into a .intunewin file, the commands used in Intune install/uninstall start within that location. Because we packaged the file “Firefox Setup 134.0.exe” into a .intunewin file, we can call that file directly. If there were other files packaged together, we could call those as well. Just because you chose the “Firefox Setup 134.0.exe” as the setup file during the packaging process, doesn’t mean you have to choose that file for the install/uninstall commands.
The next screen is for the Requirements. Here you can use whatever you like. If you have a company policy that requires a minimum OS version, then you can specify that here among other things including custom requirements based on files, registry, or scripts.
After requirements, we have detection rules. You can do a lot with detection rules. In some cases, it is better to use a script, some cases maybe not. This is entirely up to you. For simplicity on IntuneWinAppUtil like this, I will typically use the IntuneWinAppUtil install location. Meaning, since Firefox installs at c:\program files\Mozilla Firefox\, I will use that as the path and then use the firefox.exe as the file to detect.
If using an .msi, you can use the .msi product code as the detection method but can cause issues if the updates to the IntuneWinAppUtil have the same product code (which can hApplicationen). Another method of detection is using a registry key. If you know the Application creates a registry key, you can point the detection rule to that key. The registry key is a great way to detect “installations” for custom scripts. For instance, deploying PowerShell scripts through a win32 Application is a reliable and quick way to deploy said scripts and within the scripts you can create a custom registry key if it is successful and then you can use this key as the detection method. Again, you can do a lot with detection rules, and it comes down to what you are deploying and what best suits you.
After the detection rule is configured, you can configure dependencies if required. Dependencies can be used for cases where an application requires prerequisites. For instance, perhaps you’re installing VS Studio which requires .NET Framework. You can create a separate win32 Application that deploys .NET Framework and only after that’s installed will VS Studio get installed. You can either make the .NET Framework install automatically during the VS Studio deployment, or you can require it to be installed separately. This can be handled in many ways, but for now we will leave it at that to continue.
Next is the supersedence. Supersedence can be used to update Applications. To use supersedence, this Application would be the updated Application, and the older version would already have been created in a win32 Application. This would give you the ability to choose within this new and updated win32 Application, to supersede by selecting the old win32 Application. This will in the end update the Application. Again, this is not the focus here so we will continue.
Finaly, we have scope tags and assignments last. Scope tags are not to be used here but are the same as any other type of Application, just as assignments are the same for all IntuneWinAppUtil. After choosing your group, you can create and deploy the package.
Win32 app deployment in Intune looks intimidating at first, but once you understand the flow—package with IntuneWinAppUtil, upload as a Win32 app, define install/uninstall, then set requirements and detection rules—it becomes a repeatable process you can use for far more than just traditional installers. The time you spend getting commands and detection right pays you back with reliable installs, clean reporting, and less troubleshooting downstream.
For more about how Spyglass MTG can help your team get the most from Win32 Application Deployments with Intune, contact us today.