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.
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:
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 GPO to block the store.