Hotel Microsoft Store Apps: Transformania

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.

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)

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.

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.

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?

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

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.

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

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.

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.

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

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

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

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

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

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.

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

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

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

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.

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

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.

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

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

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

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

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

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

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

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.

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)