Last Updated on August 24, 2022 by rudyooms
This blog will be about some weird issues with some Microsoft Store apps when the device was wiped before handing it over to a new colleague. In this blog, I will use the Company Portal as the example app that will break
I will divide this blog into multiple parts
- The Wipe Issue
- What could be causing this?
- 2022-06 June Update
- Solving it Option 1
- Solving it Option 2
- Take a better look at the Wipe itself
- 2022-07 Preview Update
When an existing device is going to be handed over to a new colleague it’s always smart to ensure it’s wiped. In the past, there were a few issues with some lingering user data in the Windows.old folder but luckily that’s behind us now…
To make sure the device is wiped, you could 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 start installing some additional apps by using the Company Portal, some trouble started occurring!
2. The Wipe issue
After performing a remote Wipe/Reset you will notice that after logging the Company Portal isn’t responding when you click on it. Even when rebooting the device multiple times it doesn’t fix it!
I decided to record it in my own test environment because it can easily be 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
Almost as if the “Migrate AppX Provisioned Apps” is broken in the Push Button Reset functionality.
Could be right, as it has happened before?
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 was depending 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”
Some time ago I wrote a blog about the multiple options you have to deploy 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 over 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!
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.
Luckily with the June 2022-06 (KB5014699) update, the Store Fix is also included. No more store issues for us! Right?
But… But.. I already had the 19044.1766 build installed BEFORE I was resetting the device?
That’s weird as I was really expecting those stupid Store issues were 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 will be retired, it is still 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 is going to happen
After downloading that Appx file, I opened Intune and 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 but as also mentioned mixing LOB apps and Win32Apps is not the best practice. I even got some feedback asking why I didn’t deploy this dependency app as a win32 app.
As shown above, of course, I already tried to install the missing framework by 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 practise to use psexec to make sure 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.
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 was mentioning in this blog….
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 Autpillot enrollment I opened a PowerShell session to find out if the Company Portal was already 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 are making use of 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 is telling us that only “Preinstalled apps that got updated will be restored to their updated state” but the Microsoft Company App isn’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 does get removed after a Wipe and it installs perfectly fine during the 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
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
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. This was due to some faulty code in the 2022-07 preview update KB5015858 as I mentioned here
In that same blog, I was also mentioning 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)
As I was telling 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