Last Updated on January 31, 2023 by rudyooms

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

I am not going to guide you through each simple step but I am going to show you how you can abuse use it to install other Store Apps even when the Microsoft Store is blocked. I will divide this blog into multiple parts

1. Introduction
2. How does it work
3. Private Store Only
4. The Agentexecutor.exe
5. Winget and the Win32Apps
6. DesktopApp Installer GPO
7. Enable App Installer Microsoft Store Source
8. Enable App Installer Default Source
9. Applocker and the MS Store and Winget
10. What the Package Manager team is working on

1. Introduction

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

This new Microsoft Store App feature relies on the Desktop App Installer / Package Manager / Winget to get the apps installed 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 at the OOBE, Winget is NOT yet installed. I am also mentioning 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 is able to 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

It could take some time when you have a freshly installed device before the Company Portal starts installing. After some time waiting and having the build 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 is recommending 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 are also making sure 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! No restrictions nothing… 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 to block it for a while as Winget itself isn’t the only option to install UWP or Win32apps 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

Looking at the sources we got in Winget, it should be okay to remove the MS STORE source. 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 has some weird behavior on newly enrolled devices. Feel free to check out my latest blog in which I deep dive into this CSP setting.

Secret Society of Second-Born DesktopAppInstaller CSP’s

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 was describing in the previous parts, using Applocker to restrict the launch of executables is always nice but using it to block 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

When looking at the Applocker event log we will notice the same error. As shown below event 8025 is mentioning that Netflix was prevented from running

10. What the Package Manager team is working on

While writing this blog, a nice Twitter conversation was going on. When looking at the statement Demitrius Nelon made (The guy that’s working on the Windows Package Manager)

He is mentioning that they are working on a new policy that blocks users via Winget but NOT the COM API for Intune!!!! That sounds exactly like what we want! Right?

Conclusion

With the new policy in progress, we will have a good option to block users to use 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 are 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)