Under the Hood, Pt. 4: Enterprise App Management

Under the Hood, Pt. 4: Enterprise App Management

The next part of my "Under the Hood" series is looking at the brand new Enterprise App Management feature as part of the Intune Suite!


Overview

One thing that everyone hates managing is apps. It's an almost universal feeling and has been for as long as I can remember. Cue the new Enterprise App Management (EAM) feature, available separately or as part of the Intune Suite.

If you're not familiar with the feature, go check out the Intune Technical Takeoff with Danny (@SCCMAvenger) and Joe (@LURIE_MSFT) below:


Into the API

I was almost excited about dealing with the Graph API and not something entirely undocumented again. Then I came to find out that (somewhat unsurprisingly), this endpoint has no current API docs. So let's do some digging!

⚠️
Information below can be easily obtained using Edge Dev Tools and something to do API calls (Graph Explorer/Postman), however it is meant for educational purposes only.
You can break things by doing stupid stuff, so it's at your own risk.

Understandably, the below also only works if you have a valid EAM license.

Out the gate, hitting the "Search the Enterprise App Catalog" text hits a new and exciting endpoint:

https://graph.microsoft.com/beta/deviceAppManagement/mobileAppCatalogPackages

/deviceAppManagement/mobileAppCatalogPackages results

Interestingly, but something I'm seeing more of in the portal is that because lots more information sits on that endpoint (we'll dig into that in a bit), the UI uses a filter to only show certain things:

$apply=groupby((productId,productName,publisher))&$top=10000&$orderBy=productName%20asc

Probably a little optimistic to show the top 10k hits given that as of writing this there's exactly 100 results, but we'll give the team the some breathing room for now.
ProductId isn't shown in the corresponding UI screen, but in the same way that everything else is just a GUID if you take a closer look, the same goes for EAM.

Let's remove the filter and take a closer look at the JSON response for a single example app, trusty old 7-Zip:

{
   "@odata.type": "#microsoft.graph.win32MobileAppCatalogPackage",
   "id": "4c00459d-7c03-07dd-4487-e1f3144109dd",
   "productId": "3a6307ef-6991-faf1-01e1-35e1557287aa",
   "productName": "7-Zip",
   "publisher": "Igor Pavlov",
   "versionName": "23.01",
   "icon": null,
   "branchId": "3da9c2f0-94e7-90b1-01e3-35e155728974",
   "branchName": "7-Zip (x64)",
   "architectures": [
         "x64"
       ],
   "applicableArchitectures": "x64",
   "locales": [
        "mul"
       ],
   "packageAutoUpdateCapable": false
}

A few things stand out to me at first glace, firstly multiple, different ID's (id, productId and branchId), a nice null icon, some architecture definition, and "packageAutoUpdateCapable". I'm assuming the last one is mostly to drive the following message if set to true:

The EAM documentation on self-updating apps is somewhat interesting, suggesting that an auto-updating app deployed via EAM will continue to be marked as "Installed" by Intune providing it's at or above the minimum version, presumably based on the versionName field when you add the app for the first time.


Branches

Some applications have multiple branches. These currently seem to be to do one of two things. Either display different languages of the same app version:

Language Branches

Or to show different versions of the same app:

Version Branches

Regardless of the visual, the apps share the same productId, but have separate id's and branchId's. The above Blender example can be emulated in Graph Explorer by the following:

https://graph.microsoft.com/beta/deviceAppManagement/mobileAppCatalogPackages?$filter=productId eq '8b2671a4-9816-cf68-20c4-35e15596c94e'&$orderby=versionName asc

I'm not sure why some other things in the catalog (Android Studio, Python, Snagit) aren't similarly grouped by one entry but broken down by branch. In my opinion it'd make the feature less cluttered and I worry that when the available apps list grows significantly in the future it may be difficult to navigate or find what you need, but I'm sure there's some forward-moving technical reason for this choice.


Add the App Already!

While EAM has it's own "Enterprise App Catalog app" app type in Intune, they are fundamentally just pre-configured Win32 apps. And here's where things start to get interesting. Following the UI, but before you hit the Select button on the Configuration tab, there's another API call, this time to:

https://graph.microsoft.com/beta/deviceAppManagement/mobileApps/convertMobileAppCatalogPackageToMobileApp

Convert Mobile App Catalog Package to Mobile App... Interesting.
The entire purpose seems to be to take all of this:

And be able to pre-populate this...

...the split-second you hit select. Makes the experience feel nice and snappy, that's for sure!

So let's assume we don't want/need to make any changes to the app since Microsoft kindly fill everything out for us and go all the way through and hit Add App on the Review + create screen, what happens?

The magic in the background goes ahead and creates something very similar to a standard Win32 app like you would yourself in the UI, but instead of uploading our own .intunewin file to associate with the app entry, after a little wait we get a copy of an already existing app file that sits somewhere in the Intune ether. Neat!

The way they seem to be referenced in the subsequent app when viewed via Graph is via the following JSON values:

{
    "mobileAppCatalogPackageId": "4c00459d-7c03-07dd-4487-e1f3144109dd",
    "referencedCatalogPackage": {
        "@odata.type": "#microsoft.graph.win32MobileAppCatalogPackage",
        "id": "4c00459d-7c03-07dd-4487-e1f3144109dd",
        "productId": "3a6307ef-6991-faf1-01e1-35e1557287aa",
        "productName": "7-Zip",
        "publisher": "Igor Pavlov",
        "versionName": "23.01",
        "icon": null,
        "branchId": "3da9c2f0-94e7-90b1-01e3-35e155728974",
        "branchName": "7-Zip (x64)",
        "architectures": [
          "x64"
        ],
        "applicableArchitectures": "x64",
        "locales": [
          "mul"
        ],
        "packageAutoUpdateCapable": false
        }
}

The second value is somewhat tricksy and doesn't visibly show up if you go have a look via Graph Explorer, instead having to specifically expand the odata type:

?$expand=microsoft.graph.win32CatalogApp/referencedCatalogPackage

And that's really all there is to the API, at least as far as I could tell!


Closing Thoughts

Enterprise App Management has come a long way and obviously gone through various iterations since it was first silently "announced" with a tiny screenshot back in October 2022 under the name the name "Automated app patching and packaging", but what it definitely isn't is a rebadged Winget Community Repo solution I cynically hypothesised just over a year ago.

The feature is a promising v1 and depending on your app estate could pretty quickly save time and provide value. While there are some... questionable... app choices on this initial list (I'm looking at you Free Countdown Timer and CCleaner), I hope to see the list of available apps grow quickly. There's also additional functionality in the "Updates for Windows Catalog Apps" that's been shown off coming soon which will add an additional layer and further value to the feature.

My suggestion would be to put some time aside to either spin up a 90 day trial of the feature individually (https://aka.ms/EAMPurchase) or via the whole Intune Suite (https://aka.ms/IntuneSuitePurchase) and see how it can save you time messing about with deploying apps.

James Robinson

James Robinson

With 20 years of experience, James is a Principal Consultant specialising in Modern Workplace and End User Compute technologies, with a focus on Modern Management and Cloud-Native endpoints.
Brighton(ish), United Kingdom