In July 2021, Microsoft announced that both Microsoft Store for Business and Education would be deprecated on March 31, 2023. While Microsoft has pushed that date back indefinitely, the Intune integrations with both of those Stores started being removed on April 30, 2023, and will be completely shut down by September 15, 2023 (here). Of particular importance is that on June 15, 2023 Intune will stop enforcing Online and Offline apps. At that point Intune will cease to install or uninstall any existing Microsoft Store apps that that have been deployed using the Microsoft Store for Business or Microsoft Store for Education integrations.
What Do you Need To Do?
In short, you need to re-deploy all of your existing Microsoft Store for Business or Microsoft Store for Education apps. Hopefully you have already started that journey and are well on your way. If not, we’re … sorry.
The good news is that the actual applications themselves are unchanged, merely the delivery and control mechanism. Despite how Microsoft itself has discussed these changes earlier there is no ‘new’ Microsoft Store nor are their ‘new’ Microsoft Store apps. It’s the same Microsoft Store delivering the same Microsoft store apps. What has changed is how system administrators deliver a curated list of Microsoft store apps to your users via Intune.
One other caveat worth nothing here is that not all Microsoft Store apps are available via the new Intune Microsoft Store integration. According to the docs (here) an app may not be available if:
- The app is not available in your region
- The app is not available if there is an age restriction
- The app is a paid app, which is not supported
- The app is an Android app
- The app is a Microsoft Store for Business app that is not available publicly in the consumer store
- The app as an ARM64 installer
That Doesn’t Sound Too Bad. What’s the Catch?
Yea, for the most part it’s not too crazy. You need to re-deploy all existing Microsoft Store for Business or Microsoft Store for Education apps but as long as you deploy them the same way everything ‘should just work’.
So You’re Saying There’s a Catch?
Yea, of course I am. It’s called burying the lede … look it up.
There is one particular scenario where you can get into trouble. The deprecated Microsoft Store for Business or Microsoft Store for Education integration was built when the Microsoft Store only accepted Universal Windows Platform (UWP) apps that exclusive installed in the user context. That is, you could not install them system-wide but only on a user-by-user basis.
Now that the Microsoft Store supports Win32 apps installed via MSI or EXE the new Intune Microsoft Store integration allows you to deploy these applications in either the user or the system context.
Being able to install software in the system context so that it’s immediately available to all users of the device is an important feature for enterprise customers. This ability is crucial if you want to install the application during Autopilot. You can’t install applications to users before those users log into the device after all. Generally speaking, the prevailing wisdom is to not do so and wait for Intune to install applications to the user after they log in. There are some applications however where an indeterminate wait time for app availability might not be acceptable and you must install it system wide during Autopilot. One very common example here is the Customer Portal which is where users go to install apps in the first place. To wit, before the new Microsoft Store integration Microsoft recommended (docs) deploying Customer Portal as an Offline Store app so that it could be there immediately for the users after they log in.
Just. Tell. Me. What. The. Catch. Is. Already!
Migrating from user space Microsoft Store apps installed via the deprecated Microsoft Store for Business or Microsoft Store for Education to the same apps installed in the system context as supported by the new Intune Microsoft Store integration is just … horrible. Truly, truly horrible.
If you attempt to just install the same app in the system context to a user that already has it installed in user space it will fail miserably with ‘The application was not detect after installation complete successfully (0x87D1041C).
You might think to simply make an uninstall assignment for the legacy Microsoft Store app. As of this writing, that will only work for a few more days before Microsoft Intune stops enforcing those application on June 15th, 2023. Also note that this will only work if the user for every profile that exists on the device log into the device log into said device before that deadline. If a single one of those users hasn’t logged on then the legacy app will remain and the new system context app will fail to install with the ever-helpful ‘Unknown (0x00000000)’ error.
Is There Anything I Can Do?
Yes, but it’s not pretty. We’re still working on better solutions and will update this post with them but the goal is to uninstall a user-space app for all users from within the system context and coordinate that with the install of the new app in that same system context. Unfortunately, there’s nothing in Microsoft Intune that will do that for you. You will have to get creative.
Wait – we did a thing
We have put together a script that will address the issue outlined above.
The script can be pushed using the scripts feature from Intune, available from the Devices blade at https://intune.microsoft.com
As the Intune scripts feature does not accept parameters, the “Company Portal” app name has been tattooed in the script body. The $removeApp variable is the name of the AppxPackage that you wish to remove (Microsoft.CompanyPortal) and the $reinstallApp variable is the name of the app as it is installed using WinGet (Company Portal).
The script will look for any existing AppxPackages, for all users, and for the AppxProvisionedPackage for the Company Portal app and remove them. There are scenarios when the Company Portal app is installed by the user directly from the store which makes the uninstallation tricky without re-registering the app manifest. This script also handles that scenario. After they have been removed, the Company Portal app is installed via WinGet, in the scope of “machine”.
WARNING: Test the teeth out of this script before deploying it to production. The Author(s) take no responsibility for any damage caused by using this script in your environment.
Once the script has cleaned up the existing installs and deployed the Company Portal app via WinGet, in the machine scope, you should then see the Company Portal, deployed using the new store experience from Intune, in the SYSTEM context, detect as Installed.
The Intune Management Extension (IME) log will also indicate a successful detection of the Company Portal app too.
A log is also generated under
Summary
It is great that we can deploy apps from the Microsoft Store in the SYSTEM context. It will certainly help for the scenario already explained in this article, where you need the store app installed in the “Device Phase” during AutoPilot, for example.
The error reported in Intune for the scenario we mentioned in this post is annoying at worst but benign for the most part. There is no functionality loss when the error is reported – the chances are the Company Portal that was previously deployed, in Online mode from the legacy store, is working fine.
The script will help with this “bump in the road” in the reporting status and our expectation is you won’t need it going forwards.
