Installing Win32 Apps with Microsoft Intune

Installing Win32 Apps with Microsoft Intune

There have been a number of great announcements at the Microsoft Ignite conference this year, and one of the most exciting was the public mention of support for Win32 app deployment in Microsoft Intune.  Support for legacy application delivery has been one of the most common roadblocks preventing enterprise customers from adopting Modern Management for Windows 10, so closing this gap is a huge win for those wanting to provide applications to their Intune-managed systems.

So what does this capability look like?  As a long time SCCM admin I can tell you it looks…comfortably familiar! 🙂

Before we can pull an application into Intune, we need to “package” the application for delivery.  The application is actually delivered using the Intune Management Extension (aka “sidecar”), so Microsoft has provided an Intune Win32 App Packaging Tool to convert the application to a compatible format.  The IntuneWinAppUtil.exe tool can be run using command line arguments, or simply executed so it prompts for the necessary information.  The three basic things needed are the source folder for the application, the name of the setup executable, and the output folder for the new file.  As with SCCM, the source location will include any files and subfolders, so we are no longer limited to single-file installation sources (YAY!). Here is what the experience looks like when the executable is called and prompts for the necessary arguments:

image

As we can see, the output is a .intunewin file ready for import into Intune. Now that we have the package ready for intake, let’s fire up the Azure portal and create an app!

In the Intune blade of the Azure portal, when we add a new app under the Client Apps section we’ll see a new “Windows app (Win32)” option:

image

image

We can then browse to the .intunewin app package file we created and import it:

image

(As a side note, notice that as of this writing each of the subsequent configuration areas is greyed out until the previous is configured.)

Under the App information section, we need to provide a friendly name, description and publisher for the app. Optionally, we can configure additional information for the app:

image

On the Program screen, we get do define the install and uninstall commands for the application:

image

On the Requirements screen, we can specify environmental requirements that are evaluated at runtime to determine whether the app can install:

image

This is where we ConfigMgr admins start to get excited!  The Detection rules screen provides us with a very familiar bit of functionality from the SCCM app model. At present, we can use one of two rules formats: a manually configured detection rule, or a custom detection script:

image

Normally, we’ll do a manual detection rule, which gives us the usual familiar options: File, Registry, or MSI:

image

I know what you’re asking yourself, and the answer is: Yes, if you specify an MSI, it will automatically import the MSI Product Code as the detection rule!  In this case though, we’ll just use a standard path to the main executable:

image

Again, note that it does recognize standard environment variables the same as with the ConfigMgr app model.  Our last option is again a familiar one: the ability to specify actions based on return codes.  The usual suspects are already included by default:

image

Now that we have everything imported and configured, we can click Add and wait while the portal uploads and finalizes the app. Once completed, the application is available to be assigned and deployed like any other:

image

While it’s not quite as straightforward as we’re used to seeing in SCCM, we can also do a little log checking as well via the  C:\ProgramData\Microsoft\IntuneManagementExtension\logs folder:

imageimage

This is a huge advancement for the Modern Management scenario to bridge the gap for application deployment. No doubt the advancements with MSIX packaging and other upcoming Store functionality will facilitate an eventual shift away from these legacy app types, but in the meantime we have more tools at our disposal to get our end users the apps they need to do their work!

Stay tuned for more info as this feature goes live!

Leave a Reply

Your email address will not be published. Required fields are marked *