This blog will be an additional part of the blog I wrote about my experiences when deploying UWP /Store Apps with the New store App functionality in Intune. I will deep dive into a specific DesktopAppInstaller GPO setting that could break your Store Apps on newly enrolled devices.

1. Introduction

In my previous blog, I showed you my experience with the New Microsoft Store Apps feature and how Microsoft Store apps are deployed in the background without the need for Winget to be installed.

Microsoft Store Apps | Intune | Winget | Private Store (call4cloud.nl)

While writing that blog and trying to come up with a solution to block Winget for the standard users I also broke the deployment of UWP Store Apps for new Autopilot enrollments.

By the looks of it, this was caused by this CSP I configured Enable App Installer Microsoft Store Source (EnableMicrosoftStoreSource)

Please note: This CSP is only working for Windows 11 even when Microsoft their docs are mentioning Windows 10 is supported!

After configuring this CSP in my test tenant, all my new Windows 11 devices stopped receiving the Microsoft Store Apps I pushed with the new feature. I will guide you through what I configured and noticed with this policy being applied on existing devices and new devices.

2. Let’s see it in action

Let’s start by taking a look at what happens when the device is already enrolled. I configured the CSP setting I mentioned in the previous part and waited some time. After syncing the device and a couple of minutes of waiting, the registry key arrived at the device to block the Microsoft Store Source in Winget

When deploying this registry key or the CSP on an existing device, we are removing the “msstore” source and combining it with the other CSP I mentioned in my previous blog. With both of these settings configured there will be no sources left when taking a look at the Winget sources

When trying to install a new Microsoft Store app on an existing device from the Company Portal we will notice that we are still able to install the UWP App but are unable to do the same with Winget

As shown above, and of course mentioned in the previous blog the IME / Agentexecutor uses its WindowsPackageManager.DLL file to deploy these apps, so it’s not depending on the DesktopAppinstaller its DLL file.

But a biggggg BUTTTTT… a very big but!!!! When this Appinstaller CSP setting is being deployed to NEW enrolled devices you could end up with some weird errors. With the msstore source missing, it pretty much looks like the agentexecutor.exe isn’t able to do its job and it will fail to install the required UWP apps.

Let’s take a look at what errors we could run into and perform a sort of deep dive into the Microsoft.Management.Clients.IntuneManagementExtension.WinGetLibrary.dll and of course the main DLL, the WindowsPackageManager.dll

3. Troubleshooting

So I enrolled a new Windows 11 22h2 VM again and waited and waited but no Microsoft Store Apps were installed. I guess I need to perform some troubleshooting to find out if that CSP is really causing this.

First I opened the event log and immediately noticed a lot of Store event id’s 2005/2006/2007

When taking a closer look at them, those events are indeed mentioning the UWA Apps but it looks like updating the InstallAgentPdcActivation failed.

But when comparing the Application event log with the Store log, it doesn’t seem that this error has anything to do with it. As shown below, my application event log is filled with Application and .NET Runtime errors

All of them are mentioning the fact that a process was terminated due to an unhandled exception. Let’s find out if we maybe could install the UWP apps with the agentexecutor with the -executewinget command I showed you before. Within a second after executing that agentexecutor.exe command a lot of nasty errors will be thrown at you

As shown above, as pretty much expected, the agentexecutor.exe command we entered shows us the same kind of error we noticed in the Application event log

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

I guess it’s a bit broken… Let’s fire up a Procmon trace to find out what’s happening before it crashes into 1000 pieces!

When looking at Procmon, it indeed looks like it is checking that same registry key that was set with the CSP before breaking apart. As shown below, it tries to find the EnableDefaultSource and EnableMicrosoftStoreSource registry keys

Okay, this is getting weird… as the agentexecutor.exe should be a totally different product than the Windows 11 build-in Winget product but somehow it checks the registry key from above. After walking through the whole Procmon trace, I noticed that SMARTLOCKER is being mentioned a lot

SMARTLOCKER as in the Applockerfltr.sys

I was wondering if maybe Applocker could also be interfering if those registry keys are set to block the Microsoft Store Source because I know that with 22h2 some changes were made to Applocker (More on this in a future blog) To be sure I removed the Applocker policy assignment and enrolled a new VM

After the VM was up and running again, I again waited some time but no Store Apps were delivered. Unfortunately also running the agentexecutor command ended up with the same error we noticed earlier.

After excluding Applocker, I was curious about what would happen when I revert the CSP settings. I decided to manually change the 0 in the registry keys to a 1, to be sure the MS Store Source will be enabled again.

As shown below after changing the registry keys and enforcing them with a good old gpupdate and running the same agentexecutor command again, the WhatsApp store app started installing immediately!

So reverting the CSP changes to enabled brought the Store Apps installations back to life within a matter of seconds! Okay, let’s switch those registries back to disabled, and let’s try again!

Huh? Okay, so having those registry keys disabled (zero) when the device enrolls crashes the Agentexecutor but switching them on (1) and off (0) if the device is enrolled just works?

Let’s find out if we could spot something in the Microsoft.Management.Clients.IntuneManagementExtension.WinGetLibrary.dll as that DLL file is being mentioned in the App Crash. I opened DotPeek and opened that nice DLL file and start poking around a bit

I started with the ConnecttoCatalog which was also mentioned at the start of the Agentexecutor crash. As shown below it doesn’t show me much except the RepositoryType

So I took a closer look at this WingetRepositoryType to hopefully find something usefull

As shown below, the WingetRepositoryType shows us the same Winget Sources I disabled with the CSP.

That can’t be a coincidence, right? Let’s dig further and let’s open the WindowsPackageManager.dll file instead. This is IME its own DLL file with all the “Winget “functionality in it.

I guess the first thing to look for in this DLL would probably be the EnableMicrosoftStoreSource key as that is the one that is causing the issue

As shown above, the WindowsPackageManager.dll file from the IME also has references to these policies. That’s odd? as again the WindowsPackageManager is NOT Winget? I guess I need to ask that question to someone at Microsoft.

So the only thing I could think of what my next step would be to resume troubleshooting, was opening myself a nice beer!

4. Sources_metadata

After having some trouble opening that Beer I decided to just keep on scrolling, scrolling… Until something nice caught my attention

As shown above (you can click on it to get a better view), first I spotted the “Dropped Because of group policy“, after noticing that line of text I stopped scrolling and started reading a bit more concentrated. I noticed that the next few lines were mentioning SetMetaData and sources_metadata

Did I miss something in my Procmon trace? It certainly looks like it, stupid me. I installed a new VM (for the 50th time) and opened Procmon. This time I made sure I added 2 Filter rules to make sure I will catch everything that tries to “touches” those 2 paths

As shown below, I added the path: Sources_metadata and EnableMicrosofStoreSource.

As shown above, the Agentexecutor.exe checks the EnableMicrosofStoreSource registry key and within some milliseconds it tries to create a file sources_metadata in the user its localappdata\microsoft\WinGet\Settings\Defaultstate folder.

When taking a look if the folder exists in the user its localappdata I came to the simple conclusion, that it was missing in action.

I manually changed the EnableMicrosoftStoreSource to “1/Enabled)” and executed that same agentexecutor.exe command

As shown above, the moment I pressed enter to pass the command, the sources_metadata was created and the UWP Store app started installing immediately. Guess what that sources_metadata file showed me when opening it!

As Shown below: Sources: -Name msstore. That sounds familiar, doesn’t it? If not for me it did 🙂

Let’s step it up a notch because in part 4 I noticed that if the EnableMicrosoftStoreSource was set to 1, and the agentexecutor command was executed successfully only one time, it would keep working. It didn’t matter if you changed back that EnableMicrosoftStoreSource to 0/Disabled it kept working… Except if you remove that sources_metedata file! At the moment you remove that file, the agentexecutor starts crashing again!

5. Fixing It my way

I guess I could draw the conclusion for now, that when that EnableMicrosoftStoreSource is disabled, Winget isn’t going to create the required sources_metadata, and by the looks of it without that file, the Agentexecutor crashes! Let’s fix it!

I created 2 bat files (As I am blocking PowerShell in the user session) to make sure those directories get created in the %localappdata% folder and to copy the sources_metadata file to that same folder

I uploaded the IntuneWin Package to Intune and defined the Install behavior to “user” because I want that app to be executed in the user context.

As always I also needed to define a user-based detection rule. Damn!! I just created a blog about that one, which will come in handy!

User Context Install | Uninstall | Intune | Detection Rule | (call4cloud.nl)

As shown below, I created a file detection rule to detect that same file in the user ist localappdata by using %username% in the detection rule

To be sure it arrived in time, I assigned the app to a user group and also added the app as a required app to the ESP. After entering my username and password after the device setup, the account ESP setup started, and in the background, the App created the sources_metadata

Once the account setup ESP page was finished I immediately opened a cmd and wanted to execute the agentexecutor command but just before clicking on enter, I noticed that the most important business App Whatsapp started installing!!! Damn!!!

6. Copy/Paste

After stumbling upon the source_metadata issue, I wondered if the Intune department just copy/pasted the DLL, and used it for their own purposes 🙂

Please note: I am only guessing and doing a lot of assumption here, so don’t blame me on this one.

When looking at the Microsoft.DesktopAppInstaller folder in the c:\program files\windowsapps folder we will notice that the DesktopAppinstaller folder holds almost the same WindowsPackageManager.Dll

I decided to open this DLL file with IDA and searched for the same things. Even when the files arent exactly the same size, the DLL file from the IME folder still holds a lot of stuff from the “originally” DLL

So I guess when the Intune department had the perfect idea to use that DLL from Winget, “they” just took it, changed/removed a lot /added a couple of lines and it would be all okay?

I guess that could explain why the agentexecutor that relies on the WindowsPackageManager.dll to install Store Apps could break on the “Winget” policies

7. What’s next?

While trying to perform some more troubleshooting, I also reached out to Demitrius Nelon. After talking for a bit he asked me to put in “New Issue” on the Winget Github page

AgentExecutor.exe Crashes · Issue #2742 · microsoft/winget-cli (github.com)

As shown in the above link, hopefully, we will get an official answer about what is going on. As those 2 products shouldn’t interfere (so I am told)

By the looks of it, the fix for this issue will/is been added to the v1.5 Milestone

This version will be due by April 30 2023 and yes a “fix” for the AgentExecutor.exe crash seems to be in it

Conclusion

When trying to restrict Winget by setting up those CSPs you could run into some weird behavior. It’s kinda funny because Peter Klapwijk did the same but didn’t notice any errors with new enrollments

Manage Windows Package Manager settings with Microsoft Intune | Peter Klapwijk – In The Cloud 24-7 (inthecloud247.com)

So I guess I am losing it a bit… for now I will wait until Demitrius has some new policies to only restrict Winget in the user session and stick with my trusted Applocker deployment