Under the Hood, Pt. 2: Microsoft Store Apps

As I already did an "Under the Hood" post on Autopatch and I love to dig into how things are working out of view of most, I'm turning it into a series!
Part 2 looks at the recently released Microsoft Store app (new) app type, interaction with the MS Store, API's, winget, expectations, assumptions, and issues!

What is it?

The app type is, at it's most basic, MS's first stab at replacing the Microsoft Store for Business. There are now three options available for Store apps within the Intune UI: Synced Store for Business Apps, and the below choices:

The "(legacy)" type is the option we always had to specify a link a public App Store URL, just renamed to fit the new scheme.
The "(new)" type is what we're most interested in here, and following the docs shows it's fairly simple. There is, however, some significant nuance in exactly what is available, and I've already seen a large number of people show confusion, especially when it comes to the apps that are available, but we'll come back to that.

Hidden Treasures.

The first thing I did when it was made available in my tenant was to smash F12 and take a look at the network calls being made when doing certain actions within the Intune UI.
To my surprise, I was met with a new API URL: https://storeedgefd.dsx.mp.microsoft.com/v9.0/manifestSearch
Doing a search for "Microsoft" in the app search bar returned some interesting info, and a .json payload being sent to the new API via a POST request:

What initially concerned me were the request headers, specifically the Access-Control-Allow-Origin header. From previous API tinkering, this was usually a sign that the requests to that API were "locked" and only callable from the denoted origin, which in this case is the Intune portal.

Note: I'm not a dev, nor am I particularly familiar with this stuff, so I may have wildly misunderstood all the CORS stuff. I am purely going on experience.

Unphased, I decided to open up Postman and try anyway. Copying the json payload and using it in the body of a request, completely without authorisation, I was genuinely surprised with the results:

The same results were returned as from the UI! I was quite curious that the results include only basic information of each package, that being the PackageIdentifier, PackageName and Publisher, which does lead me to think that the Intune Portal UI is cheating when it shows the "Type" column and whether it's a UWP or a Win32, but again, I'll come back to that later.

Just keep digging...

With my newly-found success, I went back to DevTools and chose one of everyone's favourite apps, Company Portal as a test to find any further information. The result was another API URL: https://storeedgefd.dsx.mp.microsoft.com/v9.0/packageManifests/%PackageIdentifier%
The PackageIdentifier for the Company Portal is 9WZDNCRFJ3PZ, the same ID found in the Public Store, or if you search for it via Winget.

Back in Postman, and a GET request to our new URL provided me the following (thrown in a Gist for ease of reading, though you can just open up the URL of the request)

Company Portal JSON

GitHub Gist: instantly share code, notes, and snippets.

Gist262588213843476

This is where it immediately clicked for me, and of course it makes perfect sense to do so. The returned result looked to match the format as used in the winget package manifests in the community repo:

Of course! Why have two different instruction sets when you can structure them in the same format and just re-purpose code?!

So you found some JSON, so what?

Hey, I never said these "Under The Hood" posts would be useful! In fact, that is pretty much where my digging ceased, and to be honest, apart from being able to see the different architecture types and whether the app has the functionality to install as the User, Machine or Both (which does come into play, especially given my testing of trying to target the Company Portal to devices...), I don't think there's an awful lot you can do with the information.
I was however curious to take a look at a manifest of a Win32 app which is currently unavailable to add, such as that of Teams. Turns out the Store-delivered version of Teams runs to nearly 52500 lines of JSON when compared with the winget-delivered version, which is just 57.

Cheating UI

Remember I said about the cheating UI and that there's no response to denote if an app is UWP or Win32?
It's purely a hunch, but I think MS is keeping some sort of back-end reference for the UI to match against, because without matching the InstallerType per-app (I.e msstore = UWP and exe = Win32), I don't see how it's returning this information.

Circling Back

As it's been a particular interest of mine, I've already shared some of my feelings around this in my previous post, The troubled situation with the Store(s). I'm still of the opinion that the whole things has been tragically mis-communicated, which is a real shame, and I genuinely believe most of this could have been avoided with better communication by MS.

Some of the most frequent comments on this across multiple communities have been:

"It's missing all the winget apps!"

Yes. It is. Because this is initial release is purely to replicate the existing MSfB functionality and apps it delivers, and gives (some) time for admins to migrate.
The winget functionality has been hinted at, but even at Ignite and the Technical Take-Off there was something that was mysteriously missing from the rest of the published information on the below article:
Reduce your overall TCO with a new Microsoft Intune plan - Microsoft Community Hub

I don't want to be cynical, but part of me definitely feels like the "Automated app patching and packaging" could be automation around delivery from the Winget Community Repo. Not that that's a bad thing, and I'll withhold any further comments at least until some information about it is released.

What I will say, is that there's not been nearly enough Microsoft-delivered information about this leading up to now. This is entirely an expectation-setting exercise and could have been helped if this had been communicated 6 months ago.

"This is garbage, I can't deliver apps during ESP!"

No, you can't. This one is more interesting and very much revolves around how, out of the box, the Windows OS handles delivery of the apps using the new Store app type.
Contrary to speculation (including mine), it's not sending an instruction of winget install --ID 9WZDNCRFJ3PZ --accept-source-agreements --accept-package-agreements (which does work to deliver the Company Portal, if you're interested), and that wouldn't even work during a standard ESP due to winget (delivered as part of the App Installer package) not being registered during Autopilot.
While the request to install an app of this type is done by winget, it's a direct COM API request between the Intune Management Agent (IME) and the Microsoft Store, bypassing the user CLI availability of winget entirely.

The stance I'd normally take on this is: What does it matter if these apps come down after the user gets to the desktop? The whole point of Autopilot is to provide a great end-user experience in device onboarding, and part of that is getting them to the desktop ASAP. I always recommend as barebones as possible (I.e. pretty much just the M365 Apps). The more you add, the more chances of failure, user impact, and having to deal with that support ticket. For a user new to a business, that initial onboarding experience can be really important.

Whether that should be the responsibility of the IT function is a different question entirely... ;)
The ESP functionality is also apparently coming in a future release, so...

What's next?

I would LOVE the Winget and Intune teams to release a technical deep-dive of how all these pieces click together. The Intune app type, Winget, the Store COM API. It would help the technical among us better explain the process, requirements and expectations to customers/clients/those less technical.
Beyond that, Microsoft needs to get better at communicating. There's lots of IT admins that are well aware of the MSfB EOL date and using it in a way this doesn't provide a 1:1 implementation of, and they're going to have to adjust their processes appropriately (I've seen many people using MSfB apps to uninstall out-of-box applications, for example).

Wingotchas 2: Package Boogaloo

In all of my testing, there's been a few things I've noticed which could cause issues, but it almost entirely revolves around how businesses are controlling/blocking access to the Windows Store.

The docs are very clear about what policies (either delivered via GPO or Intune) could significantly impact or entirely break the delivery of these apps. There's also the highlighted note below:

If you would like to block installation of arbitrary applications from the Store application by the end user without blocking the Intune and Windows Package Manager store integration, set Store\Only display the private store within the Microsoft Store to Enabled.

Some policies that are almost definitely being deployed by businesses will straight-up break the attempted deployment of these apps. While the Private Store policy is a Windows 10-only feature, that policy does work on Windows 11 with the end result that the user just can't access the Store at all. They can still self-service apps added into Intune via the Company Portal.

I have, however noticed that (depending on your implementation), it is technically possible for a user to "bypass" the above Private Store restriction policy and call winget directly via Terminal. They will still only be able to install things that don't require elevation, and while this could mean a user could install relatively innocuous stuff like the Remote Desktop app...:

... It could also be used to install non-corporate apps:

A way to block this would of course be utilising AppLocker, but AppLocker (or Windows Defender Application Control) management is a huge pain point for many IT teams.

More positive news is that hopefully this behaviour could be resolved soon:

Hopefully the above was somewhat interesting. I've already got future Under The Hood's planned for the M365 Apps Admin and a re-visit of Autopatch!
Stay tuned...