Introduction

In your organization, you might need at some point to centrally deploy apps, if your devices are enrolled in Intune. You may package and deploy a multitude of apps from browsers ; archive/zip managers ; business applications ; media players ; even scripts or drivers. In today's example, we are going to follow how to package and deploy Google Chrome browser.

Packaging

You have 6 important aspects you need to think of when deploying an app:

1. Sourcing the installer (.exe ; .msi ; .msp etc..)

2. Transforming it into an .intunewin file

3. Figuring out the silent install switch

4. Figuring out the uninstall string

5. Figuring out the detection method

6. Versioning?

7. Assignments

As a best practice, the recommendation would be to focus on deploying all your apps in Intune as Win32 apps. Even .msi installers can be packaged and deployed as Win32 app in Intune. Having different types of deployments can cause concurrency issues during device preparation steps.

1. Sourcing the installer (.exe ; .msi ; .msp etc..)

Let's grab the msi from an official source via a quick web search:

2. Transforming it into an .intunewin file

Then we'll gonna need an app from Microsoft that transforms anything you put in the input folder into an .intunewin file, which is like an archive containing the executable/installer, and can also include scripts, or other canary/dependency files. This .intunewin "archive" is used by Intune to distribute, deploy, then unzip and install the packaged resources on Windows Endpoints in your organization. So, going back to the tool that makes this possible IntuneWinAppUtil.exe

The tool looks like this:

We're going to need to create 2 empty folders (an "in" and an "out" folder; you may call them as you wish) and place the installer in the "in" folder:

Copy the path of your "in" folder and place it in the source folder in the IntuneWinAppUtil window at the Source folder prompt:

Hit Enter, and then you'll need to input the path to your Source file (it can be your installer, a custom script you built etc.)
Then hit Enter again and paste the out folder path:

You will be asked for a catalog file, you can input "n" then hit Enter again. At the end, your .intunewin file will be in the "out" folder:

3+4. Figuring out the silent install/uninstall switch

Now that we have our intunewin file, let's move to intune.microsoft.com, and we'll go to Apps -> All Apps -> +Add and create a new Win32 App:

Select your .intunewin package created before:

You can give it a name, description, publisher, version, Logo etc. These will be visible to users when installing and using it. And on the next page is where some magic happens:

The install and uninstall cmdlets are quintessential. If you're using an msi (as in this example), they will most likely be baked (by the app devs) in the .msi executable, which is packaged in your .intunewin file, and Intune will know how to extract that information and prefill it.

For any app you plan to deploy, you need to figure out its silent install switches. Sometimes you get lucky with them being baked into the .msi, other times, if you have to deploy an .exe app, you will have to research the developer ressources for your desired app. Sometimes they are simply /S (silent) or /qn, but it's no guarantee. Sometimes you can install the app manually then search for the regkeys it created, some have a special registry key that shows you the silent install/uninstall cmdlets.

Intune will download your package on the endpoint(s), unzip it, then execute the "Install command" in a PowerShell using the SYSTEM elevated account from an elevated PWS (hidden) window.

Here's where you can take advantage of building a custom installation PowerShell script and point the Intune Install command at it, after you have packaged it with the .exe/msi.

Next up you can define some requirements for the endpoint:

5. Figuring out the detection method

Another very important step is determining how to detect if the installation happened successfully or not at endpoint level. Again it's a step where building a custom detection script can be useful. Otherwise you can use Registry Keys, the existence of a certain file or folder, or in our case we'll take advantage of the builtin msix unique code for this version, read by intune from our .msi:

6. Versioning?

Note When doing updates/upgrades of apps that can be already present on endpoints, be very careful how you manage detection, because you can cause loop install/uninstalls. It's best in these scenarios to base your detection on something that actually changes with the update - like the version number.

Next, Next (we don't have dependencies, nor supersedence - not covered in this article, but these can help update/upgrade older/pre-existing installations).

7. Assignments

We won't go in great detail as this section can span over a whole post, but in short we have 3 assignment options:

• Required - forcefully installs the app on the endpoints
• Available - makes the app available to users in the Company Portal app. They can install/uninstall it by themselves if they want
• Uninstall - forcefully uninstalls the app from the endpoints

You can assign groups to these sections, depending on what you need. The groups can be user based or device based, but some apps work better with user groups. This can also be important if you need the app to be installed at the device prep zone during Autopilot/Enrollment Status Page, or at the User zone when preparing a device.

Be sure to check if you need to show or hide notifications for your users. Also be sure to test your app on a small subset of test devices, then pilot group before committing to a full deployment.

Review the config and hit Create. It will take a short while to upload the .intunewin package, then at the next endpoint's sync with intune, they will see that there's a new app to download+install and will proceed to do so.

If everything is correct, after some wait time, a reboot, or a sync with Intune, the targeted endpoints will start downloading the package and installing it:

Conclusion

Packaging and deploying apps can be rather tricky, but nevertheless achievable through intune with a bit of research and testing. Be sure to follow the above guide for an easy .msi deploy. Things can get a bit more complex with .exe installers as silent switches and detection methods are not that obvious anymore. Don't be afraid to reach out to the app's developer for silent install/uninstall, and detection methods/scripts/tricks.