Last Updated on March 8, 2023 by rudyooms
This blog will show you how I started troubleshooting an issue in which Microsoft Store Apps failed to install. I will guide you through the PowerShell script I always use to collect logs and which logs I used to determine what is going on
I will divide this blog into multiple parts
- Store Event Log
- AppxDeployment-Server event log
- DO log
- IME Log / Get_package.txt
- The Cause and the Fix
Every day is a new day and this day someone posted this wonderful question. He was mentioning the fact that the Company Portal failed to install. He tried to deploy it from the Legacy Microsoft store and the new Microsoft Store that relies on Winget to fetch the App.
Please note: If you want to know the exact flow and how the IME uses its own Winget DLL please read this blog first
Hotel Microsoft Store Apps: Transformania – Call4Cloud
After some chatting, I asked him to run these 2 commands to provide me with some wonderful logs
wget https://aka.ms/intuneps1 -outfile IntuneODCStandAlone.ps1 powerShell -ExecutionPolicy Bypass -File .\IntuneODCStandAlone.ps1
These 2 commands will fetch all the stuff I need to start troubleshooting this particular issue
2. Store log
I guess with all these logs in my possession, the first place to start looking would definitely be the Store Event log… because it’s a store issue, right? And store issues are logged in the…. Store log?
I opened the Store Event log and immediately stumbled upon a lot of warnings and errors
As shown above, the first nice error I noticed was mentioning that it failed to navigate to the page: https://storeedgefd.dsx.microsoft.com . Sound like a Microsoft Store URL, right?
Another warning also mentioned it failed to get data from the same network Store URL
After scrolling through all of the errors, I also noticed this one. Mentioning Access Denied and the error code 80070005. That sounds familiar, right?
Something Went Wrong – Fury of the Gods – Call4Cloud
Pretty much sounds like the: blocknonadminuser CIS baseline setting all over again
With this in the back of my mind, I needed to start looking at the next event log: appxdeployment-server
As shown above, again that same 0x80070005 error … okay, the CIS issue it is!!! Luckily the log collection also contains a nice policymanager.txt file in it with all the policymanager keys from the registry. For anyone that doesn’t know the policymanager registry key, this reg key contains all the configured Intune settings
4. Policymanager.txt key
After all those errors pointed me to the blocknonadminuserinstall registry key, I opened the policymanager.txt file and started searching for the it!
Yeah!!! It’s there!!! Owww, wait ……
That blocknonadminuserinstall exists in the “default” subkey and not in the “current” key where it should be in the first place to get enabled or disabled
Besides the wrong place, by default it has a value of zero… zero means this setting is NOT enabled!!! Okay, I wasn’t expecting that but let’s continue to find out what is going on because this time it isn’t the CIS baseline that is causing issues!
I decided to open the Windows Update log to spot if that log is telling me the same thing because, in an older blog, I also noticed the fact that Windows Update is being called upon when Store Apps are in need of some updates
As shown above, the Windows Update log indeed also mentions the CompanyPortal
But at the same time, it also mentioned a bit of the same error: Failed 80242023, failed to get download volume. Scrolling down the log, showed me the DO job (Delivery Optimization?)
This DO job was telling was showing us a 0x80190193 error. Aka “Access Denied”? Up to the DO log
6. Do log?
When looking closer at this DO log, this one also showed a lot of failing stuff and CDN errors.
Almost as if some networking going bad!! I guess we need to focus a bit more on networking. Maybe a DNS issue? as it is always DNS?
To rule out DNS and possible other networking errors, I opened the networking.txt file
This networking.txt file showed me 2 Ethernet adapters. One Virtual and one wifi?
The Virtual one really looked like a connected VPN client to me. It also shows us the default gateway: 0.0.0.0 . That does remind me of something!
Force tunneling…Let’s check the IME log if I could spot a VPN client
8. IME log
I opened the IME log with the CMtrace tool and started searching for the “Collected App Inventory Details” hoping it would show me the installed apps
As shown above, it is mentioning the GlobalProtect Palo Alto Vpn client! To be sure I also opened the Get_package.txt to check out if it also mentioned the same VPN client
Yes, it did!! Okay… I guess we know where to look now!
Store Apps –> Network Issues –> Vpn Client –> 0.0.0.0 –> Tunneling?
9. The cause and the fix
Microsoft really needs to improve its SEO… even when I was pretty sure that Microsoft already documented it, it took me some time before I could find it.
Microsoft Store doesn’t open after a domain-joined computer makes a VPN connection – Windows Client | Microsoft Learn
As shown in the above MS docs link it is indeed showing us the force tunneling
Luckily I don’t need to come up with funny solutions
The recommended solution by Microsoft is just creating a Network Isolation group policy and adding the local VPN adapter IP range to it. With this GPO set your job is done and you could install Store Apps again!
When you run into an issue when Microsoft Store apps aren’t getting installed, you need to check if you are using a VPN. When using a VPN, you probably didn’t configure network isolation/private app network range
Hopefully, this blog showed you how you could start troubleshooting by using the IntuneODCStandAlone.ps1 (which is also used by MS Intune engineers).