The troubled situation with the Store(s)

Today I'll be diving into the complexities and frustrations of App Deployments, Stores and Package Managers off the back of a genuine client discussion about moving into cloud-native device management.

Before I explain how the discussion went, let's high-level the current state of the various "storefronts":

• Consumer Microsoft Store - Used to be garbage and required app vendors to create MSIX versions of apps, but also had a pretty serious issue with unofficial or even potentially malicious apps being available. Has now been entirely rewritten and now supports multiple frameworks so things like Discord, VLC and Adobe Acrobat can be seamlessly installed and updated direct through the store.
• Microsoft Store for Business (MSfB) - Soon to be decommissioned, and replaced with winget integration into MEM. Still needs to be configured as it's currently the only* way of deploying the Company Portal app to enrolled devices. Apps are delivered as MSIX.
• Company Portal - Shows installed/available apps delivered by MEM for user self-service. If using MECM Tenant Attach, can show both MEM and MECM-delivered apps. MEM apps can be delivered in multiple ways, but the recommendation is wrapping whatever you need into a Win32 app, bundled as .intunewin files.
• Software Center - If using MECM, apps are visible here, but from version 2006 and using Tenant Attach, can also be configured to show in the Company Portal. Can display MSfB apps, but will not display apps available in MEM. Apps can consist of pretty much anything you want, and delivery method will be dependent on what you're deploying.
• Windows Package Manager (winget) - A tool I couldn't be more excited about if I tried. Upcoming integration with MEM will make deploying core apps trivial for admins. Also supports private repos so you could self-host your internal LOB apps and use the public repo for everything else, or use only a source-controlled internal repo for everything.

That's a lot to take in, but on top of that, we then have the current situation with Operating Systems:

• Windows 10 - Has the Microsoft Store in-built, still supports the concept of a "Private Store" which will display apps available via the MSfB in a custom tab on the left.
• Windows 11 - Has the Microsoft Store in-built, does not support (or understand the concept of) the MSfB Private Store.

And finally:

• Almost all "in-box" (i.e. core OS pre-installed) Windows 10/11 apps, from Calculator, to Notepad and the Clock, utilise the Microsoft Store to update them, so if you've ever run "debloat" scripts as part of your build process and removed the Store (which I remember being a hot thing a number of years ago), are pushing some sketchy registry keys to block it/lock it down; You're going to have a bad time and have a massive number of core OS apps that will not, and possibly can not update.

* May not be entirely true and can be done using winget:
winget install --id 9WZDNCRFJ3PZ --accept-package-agreements --accept-source-agreements

Explanations:-

So, given the above background, how do you think trying to explain all of that to a client went? It's an absolute minefield of tangential footnotes and ends up sounding more like a conspiracy theorist's board of pins and red string than it does a cohesive technology offering!

Trying to give even a high-level overview of

"so you want to achieve business goal z, and to achieve that we need to use technology v, which is going to disappear soon, and technology x, but we need to be mindful that technology y is coming soon which will be able to achieve business goal z in an easier fashion, but for now we have to use just technology w and technology x..."

You get the gist, and as a consultant who wants to not just deal with the tactical now, but prepare a customer for the strategic future, it's incredibly frustrating, for both me and the client.

The wide world of updates:-

Getting an app to install initially is one thing, but keeping that app updated is a potentially time-consuming task, especially if you've got a large number of apps across your business.

Creating custom automation for the creation and publishing of apps and updates in Intune isn't new, and there's a huge amount of resources available across the internet, as well as templates, scripts, and PowerShell WPF GUI apps people have created to achieve

There's also a lot of third-party options out there to automate the process, like PatchMyPC, Ivanti, ManageEngine, Qualys and Tanium, or even open-source options like Chocolatey and RuckZuck, but none of these are silver bullets, either requiring additional cost in either licensing, engineering time to ensure updates are packaged and successfully deployed to endpoints, or lack reporting features vital for an Enterprise solution.

Wingotchas:-

Part of the main issue right now is, without somewhat hacky workarounds (shout out to the smart people like Olav Birkeland and Chrissy Rothgeb who set the foundations (Can't run winget as a admin · Issue #637 · microsoft/winget-cli), and the likes of Romanitho's Winget-AutoUpdate), accessing winget from a system context isn't an easy task.
That said, change is coming, such as the latest preview (Windows Package Manager 1.4.2161-preview · microsoft/winget-cli) bringing in PowerShell control over winget, but even then it's far from perfect, and still has issues around user/system context for both using the winget-cli, as well as it being a complete crapshoot to if the package supports user or machine install methods.

All of this needs to get better over a relatively short time frame. The MSfB being killed in Q1 '23 and a public preview version of it's replacement only becoming available in (likely late) Q4 '22 doesn't leave a lot of headroom for admins to pivot their approach, and there's an understandable amount of concern across enterprise admins that I don't believe Microsoft has actually tried to properly address.

Re-Writes ahoy:-

As I mention above, I couldn't be more excited for winget integration into Intune and have been following the situation closely for some time. Unfortunately for "reasons", it's been rather hideously delayed and (public) information from Microsoft has been sparse (Update to Endpoint Manager integration with the Microsoft Store on Windows - Microsoft Tech Community).
Reading somewhat between the lines, I genuinely don't think they expected it to be as difficult as it has been. They've completely re-written the in-box Microsoft Store, and had to do a bunch more work so it can even communicate with the way winget works:

Private repos, you say?!:-

That bit up there where I said about hosting your own private winget repo? Yeah, unfortunately right now, even that is incredibly convoluted:

GitHub - microsoft/winget-cli-restsource: This project aims to provide a reference implementation for creating a REST based package source for the winget client.

This project aims to provide a reference implementation for creating a REST based package source for the winget client. - GitHub - microsoft/winget-cli-restsource: This project aims to provide a re...

GitHubmicrosoft

It's also potentially really costly, relying entirely on Azure with Function Apps, Storage, KeyVaults, and CosmosDB. Microsoft need to make this so much more accessible, both in terms of initial configuration (they could publish something pre-built into the Azure Marketplace, or make Bicep templates available), as well as choice on hosting, such as if you wanted to use AWS for storage, or SQL/MongoDB as your database, OR even internally host across existing infrastructure and secured via AAD App Proxy!?

While there is the possibility of third-parties (currently only winget.pro have gone to market) who could take the pain out of it, from a commercial standpoint it's... not great, and you're back to square one with paying for additional products.

Then the flip side are sites like winstall.app which would make the user experience of getting a package of apps you might need or find useful incredibly easy, but translating that into an automatable experience an administrator can publish and a user can access just isn't there yet.

So, what are my options?:-

Right now, choices are either:

• Spend the time required to try and get something hacky working using Winget.
• Spend money on a third-party product.
• Continue to use the MSfB with the knowledge it's soon going to die a death.

In my opinion, this shouldn't have to fall to additional third-party apps, and there should be something that's in-built, secure, easily configurable, easily manageable, and provides the rich data necessary to provide confidence your apps are up to date. That's why I'm really, really, looking forward to the MEM/winget integration, and have high hopes.

With that hope, and with Ignite '22 only ~10 days away, hopefully we'll get some exciting new info...