Last Updated on February 2, 2023 by rudyooms
This blog will show you my first experiences dealing with Winget and installing Store Apps from the Microsoft Store as a regular user. I will try to show you what you need to beware of and some funny details
I will divide this blog into multiple parts
- Introduction
- Blocked!
- The Exe file and the UAC Prompt
- The Store, Winget, and Fiddler
- The Store and Procmon
- How to solve it.
1. Introduction
Someone reached out to me asking why it wasn’t possible to install OneNote from the Microsoft Store. The moment I was reading it, I immediately had my hopes up that it would be using the Winget Package Manager that has been announced some time ago.
I even wrote some blogs about Winget and the MSFB deprecation, so maybe it could be useful to read them first… if not … we are still friends!
Install | Deploy | Use Winget | System context | Intune (call4cloud.nl)
Microsoft Store for Business Deprecated! What to do now? (call4cloud.nl)
To install the OneNote app if it wasn’t part of your Microsoft 365 Apps deployment in Intune, I opened Microsoft Edge and searched for OneNote. As shown below, it showed me the Get the app in the Store
Okay so if it’s in the Microsoft Store, I could also add/buy the app from the Microsoft Store for Business and deploy the app with Intune to my devices, right? As shown below.. no results were found when searching for OneNote in the MSfB.
Noticing the app missing in the MSfB made me smile a bit. Because if it isn’t in the MSfB, it should be using “something else”
2. Blocked
I am a good boy, so I always make sure Applocker (or WDAC) is deployed on my devices. You can guess what happened when pressing the install button. The Microsoft Store app will initialize the installation in the user context. My first attempt to install the OneNote store app ended up in a nice Applocker Blockade. As shown below a nice 8004 Applocker event.
Did you notice the red marker placed around a word with 6 characters? I guess you did….the Applocker 8004 event is mentioning the Winget Package Manager! Okay… I am intrigued. I wanted to know what it would show me when I allowed it in my Applocker policy. To do so I opened the folder in which the exe was placed in
Before opening gpedit.msc to create the required XML to allow the executable to be opened in my own user session I first executed the get-applockerfileinformation PowerShell command to determine if it even had a Publisher
As shown above, yes it does! I opened gpedit.msc and added a new exe publisher rule and selected that nice exe file
After I added the executable to be allowed with a publisher rule I exported the XML and added it to my existing Applocker device configuration profile in Intune
To speed things up, I trashed my Applocker MDM folder on my device and synced the device, and waiting a couple of minutes my device received the latest Applocker policy.
3. The Executable and the UAC Prompt
With the new Applocker policy arriving on my device, I restarted the OneNote Store App installation. After a second or two of downloading the Store App, I received a nice UAC prompt
You might think that entering the proper admin credentials would start the installation process, right? But unfortunately, that isn’t the case! As shown below we will receive this error.
This Network error is telling us we “need to check the spelling of the name. Otherwise, there might be a problem with your network” (ShellExecuteEx Failed; Code 67) Huh? the file is there and it showed us the UAC prompt, and the installation prompt.
Guess what happens when you enter the administrator credentials to start the installation. The executable will be relaunched in that admin user its context. To start the installation it of course needs to have permission to the user its WinGet folder.
Looking at the permissions, we will notice that ONLY the “SYSTEM” account and the user itself have permission to that folder and subfolders even when the administrators group has full permissions in the above temp folder. The only way to fix it is to enable inheritance.
Let’s continue our story because I am not a local admin! So I needed to cancel the UAC prompt. After canceling the UAC prompt, the Office setup told me that administrative privileges are required to continue the setup
That’s weird…… It needs to have administrative permission to install the app but the permissions to do so are missing.
I guess I first need to explain why we got the UAC prompt before moving on to the Winget part. I downloaded the sigcheck tool and I specified the exe file that was downloaded.
Please note: it’s of course the same as the OfficeSetup.exe but with some random names
As shown below the sigcheck tool is showing us the RequestedExecutionLevel and the UiAccess parameters
Please Note: I also explained that Uiaccess a bit in my quick assist blog
When looking at the execution level first, it’s mentioning the “AsInvoker” execution level. When specifying the “AsInvoker” parameter, the application will run with the same permissions as the process that started it. So in my case, my own user opened the Microsoft Store and clicked on the install button to initialize the download.
If we look at the UiAccess parameter, this one is mentioning the “false” flag. If it was set to true then the application would bypass the user interface protection levels and drive input to higher permissions and that is something you don’t want.
Before Windows would start an application with UIAccess privilege it would check if the application has a digital certificate and if the application is going to install in a folder that is only writable by administrators, such as the Program Files Folder. Guess where the OneNote app will be installed?
You could also spot that UAC prompt by running a Procmon session(more on this later on in part 5). As shown below the consent.exe (UAC) will be started after the download was successful
So with this obvious UAC prompt, I guess we can’t install the OneNote Store App from our own user session but luckily there are always solutions. Before moving on to the simple solution, let’s focus on some funny Winget Store details first and start with Fiddler
4. WinGet, the Microsoft Store, and Fiddler
Some time ago I also wrote a blog about fetching the Microsoft Store Appx packages when you press install in the Microsoft store by using Fiddler
Using Fiddler to decode Intune MDM or Graph traffic (call4cloud.nl)
So I was curious what Fiddler is going to show me with this Winget Store App because normally when you install an old-school Microsoft Store App, you would notice a connection to the tlu.dl.delivery.mp.microsoft.com URL
This URL is normally used to download operating system patches, updates, and APPS from the Microsoft Store
I guess when Microsoft is using Winget to deploy a store app we will notice a different kind of connection. As shown below, we will notice a connection to sparkcdneus2.azureedge.net instead
I was curious if it was also possible to just copy and paste that URL into a browser to download the file instead of using the DesktopAppInstaller to do so
As shown below, after entering that URL in my Edge browser it started downloading the same Office installer setup.exe
Isn’t that nice? Let’s move on to looking at the installation flow but this time with Procmon to see if we could spot some funny details
5. The Microsoft Store and Procmon
In the previous part, we learned that the Microsoft Store will use a different URL to fetch the selected Store App when it is going to be deployed with Winget.
When looking at the installation flow with Procmon, we could spot the Microsoft.DesktopAppinstaller.exe being called upon by the WinStore.App.exe to initialize the Store App download and installation
After the Winstore.App is triggered to hand over its job to the WindowsPackageManagerServer we will notice a lot of TCP connections being made to the *.deploy.static.akamaitechnologies.com CDN to fetch the installer
After the file was downloaded and the executable isn’t blocked by Applocker anymore we will notice the consent.exe process popping up, which I mentioned earlier to show the UAC prompt to the user
While looking at the Procmon trace I stumbled upon a nice Log file in my user’s local AppData folder: C:\Users\RudyOoms\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir
If you open that folder in your file explorer we will notice a lot of nice Microsoft.DesktopAppinstaller log files
When opening one of those log files we will notice the same flow I showed you with the Procmon trace.
6. Fixing it
I guess we can pretty much assume that deploying OneNote under the user context isn’t going to work. That’s pretty obvious with the setup being blocked with Applocker and the UAC prompt.
Wondering if we can’t use the system context to deploy it, that should work, right? Ow wait… I already wrote a detailed blog about Winget sometime ago mentioning how you could deploy Winget apps from the system context without messing things up
Install | Deploy | Use Winget | System context | Intune (call4cloud.nl)
After making sure I had a nice clean installed Windows 11 device and added Winget as a required/blocking app when the device is being enrolled I added an additional win32app based on a PowerShell script.
After syncing the device and enjoying an Intunebeer, something nice was added to my device
Conclusion
Noticing Winget being used when trying to install a Store app was great! When installing a Store App from The Microsoft Store in a user session, the Store App will always install in the User Context. It’s obvious that there are no local admins on our devices so it’s a bit of a shame that also this OneNote Store app gets installed in the User context instead of the System Context (even when it is the default behavior)
I guess that is just how the Cookie Crumbles
Luckily Microsoft will make sure we will have more Winget/Package manager options available when the integration in Intune is completed