This blog will be about some weird issues with some Microsoft Store apps, such as when the device was wiped before being handed over to a new colleague. In this blog, I will use the Company Portal as the example app that will break.
1. Introduction
When an existing device is going to be handed over to a new colleague, it’s always wise to ensure it’s wiped. In the past, there were a few issues with some lingering user data in the Windows.It’s an old folder, but luckily, that’s behind us now…
To ensure the device is wiped, you can perform a remote wipe or do it yourself from the device itself by opening the Company Portal app, selecting your device, and choosing the “reset” option.
If you select the reset option, the device will start performing the reset without asking more questions (even when your user isn’t a local admin)
Great!!! After the wipe, the device is ready for use! But soon after the user logged in to the device and wanted to install some additional apps using the Company Portal, some trouble started occurring!
2. The Wipe breaks the Microsoft Store Apps
After performing a remote Wipe/Reset, you will notice that after logging in, the Company Portal doesn’t respond when you click on it. Even rebooting the device multiple times doesn’t fix it!
I decided to record it in my test environment because it can be easily reproduced! Please watch the YouTube video to get a good understanding of what was exactly happening.
Please Note: I also tried performing a Fresh Start and an Autopilot reset as shown below
The results of performing the “Fresh Start” and the “Autopilot Reset possibility” were pretty much the same, so no luck with these options
It is almost as if the “Migrate AppX Provisioned Apps” is broken in the Push Button Reset functionality.
Could be right, as it has happened before?
Windows 21H2 | Data Wipe Command leaves User Data on disk (call4cloud.nl)
3. Troubleshooting the broken Microsoft Store Apps
After spending a lot of time lately troubleshooting all kinds of weird store issues I knew where to look. I opened the AppxDeployment-Server event log, and immediately, a lot of errors showed!
Let me list the errors:
- Event 405 –> 0x8007005 –> Certainly the access is denied error
- Event 401 –> 0x80073cf3 –> The package failed to update, dependency, or conflict validation.
- Event 628 –> The Package depends on a framework that could not be found
One thing is for sure! The framework “Microsoft.Services.Store.Engagement” that the Company Portal depended on was missing! So I decided to compare the c:\program files\windowsapps on a working and the broken device
As shown above, on my broken device it was missing the Microsoft.Services.Store.Engagement_10.0.19011.0_x64__8wekyb3d8bbwe app and we all know that this is one of the dependency apps that need to be installed before the Company Portal could be installed.
4. What is causing this issue
Now we know what is causing the Company Portal app to be malfunctioning; we still need to know the “Why”
I wrote a blog post some time ago about the multiple options for deploying the Company Portal app to your devices.
Normally we are using the Online Company Portal app instead of the Offline Company Portal app but this customer still had the Offline Company Portal app configured as a required app during the Device ESP
We decided to switch to the Online version of the Company Portal, and after switching and wiping another device, the Company Portal was working! So, the Offline Company Portal being required during the device ESP is giving us some issues.
5. 2022-06 June Update?
I started to doubt myself a little bit because I know there were Store Issues when you installed the 2022-05 May update.
I even wrote a blog about that specific 0xc002001b error!
0x80073cfb error | Autopilot ESP | Windows 11 Build 25120 (call4cloud.nl)
Microsoft released an OOB update for that issue but deploying it with Intune could be difficult. Luckily I also wrote a blog on that topic.
Using Intune and WuFb and installing optional OOB updates (call4cloud.nl)
The Store Fix is included with the June 2022-06 (KB5014699) update. No more store issues for us! Right?
But… But.. I already had the 19044.1766 build installed BEFORE resetting the device?
That’s weird, as I was really expecting those stupid Store issues to be resolved with this update!
6. Solving it Option 1
In the troubleshooting part, it mentioned the framework Microsoft.Services.Store.Engagement_10.0.19011.0_x64__8wekyb3d8bbwe was missing from the device.
This framework is one of the dependencies of the Microsoft Company Portal. For now, we could still open the Microsoft Business Store https://businessstore.microsoft.com/ to download the Offline version of the Company Portal.
Hopefully, when the Store for Business is retired, it will still be possible to download those Appx files manually. If you have any questions about the MSfB being retired, please read my blog about it to fully understand what will happen.
After downloading that Appx file, I opened Intune, created a new LOB app, and selected the Microsoft Engagement Framework.
Please Note: Please select the Device Context as Install context to make sure it uses a device license and
I know…. mixing LOB apps and Win32 apps must be avoided but if I need to choose between a broken device and a working device, you can guess what I prefer
After uploading the APPX file, please make sure you also configure it as a required app during the Device ESP as shown below to make sure it will be installed before the user logs in!
When you wipe that same device again, you will notice the missing Microsoft.Services.Store.Engagement isn’t missing anymore! Isn’t that beautiful?
7. Solving it Option 2
In part 6, I showed you how to solve the Company Portal issue by configuring a new LOB app and uploading the APPX file. However, as I also mentioned, mixing LOB apps and Win32 Apps is not the best practice. I even got some feedback asking why I didn’t deploy this dependency app as a Win32 app.
I also tried to install the missing framework using a Win32App, but my first attempt failed. At that moment, I just wanted to create a working fix, but after the blog was released, I took a better look at why the Win32app solution was failing me.
It’s always best practice to use Psexec to ensure that you are testing your failing apps in the “local system” context. Let me tell you why! If you are adding WIn32Apps, you will probably configure the install behavior to “System” instead of “User.”
So, to make sure you are testing the app with the same variables, you will need to test it in the system account. I opened a new PowerShell session and started PowerShell in the system context. After entering the add-appxpackage command, as shown below, it’s pretty obvious why my first idea was failing me.
Adding a Store app in the system context by using the command: Add-AppxPackage is never going to work, simply because it’s not allowed! The add-appxpackage is used to add a signed app package to a USER ACCOUNT.
Luckily, there is still the DISM command I also used in my blog about ingesting an additional update in my Windows installation media.
I changed the PowerShell script a little bit and added this DISM command instead of the add-appxpackage command
DISM.exe /online /Add-ProvisionedAppxPackage /PackagePath:.\Microsoft.Services.Store.Engagement_10.0.19011.0_x64__8wekyb3d8bbwe.appx /SkipLicense
After changing the command line I recreated the IntuneWinapp and uploaded it to Intune. Please make sure when adding the app you are also configuring the detection rules as shown below
To be sure it was working I reinstalled my test device and executed the same steps to check out if the Company portal was working.
DAMN!!! As shown above, we just got ourselves the same 0x80073cfb error I was talking about in my older blog.
0x80073cfb error | Autopilot ESP | Windows 11 Build 25120 (call4cloud.nl)
I wasn’t expecting that because in that specific blog, the ESP time out while installing the offline Company Portal, but this time, it installs the Company Portal a little bit but not the way it should be installed.
If you have enough patience, that missing framework will be installed within 15 minutes. but if you don’t want to tell your customer to wait, just package all those Frameworks to be sure none of them are missing!
But looking at this solution, it’s almost as if you are packaging the REAL offline version of the Company App that I mentioned in this blog.
Company Portal | Intune | Offline (device) vs Online (user) (call4cloud.nl)
8. Take a look at the Wipe Itself
I decided to take another look at what could be causing the Company Store (Offline) to not respond after a Wipe. First, I made sure I put up a new VM with a clean installation of Windows 10 21h2 (April version)
Before logging in to start the Autopilot enrollment, I opened a PowerShell session to determine if the Company Portal had already been installed.
Of course, BEFORE your device will be enrolled with Autopilot the Microsoft.CompanyPortal App isn’t on the device. After the device finished the device phase in the ESP you will notice that the Microsoft.CompanyPortal has been installed
But what happens after wiping the device but before starting the Autopilot enrollment when you use the Offline version of the Company Portal App?
As shown above, the Microsoft Company App is still there!!!!! it’s not removed? It looks like when the App is still on the device, when enrolling the device with Autopilot, it just skips the installation! And because it skipped the installation, it also doesn’t install the other required dependencies!
Looking at the Push Button Reset Microsoft docs, it tells us that only “Preinstalled apps that got updated will be restored to their updated state.” But is the Microsoft Company Appn’t a preinstalled app?
Of course, I needed to test the same but this time with the Online version of the Company Portal App. Let me show you what happens with the Online version of the Company Portal after you wiped the device
As shown above, when using the online version of the Compay Portal, this Store App gets removed after a wipe, and it installs perfectly fine during Autopilot enrollment.
While looking at what was happening, I was curious if I could use the Push Button reset options to make sure the Microsoft.CompanyPortal app will be removed after the Wipe and just before showing us the OOBE screen
It almost looks familiar, right? I guess it does, because some time ago I stumbled upon that awful lingering user data in the Windows.old folder, and I/Microsoft fixed it by using the same Push Button reset features
Just like we noticed with the Online version when the Microsoft.CompanyPortal app isn’t on the device before the Autopilot enrollment, it will just install the Offline version of the Company Portal with all of its dependencies as shown below.
If you are interested in the PowerShell script. here is the download link
https://call4cloud.nl/wp-content/uploads/2022/06/RemoveCompanyPortalAfterWipe.zip
9. 2022-07 Preview Update
In one of my latest blogs, I showed you how you could end up with a time-out error 0x800705b4 when enrolling your device with Autopilot. As I mentioned, this was due to some faulty code in the 2022-07 preview update KB5015858.
Preparing your device for mobile management | 0x800705b4 (call4cloud.nl)
In that same blog, I was also mentioned the fact that I installed this update to determine if some other fix was also applied (even when it’s not in the release notes)
If you read the blog about the 0x800705b4 error , you could have noticed one picture I showed you.
As shown above, the AppxAlluserStore.dll was changed to a newer file version! I am not 100% sure if this has something to do with the issue I described above but it is certainly not a coincidence…right? As this DLL file contains some nice functions
After installing this preview update, it was finally possible to wipe and enroll my device with Autopilot. When the Autopilot enrollment was finished, I immediately opened the start menu to click on the Company Portal. Of course, I made sure all the fixes I mentioned above weren’t configured, and guess what happened! The Company Portal just opened!
Looking at the release notes, it looks like the reliability of a push-button reset was “Improved”
I am also very happy about the fact that this wonderful fix is also included in the latest Windows 2022-08 Update (KB5016629 and KB5016616)
Conclusion
As I told you in the blog, we are also experiencing some other issues with the Store Apps. The start menu wasn’t working, and OneDrive couldn’t connect anymore.
While writing that blog (which still needs work) I learned a lot and with that knowledge troubleshoot the missing Microsoft.Services.Store.Engagement_ was a piece of cake
We got hit by this too. Seemed like it was something transient on MS’s end … after a while, removing the broken Company Portal app (Remove-AppxProvisionedPackage/DISM) and letting policy re-install it again started working as expected (didn’t need to install the engagement framework separately).
MS Support wasn’t able to give us a root cause.
Hi removing the company portal and waiting for it to be reinstalled is indeed also a good option… but normally you want it to be fixed automatically.
Excellent article. We too have this issue. Deploying the missing dependency appx package resolved this and users can launch Company Portal right away. For the missing dependency app deployed as win32 app, I used a generic part of the dependency name (not version) so future updates wont be affected by the package. Here is the detection script if it will help anyone.
$MSStoreEngagementApp = (Get-AppxPackage -Name *Microsoft.Services.Store.Engagement* -AllUsers)
if ($MSStoreEngagementApp) {
Write-Output “DETECTED”
exit 0
}
else {
Write-Output “NOT DETECTED”
exit 1
}
Hello and thanks a lot for writing this blog.
This article helped me a lot for deploying my appx files to production.
I’m running an issue now is that I can’t update the appx version on the computer. I deployed a powershell script with the same command you mentioned and the appx file, packaged everything in intunewin file and deployed a win32 app on Intune.
when I run the command to check current installation of the appx:
PS C:\Program Files\WindowsApps> Get-AppxPackage -AllUsers | Where-Object -FilterScript {$_.Name -like ‘Microsoft.MSPaint’}
I got the new appx I’ve deployed which is “Microsoft.MSPaint_6.2203.1037.0_x64__8wekyb3d8bbwe” and the old one. Is there any way to get rid of that old version and keep only the version I deployed (the updated one):
Name : Microsoft.MSPaint
Publisher : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture : X64
ResourceId :
Version : 6.1907.29027.0
PackageFullName : Microsoft.MSPaint_6.1907.29027.0_x64__8wekyb3d8bbwe
InstallLocation : C:\Program Files\WindowsApps\Microsoft.MSPaint_6.1907.29027.0_x64__8wekyb3d8bbwe
IsFramework : False
PackageFamilyName : Microsoft.MSPaint_8wekyb3d8bbwe
PublisherId : 8wekyb3d8bbwe
PackageUserInformation : {S-1-5-21-912588002-3793939173-3178407553-3718 [Domain\******]: Installed,
S-1-5-21-912588002-3793939173-3178407553-16407 [Domain\******]: Installed,
S-1-5-21-912588002-3793939173-3178407553-16415 [Domain\******]: Installed,
S-1-5-21-912588002-3793939173-3178407553-12582 [Domain\******]: Installed…}
IsResourcePackage : False
IsBundle : False
IsDevelopmentMode : False
NonRemovable : False
IsPartiallyStaged : False
SignatureKind : Store
Status : Ok
Name : Microsoft.MSPaint
Publisher : CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Architecture : X64
ResourceId :
Version : 6.2203.1037.0
PackageFullName : Microsoft.MSPaint_6.2203.1037.0_x64__8wekyb3d8bbwe
InstallLocation : C:\Program Files\WindowsApps\Microsoft.MSPaint_6.2203.1037.0_x64__8wekyb3d8bbwe
IsFramework : False
PackageFamilyName : Microsoft.MSPaint_8wekyb3d8bbwe
PublisherId : 8wekyb3d8bbwe
PackageUserInformation : {S-1-5-21-912588002-3793939173-3178407553-16128 [Domain\******]: Installed}
IsResourcePackage : False
IsBundle : False
IsDevelopmentMode : False
NonRemovable : False
IsPartiallyStaged : False
SignatureKind : Store
Status : Ok
Is this still an issue with the Company Portal from the new store? Wondering if I can remove my app.
Have you tested this recently with the new store version of the Company Portal?
This issue has resurfaced! and now under the new store. Logging a case to MS!
With which winget new store app did you tested it ? Also the new company portal or the old one? With which windows version?