Orphaned Start Menu Apps Workaround

Hey community, this is Helmut Wagensonner, a Customer Engineer for Windows Client platform. Today I want to provide you a workaround for an issue I ran into a couple of times now at my customers. Please note that at the date of writing the product group and engineers are investigating the root cause and probably there will be a fix. But for now…

Let's have a look into some details. It appears that built-in Microsoft start menu apps, also known as start apps or inbox apps, show up as orphaned links after upgrading the OS to Windows 10 1909 (and probably also newer versions). The following image shows an example.


We've seen this happening in combination with a blocked Windows Store or blocked inbox apps. In some cases, the apps start to heal themselves after a short while. However, we've also seen cases where ms-resource items remain.

It appears that apps showing orphaned links do not have the InstallLocation property set anymore. You can check this by running the Powershell command

Get-AppxPackage | Select Name,InstallLocation

from a Powershell window in the user's context. So re-registering the apps for each user could solve the problem. That's why engineers working on this topic came up with a workaround, which helped my customers to get the apps fixed. Following Powershell command can be used to repair the start menu:

Get-AppxPackage | % { if (!($_.InstallLocation) -and !($_.IsFramework)) { Add-AppxPackage -RegisterByFamilyName -MainPackage $_.PackageFamilyName }}

Credits go to Raul Martinez (raulm@microsoft.com) and David Bennet (dbenne@microsoft.com) for creating and fine-tuning this one-liner.

The command needs to run in the context of the user (i.e. logon script). It retrieves a list of all modern apps installed/registered by the user. If the app is not part of the UWP framework and if its InstallLocation property is empty, it get re-registered for the executing user account.

Experiences show that blocking the Windows Store using Applocker can advance the erroneous behavior. Consider one of those GPOs to prevent users from downloading apps from the public store: https://gpsearch.azurewebsites.net/#8215 or https://gpsearch.azurewebsites.net/#13794. Latter is recommended when a private store is available. However, we've also seen the orphaned inbox apps issue on clients, which were using the mentioned to block the store.

I assume this will be fixed soon but we do not have an ETA yet. I will update this post as soon as we have new information.

Thanks for reading and stay healthy!




This article was originally published by Microsoft's ITOps Talk Blog. You can find the original article here.