New Microsoft Store integrated in Intune

In the week of November 28, 2022, Microsoft released the new Microsoft Store which is implemented in Intune using the Windows Packager Manager. This new store will replace the Microsoft Store for Business (MSfB), which will be deprecated in the first quarter of 2023.

The new store relies on the Windows package manager framework, the backend of this framework is connected to Microsoft Intune app service, which allows us to directly search the store for available applications. We don’t have to setup a connection with the store, like we needed to do with the MSfB. And we don’t have to sync apps between the store and Intune which we purchased; we search directly in the store itself and the applications are not stored in our Intune tenant.

Windows Package Manager is an open set of APIs that can integrate with any unified endpoint management solution, including Intune. Organizations can also choose to integrate directly with these APIs to build their own solution to meet their needs and for unmanaged devices.
The WinGet command-line tool is the front end, or client interface, of the Windows Package Manager service, which itself is a comprehensive solution consisting of a command-line tool and a set of additional services for installing and managing apps on Windows 10.

Source: http://aka.ms/StoreTransition

Software available via this framework can be made available not only by Microsoft but also by other Independent Software Vendors (ISV), like Adobe, Citrix, or SAP. Besides that, not only UWP apps can be made available, like in the old store, but there is also support for WIN32 apps (.exe and .msi files). But currently support for win32 apps is in preview.

The apps in this new store are maintained by the ISV, not only the UWP apps but also the WIN32 apps. While WinGet has the capability to update the (win32) apps automatically, this is not a default store functionality. This functionality might be added in the future. UWP Store apps are kept up to date, for this the store functionality is used.

WinGet

This Windows Package Manager WinGet command-line tool is bundled with Windows 11 and modern versions of Windows 10 by default as the App Installer. It’s available on the Windows device as part of the App Installer app (a store App). But if you want to use WinGet immediately after the first sign-in on a newly installed Windows device, you might see that WinGet is not available with a message like “The term ”WinGet’ is not recognized….”. The app is present, but not registered yet on Windows 11 and on Windows 10, WinGet is not part of the App Installer thus also first needs an update (which should run automatically as long as the store is not disabled/ blocked). There is about a 15-minute delay of the store starting to update and register apps. After this, we are able to use WinGet from the command line. If the app is not available, because you’re running an older Windows 10 version, follow this documentation.
But the Intune Management Extension (IME) knows how to use WPM/WinGet functionality without WinGet installed. So, IME should be able to install apps from the new store even as the registration hasn’t been completed yet.

With WinGet available on the device, we can directly search all the sources available on which software is made available.

When we start a command-line tool like PowerShell, we can search the store directly using WinGet. We can search the Microsoft Store directly by specifying the source in which we want to search. As we directly search in the same repository as we do when using Intune to search for an application, we will see the same applications available.

Like with the below example we search for Adobe in the source msstore (Microsoft store):
winget search Adobe –source msstore

Every application we find in the store repo has an Application Identifier (ID), which we will also see in the Intune portal when we select an app. But what you might have noticed, some of the application IDs start with XP.
This means, the application is of an exe type.

With the command WinGet show appID, we can get more information on the particular application, which in this case indeed shows Adobe Acrobat Reader DC is an exe type application.

If we do the same for the Company Portal, we see it’s a store (UWP) app.

And with WinGet we can install applications available in the repositories. But still, this fails when the end-user doesn’t have the needed permissions to install the application, like when installing this win32 application without the needed permissions.

And therefore, we make applications available via Intune for our end-user, so they can install these kinds of applications.

Note; if you only allow the private store on your corporate Windows devices, WinGet still allows the end-user to install store apps since Winget is available on these devices. Have a look at this blog post, to read more on that.

The new store in the Microsoft Intune portal

Now finally let’s also have a look on how this new store is integrated with Microsoft Intune!

As written before, we don’t have to setup a connection between the store and Intune, we can go right to the Apps tab in the Intune portal.

If we choose to add a new app, we have Microsoft Store app (new) and Microsoft Store app (legacy), where of course the one with new in it, is the new store and the other on is the Microsoft Store for Business.

If we select the new store app, we see the below screen. When we click on Search the Microsoft Store app (new), we get a search box available.

We have UWP apps available in the Store, like the Company Portal app.

But we also have WIN32 apps, like we already have seen when we searched the store ourselves with WinGet.

When we select an app, most of the Information is pre-populated. The Name, description and Privacy URL are filled in. The only thing, which is missing, is the Logo.
We also see the Package Identifier and Installer Type, which have seen before via WinGet.

The same information, but for a WIN32 app type.

After selecting the app, the only thing left, is assigning the app which is straightforward. We can assign the application to groups, and we have filters available.

And there are our UWP and WIN32 apps available in Intune from the new store.

End user experience

The new store apps are not available anymore in the Microsoft Store on the local device, these only become available in the Company Portal app.
Currently the new store is not supported in the ESP, thus the Company Portal app is installed after the user is signed in.

If you already made your WIN32, LOB and UWP apps available before in the Company Portal, your users don’t even notice the difference between the store with which an app is published.

The description and additional information are shown, but your users won’t see the source of the application.

And without wrapping the WIN32 app ourselves, the end-user can install Adobe Acrobat Reader DC without having administrative permissions on the device.

Side notes

It’s a good idea to also have a look at this official documentation of Microsoft regarding the Microsoft Store.
Certainly have a look at the section regarding Store group policy restrictions.

I’ll suggest you’ll also read this article related to managing Windows Package Manager/ WinGet.

That’s it for now. If additional information is available regarding the new Microsoft Store I will update this article.




10 Comments

  1. So right now is there no way to know how the update behavior of each app will work? Worst case you would end up with apps significantly out of date, you could run winget upgrade -h -all but that would be very disruptive to users.

    • As far as I know its based on the Microsoft Store so the updates should be handled there. I enabled the auto update for the Microsoft store over a administrative Template and a proactive remediations runs on ever 2nd Friday to upgrade all winget apps 🙂

      • Hi Chris, is it possible that you share the script for proactive remediation using winget to update all app. I am trying to do this but always get an error that winget could not be found.I have saw somewhere that deploying the script as a system user is the problem. Please how are you able to handle this ?

        • Have you managed to find a solution to this as I can’t get winget install to run under from a powershell install script.

    • De UWP store apps still use the store functionality, so are just kept up to date.
      MS needs to work something out for WIN32 apps. For now, you could schedule a PS script which update all the WinGet managed apps.

  2. How will this work as a replacement for apps installed during Autopilot?

    The recommendation was to use an Offline licensed version of the Company Portal when installing during Autopilot. Will this method work file for an Autopilot deployed scenario?

    • Currently, this is not supported during Autopilot enrollment. You can’t select these new store apps in the ESP. If you assign an app as required, it will be installed after the enrollment.
      Let’s hope Microsoft adds support before the old store is retired.

    • Hi Chris, is it possible that you share the script for proactive remediation using winget to update all app. I am trying to do this but always get an error that winget could not be found.I have saw somewhere that deploying the script as a system user is the problem. Please how are you able to handle this ?

      Regards

  3. NIce Post!
    Can you share the proactive script that u use to update Microsoft Store apps (win32apps) pushed with Intune.

    Would be lovely!

    Is there also a possibility in Intune to lock (automatic updates for uwp apps) so that users can’t change this?

    Kind regards

    Rens

  4. Great post. One question; are all Winget apps available through the Store? I’m trying to install the Microsoft Visual C++ Redistributable ID Microsoft.VCRedist.2015+.x64 but I can’t find it in the store. I’ve tried installing it with a powershell script to run winget install but winget won’t run under user workgroup/system.

Leave a Reply

Your email address will not be published.


*