Call4Cloud | MMP-C | Autopilot | Device Preparation

Hotel Microsoft Store Apps: Transformania

Patch My Pc | install & update thousands of apps

This blog will show my experiences with Intune’s new Microsoft Store App functionality. I wanted to publish the next part of my Autopilot series this week, but with all the commotion going on, I decided to write something about the functionality of the new store apps in Intune. It’s a bit of a quickly written blog, but I hope you like it.

I won’t guide you through each simple step, but I will show you how to use it to install other Store Apps even when the Microsoft Store is blocked.

1. Introduction

With the Microsoft Store for Business going to be deprecated, I love this new feature for installing Microsoft Store apps.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

This new Microsoft Store App feature relies on the Desktop App Installer / Package Manager / Winget to install the apps on the devices. Feel free to read this blog about it to get some more background information on Winget

Install | Deploy | Use Winget | System context | Intune (call4cloud.nl)

Please note: Winget is only used to install the app, not to update it. Updating the existing apps is the MS Store’s responsibility

2. How does it work

If you decide to reinstall your device, you will notice that Winget is NOT yet installed at the OOBE. I also mention this in this blog below.

Install | Deploy | Use Winget | System context | Intune (call4cloud.nl)

winget is not recognized as an internal or external command

But even without Winget available on the device, the Intune Management Extension(IME) “knows” about the Package Manager Framework / Winget. As shown below, this functionality is “build-in” into IME.

The IME will use the Microsoft.Management.Clients.IntuneManagementExtension.WinGetLibrary.dll and, of course, the main DLL, the WindowsPackageManager.dll. With these “build-in knowledge/Dll files“, the agentexecutor.exe can install the MS Store Apps!

Let’s continue our wonderful story, and let me add a UWP Store App. In this example, I added the Company Portal as a UWP store app in Intune.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

When you have a freshly installed device, it could take some time before the Company Portal starts installing. After waiting some time and having the built-in Winget Package manager updated, we could also use Winget in our own user session.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Guess what a user can do when it has access to Winget? Yes, install user-based apps! For example, installing Netflix can be done within a couple of seconds.

That’s not what we want, do we? So let’s block it! or at least try to block it!

3. Private Store Only

When we don’t want the user to install Store apps on their devices, we could use the option to only allow the Private Store without blocking the public store. Even Microsoft recommends it to make sure you are blocking the installation of arbitrary applications from the store application…

Store Application… doesn’t mention anything about Winget, does it?

if you would like to block installation of arbitrary applications from the store application by the end user without blocking the intune and windows packafge manager store integration set store\only display the private store within the microsoft store to abled

Then again Winget is not the Microsoft Store… but for now, let’s proceed and let’s configure a policy to make sure you require a private store

Please Note: Enterprise License required

a microsoft app store policy to require private store only

If we deploy this policy to our devices we will notice that we can’t access the Microsoft Store any longer on our Windows 11 devices.

Microsoft store is blocked when we want to open the microsoft store on the device

With this policy deployed, you also ensure you can’t trigger any Microsoft Store app installation from the apps.microsoft.com website.

Afbeelding met tekst  Automatisch gegenereerde beschrijving
Afbeelding met tekst  Automatisch gegenereerde beschrijving

Okay… so installing apps from the Microsoft Store and from the Store Website isn’t going to work. Let’s try to install the “remote desktop client” UWP app with Winget.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

My first attempt with a shiny new VM ended up with the error: No Store Account found

If you happen to run into a “No store account found” error when trying to install an App, it is probably because the Desktop App Installer (Winget) was not up to date. Opening the Microsoft Store to update the apps while only allowing the Private store wasn’t going to work, so I needed to update the Desktop App installer without direct use of the MSstore.

Allow winget to install MS Store packages without account by zachcwillson · Pull Request #2095 · microsoft/winget-cli · GitHub

After updating the desktop app installer, we can install all the UWP apps we want! There are no restrictions. Duhhh, it’s Winget, and it doesn’t seem to need access to the Microsoft Store to install the UWP apps.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Of course, instead of manually updating the Desktop App installer, we can trigger it with PowerShell. Open PowerShell in the user session and enter these commands to update the store apps to the latest version

$namespaceName = "root\cimv2\mdm\dmmap"
$className = "MDM_EnterpriseModernAppManagement_AppManagement01"
$wmiObj = Get-WmiObject -Namespace $namespaceName -Class $className
$result = $wmiObj.UpdateScanMethod()

Conclusion: Only allowing the private store obviously doesn’t remove the Winget option to install UWP apps from the MS Store source.

Let’s go forth and try to find another solution for this funny issue.

4. The Agentexecutor.exe

Let’s ditch the idea of blocking it for a while as Winget itself isn’t the only option for installing UWP or Win32 apps on our own turf. Let’s take a look at how we could install WhatsApp without directly using the Winget command or the Company Portal

Afbeelding met tekst  Automatisch gegenereerde beschrijving

If you decide to install Whatsapp with the new Intune store app functionality we will notice by looking at a Procmon trace that a nice log file will be created.

This log file will be created inside the USER its localappdata\temp\Winget\DefaultState folder

winget event logs can be found in the user local temp winget default state folder

When opening this log file, as shown below, we will notice it contains a command line with some arguments. This command line uses the agentexecutor.exe to install the UWP app

the winget event log showing us each step of the installatio process

When looking at the arguments we got from the log file and comparing them to the agentexecutor.exe itself we opened with DotPeek, we will spot some similarities. (you can click on the image for a better image)

If we copy/paste this command in a cmd session in the user session we also could install Whatsapp without any issue!

agentexecutor.exe -executeWinGet “Install” “MicrosoftStore” “9NKSQGP7F2NH” “User” c:\temp\results.txt

the microsoft store is blocked but i could still leverage the intune management extension to install the winget app on my own by using the agentexecutor.

So let’s try it again but this time with the Netflix app instead.

As shown above, Netflix, WhatsApp, or any other Store App can be installed without any issue with the Agentexecutor.exe even without the Store App being added to Intune as a required or available app

If you are wondering if you can also Uninstall the app with the agentexecutor.exe or by configuring the Uninstall assignment in Intune

Yes, you can! If you change the WingetPackageInstallScope to Uninstall, the UWP app will be uninstalled

5. Win32app attempt PowerToys

But I am not done yet.. as I noticed the possibility to deploy a Win32 app to the device with the use of Winget. For example: let’s try to install PowerToys

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Mmmm… it mentioned that this app is not supported in preview! Okay, no problem as the agentexecutor.exe hasn’t any issue installing the app… right?

Let’s track it down by opening the same log file again in the Winget local AppData folder to see what happens. As shown below, it downloads a plain executable file to the same folder we got when searching for the log files.

Afbeelding met tekst  Automatisch gegenereerde beschrijving
Afbeelding met tekst  Automatisch gegenereerde beschrijving

As shown below, inside that log folder is an additional folder created with the executable file in it. Sounds less secure than the decrypted intunewin file we have when deploying Win32Apps

Afbeelding met tekst  Automatisch gegenereerde beschrijving

In a normal or maybe a less secure environment, you will have no issues when installing a USER-based installation (of course, when the app needs more permission, a UAC prompt will be shown). If you are using Applocker…. That’s another story

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Luckily, I was already showing you this behavior in this blog: Microsoft Store trying to install User Context Winget Apps (call4cloud.nl)

I guess the conclusion would be that with a proper Applocker setup already configured, you are safe, and that “nasty” exe file will be blocked

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Please Note: Even when changing the “User” to “System” won’t change the installation behavior as you are triggering the agentexecutor.exe in your own session.

Afbeelding met tekst  Automatisch gegenereerde beschrijving

Okay, let’s switch back to trying to block the Winget Msstore functionality again but without using Applocker by using the Desktop App installer ADMX files

6. DesktopApp installer ADMX

It’s a shame those ADMX files aren’t (yet) available in the Intune settings catalog, so for now we need to come up with another method to deploy them (if we want). Luckily I got you covered here with some blogs I wrote about ADMX ingestion and importing ADMX into Intune

Build your own ADMX templates and deploy them into Intune (call4cloud.nl)

This time we don’t need to create or own Desktopappinstaller.ADMX file but we can download it and import it into Intune

admx file for the desktop app installer (winget)

Removing the MS STORE source should be okay, considering the sources we got in Winget. At least that was my first idea

Because looking at the options we have, Disabling the whole App installer really doesn’t sound like a good idea…So I guess the only option we have is to make sure a user can’t use Winget to install apps from the Microsoft Store Source by configuring those policies as shown below.

configuring the app installer settings to define the default source to be the winget source

After importing the ADMX and configuring the device configuration policy, we ended up with the error 0x20101

error 0x20101 shows up after importing the admx

That doesn’t sound good as I know that 0x20101 error: Troubleshoot import errors when uloading the ADMX to Intune (call4cloud.nl)

As shown below, the same error and reason I was mentioning in the blog above: A blocked registry key

event 850 corrosponds with the 0x20101 we got in Intune. This means: blocked registry key

Damn… no ADMX import for us so we need to come up with another solution to deploy some additional settings

7. Enable App Installer Microsoft Store Source

I decided to write a simple PowerShell script to deploy some Desktop App installer settings to the device. I started with the “Enable App installer Microsoft Store Source” because disabling the whole App installer isn’t a good idea! As it will totally break UWP Store Apps deployments

configuring the enable app installer microsoft source with an intune policy

As told above because the AMDX option isn’t working, I created a PowerShell script to create the same registry key that the ADMX would set

creating a powershell script to configure the microsoft store source

Another possibility would be is to use the good old CSP functionality to restrict it

Afbeelding met tafel  Automatisch gegenereerde beschrijving

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DesktopAppInstaller/EnableMicrosoftStoreSource

VALUE: <disabled/>

Unfortunately, this setting behaves weirdly on newly enrolled devices. Feel free to check out my latest blog, in which I explore this CSP setting in depth.

I decided to remove the part because it was overshadowing this blog in which I was trying to point out how the UWP Store Apps deployment works

8. Enable App Installer Default Source

The second policy I configured was configuring the App Installer Default Source. When looking at the explanation, this policy will disable the default source for Windows Package Manager.

Again I made sure the App installer setting was deployed to the device before the user could log in to his desktop

OMA-URI: ./Device/Vendor/MSFT/Policy/Config/DesktopAppInstaller/EnableDefaultSource

VALUE: <disabled/>

Or by configuring a PowerShell script to do so

creating an oma-uri to configure the enabledefaultsource

By the looks of it, it doesn’t “break” anything. The Company Portal and other required store apps could be installed without any issue

I decided to take a look at the Winget sources available with the source list command. As shown below, only the msstore source is available!

Do you remember the Whatsapp Store App that I wanted to install in a previous part? With the Winget Source available we could also install WhatsApp from the Winget source instead.

But without that option, we can only use the MSStore source. Sounds like an improvement but I still need to perform some more tests to be sure it doesn’t break anything else

9. Blocking with Applocker Store apps

As I described in the previous parts, using Applocker to restrict the launch of executables is always nice, but blocking Store UWP apps is also a very good option. I opened my own call4cloud.nl website and copied the msstore Applocker XML file, and replaced the one I got in Intune

Restricting or blocking access to the Microsoft Store (call4cloud.nl)

If we try to install Netflix with Winget or the “Agentexecutor.exe”, it will fail! It will mention that the app is blocked by policy

winget install command showing us that it failed to isntall or update microsoft store package because the specific app is blocked by policy
Afbeelding met tekst  Automatisch gegenereerde beschrijving

This same error code could also be spotted when looking at the WindowsPackageManager.dll file in the Intune Management Extension Folder

We will notice the same error when looking at the Applocker event log. As shown below, event 8025 mentions that Netflix was prevented from running.

applocker showing the 8025 event log when it blocks an app from the microsoft store.

Conclusion

With the new policy in progress, we will have a good option to block users from using Winget on their own turf, but that is only 50% of the solution.

As I showed you before, you can still use the agentexecutor.exe to install the same Store Apps as a regular user. Luckily, the Applocker policy to restrict Store App installation by only allowing Microsoft Store apps is already in place at our customers.

Even when Applocker is like taking a sledgehammer to a screw, I love it… (okay WDAC would be way better.. but better have something in place than nothing)

Sledgehammer GIF | Gfycat

3 thoughts on “Hotel Microsoft Store Apps: Transformania

  1. Hey,

    Great article! Maybe you can help me with a specific problem.

    I set the Policy from the settings picker for Require Private Store Only. I blocks the Windows Store right away. But after i did this, i wasn’t able to install store apps from Intune, including the Office 365 package.

    A little bit of searching in the IntuneManagementExtension log showed the following:
    WinGet operation result:
    Operation result = UnknownError
    Installed version =
    Reboot required = False
    Installer Error code = -2146233079
    Installer extended error code = -2146233079
    Installer exception message = Method cannot be called without searching the app first.
    Detection result:
    Action status: Failed
    Detection state: NotComputed
    Detected version:
    Error code: -2146233079]LOG]!>

    Do you have any idea, what i can do about this?

  2. I have enabled “Turn off the store application” under “Administrative Templates>Windows Components>Store. My expectation was this will block “Microsoft Store” and also block installing applications using winget.
    The test revealed that Microsoft store is blocked but Winget is still working.
    1. Are you saying Winget is not reaching out to Microsoft store for source?
    2. How can I block winget installs as well?

  3. I was looking for a way to make Win32 with Winget so that I could detect if the UWP app was on the PC. We changed from user install to system and there was only errors in Intune. All new assigments works fine but the old assigments get error messages during notifications in Windows. Microsoft store forbuiness new doesn’t seem to give up after trying to install the UWP company portal when it’s already there.

    Greatly appreciate tips and help

Leave a Reply

Your email address will not be published. Required fields are marked *

4  +  3  =  

Proudly powered by WordPress | Theme: Wanderz Blog by Crimson Themes.