Working in end-user computing, one of the things I consider constantly is the extent to which you need additional products to do the job efficiently. There’s always a trade-off; between the additional cost on the one hand, and the increased functionality or ease of use on the other. Sometimes functionality is absorbed into the core Microsoft product set, and sometimes it remains outside.

Last year, Microsoft introduced the Enterprise App Management (EAM) feature for Intune. This extends app deployment for Windows with a catalog of pre-packaged apps. Up to this point, even the smallest and simplest app needed to be wrapped in a custom intunewin file and configured with deployment parameters. With EAM, you just select an app and assign it.

This article looks at how far the EAM feature goes in meeting enterprise app deployment requirements. Does it replace third-party solutions, or even your app packaging engineers? Let’s take a look.

Enterprise App Management

EAM is a premium add-on to Intune. It provides a catalog with pre-packaged configurations, ready to deploy an app simply by selecting it. It does many of the things an engineer would otherwise need to do:

• Fetch a current version of the media from the vendor
• Apply a command line to install and uninstall the app silently
• Decide on the context: system or user
• Handle return codes (e.g. soft reboot)
• Create a detection rule, to determine if the installation was successful, or if the app is already installed.

Common and standard apps

I would guess there are at least 8 to10 apps in any environment where a standard configuration is enough:

• Browsers, like Chrome and Firefox
• Videoconference clients, like Zoom and Webex
• Virtual desktop clients, like Citrix, VMware or AWS
• The Microsoft Visual C++ Redistributable stack.

There is also often a tail of apps that are either free or enterprise-licensed, like 7-Zip, Notepad++ and Visual Studio Code.

Customisation in EAM

You can apply your own customisations to catalog apps. In this case the catalog at least gives you a start. Most obviously, you can edit the install command. You can also, of course, create a dependency or a custom requirement (to test whether to install or not).

Example

A good example of this is the Citrix Workspace app. Citrix XenServer and NetScaler create a large and complex technical environment, and the Workspace app is the means of access to it. A Citrix user might have: a) different identities, b) different environments to connect to, and c) different functional requirements, like copy/paste or file transfer.

The Intune EAM catalog app gives this command install:

"CitrixWorkspaceApp24.9.10.28.exe" /silent /noreboot /AutoUpdateCheck=disabled

It also gives the uninstall command, to save figuring it out:

"%ProgramFiles(X86)%\Citrix\Citrix Workspace 2409\bootstrapperhelper.exe" /uninstall /cleanup /silent

That performs a basic install and uninstall, obviously. But what is this client going to connect to, and how? For that, you need to understand the whole client configuration in the Citrix Workspace App command-line parameters; which is what a packaging engineer does. So you might, instead, have an install command of:

"CitrixWorkspaceApp24.9.10.28.exe" /silent /noreboot /AutoUpdateCheck=auto /includeSSON

You might also appreciate that the Store the Workspace app connects to can be configured in policy, instead of the installation, which enables you to change it without re-installing. So there is an architecture behind the deployment that needs to be developed and understood before you can deploy the app, even with the EAM catalog.

Limitations

Although you can edit the catalog app, at present you cannot use an MST (transform file), or a script with a catalog app, because there is no facility to upload additional files. However, Microsoft told me in January this year that: “We have a solution in the pipeline for this today. Not much more to say about it for now.” So it looks as though this will be possible in future.

My point in this trivial example is that, even with a catalog app and a standard configuration, you may be able to achieve what you want for a subset of your apps.

Beyond the Catalog

These are fairly simple app deployments. There are two cases where the catalog cannot help you:

1. Where you need more extensive customisation
2. Where the app is not in the catalog.

Extensive customisation

Once beyond the collection of simple apps, app deployment expands into a world of great complexity. There have been a few like this in every migration programme I have worked on. Sometimes these are legacy apps. Sometimes they are not legacy, but complex nevertheless.

The open source PSAppDeployToolkit (PSADT) covers several of the more common customisations. Essentially, this adds wrap-around functions to the execution of the command line:

• Pre or post install scripts
• Copy or delete files
• Modify the registry
• Generate verbose logs

You could write these actions into your own script, but it would get tedious after a while, and you would probably write common functions, just like PSADT.

Then there are installations that need to be interactive. Suppose the app is an update or upgrade, and needs to close the current app? Or suppose it needs to close all Office apps while it installs? PSADT uses an interactive dialogue to do this, including to pause or defer the installation if now is not a convenient time.

Normally, in Intune, this dialog would not be seen because there is no interaction between the system context and the user session. The installation would just time out, waiting for user input. But the ServiceUI.exe utility from the Microsoft Deployment Toolkit (MDT) provides this capability. So PSADT creates a dialogue to prompt the user for input; and ServiceUI surfaces the dialog to the session of the logged on user.

If you needed any of these options, you would wrap the command line in the PSADT template, then package it as an intunewin file and upload it. The install command becomes the command to run the PSADT package, instead of the app command line. PSADT will exit with a return code that Intune will interpret as a result.

In this model, PSADT controls the app install command, and Intune controls the PSADT execution.

The Intune Enterprise App Management feature is not going to be able to do this without a very large enhancement. I have no idea whether Microsoft has this in mind, or is content to leave it as a catalog of fairly simple apps with fairly simple command line installs.

Not in the catalog

Inevitably, there will also be legacy apps or uncommon apps that are not in the EAM catalog. You can see that the Microsoft catalog currently contains mostly free apps or free clients to larger paid-for systems. They say they will add more, and I am sure they will. But, in the meantime, you still need someone to package them. Some apps are unlikely ever to be in a catalog. They may be proprietary, or have a very specialised customer base, or have customisations that are unique to the organisation, or just be very old.

The future of app deployment

So now I go back to my basic question: does it replace third-party solutions, or even your app packaging engineers?

The beginning of app deployment

Right from the beginning, app deployment in Windows had command lines for unattended install. These existed in InstallShield packages, in Windows Installer MSIs and other installers like NSIS (Nullsoft), Inno and WiX Toolset. As a consequence, there was, and is, an ecosystem of open and closed libraries of install commands. As a packager you have three options:

1. Read the vendor documentation
2. Deduce the commands from the installer type, or from the /? help
3. Use a search engine or even AI to find the commands.

Catalogs

It is a small step from there to provide a catalog of pre-packaged apps with standard commands. Altiris did this many years ago for common apps like Adobe Reader, Flash, Java Runtime. These were especially useful in the days before automatic updates, because you really did need to keep updating Flash and Java runtime every time a vulnerability was discovered. Now many vendors offer pre-packaged apps as part of an endpoint management solution. It is really quite easy to offer an app with a standard command line install and uninstall.

But, as you do this, you run into exactly the problems I described above: more complex customisations, and apps not in the catalog.

Two vendors now offer PSADT as part of their app catalog packages: PatchMyPC and Apptimized. That means they can provide an extended range of customisations. PatchMyPC have taken stewardship of PSADT, and played a role in the major upgrade to v4.0 of the toolkit. Both companies offer a large catalog of pre-packaged apps, and a packaging service for custom packages.

It is not my aim to compare Intune Enterprise App Management in detail with other products and vendors like PatchMyPC and Apptimized. I just want to provide some context. In summary, there is a scale of complexity:

1. Common apps with simple command line installs
2. More complex but still standard customisations, for example with PSADT
3. Complex customisations, and legacy or uncommon apps.

Intune Enterprise App Management currently hits Level 1. This gives a rough feature parity with other endpoint management solutions.

PSADT provides the wrapper for a standard set of more complex customisations at Level 2. But you still need to be a fairly experienced packager to use it effectively. Anyone can wrap a command line in a nice PSADT dialogue. The skill is to know what needs to be customised and how best to do it; registry, policy, file, script? PatchMyPC and Apptimized have products that do this as a service. Either they have the package already prepared, or can create it as a custom app.

However, in any large organisation, there will still be a requirement for more complex customisations. There will also be legacy or uncommon apps. You could just hand all the material over to a packaging factory and tell them what you need. But a) finding out what you need is most of the challenge, and b) then you are using a specialist, just not employing them.

So Enterprise App Management is a great addition to Intune. It will save time with the simpler and more common apps. The apps in the catalog can still be customised a little, and there will probably be more customisation in time. But it does not have the range of customisation options available in PSADT, or through services like PatchMyPC and Apptimized. Even then, you will probably need a specialist application packager for a few of the most difficult apps.