Managing the Microsoft Store and Apps with AppLocker

From a business IT point of view, at the moment we’re a bit stuck when it comes to the Microsoft Store.

You hate it because it allows users to install all kinds of rubbish and unwanted apps onto their PCs, but you can’t block it because it’s increasingly being used to deliver not just the GUI front end for apps and utils that you rarely need (e.g. fiddling with the WiFi settings) but also entire drivers that you can’t get from anywhere else (e.g. Waves MaxxAudio).

And you can’t use the Windows Store for Business on Windows 11. At all. The way I’m currently managing this, until Microsoft makes the situation better, is to use the Packaged app rules in AppLocker.

Now, to use AppLocker you need to be running an Enterprise (or Education) edition of Windows, so if you’ve got a 365 E3 or E5 licence you’re probably good to go.

Pro Tip

Make sure you’ve excluded the Universal Store Service APIs and Web Application (45a330b1-b1ec-4cc1-9161-9f03992aa49f) from any Conditional Access Policy that enforces MFA for your users, or Windows won’t reliably upgrade to from Professional edition to Enterprise. Check your Azure AD Sign-Ins logs for failures in the User sign-ins (non-interactive) category to verify this is all working properly. The Application name to look out for is called Universal Store Native Client (and hilariously, even though it’s not supported on Win11 and is being dropped for Win10, the Resource name is Windows Store for Business!).

AppLocker Rules

The problem with using AppLocker to manage modern apps (or packaged apps, or whatever you want to call them) is twofold:

1. It’s hard to do without a machine that you’re not applying the AppLocker policy to. The Group Policy Management MMC requires you either pick an already-installed app, or provide the .appx (or .msix) app installer file.

2. On Windows 11, increasingly core parts of the OS are being replaced with these apps, e.g. the Start Menu. This causes big problems if AppLocker ends up blocking those – and you often won’t know that something has changed until it’s too late.

Initially my approach was to just build a machine without AppLocker applied to it, add a rule for every app, and then keep an eye out for Event ID 8025 being logged to see what new apps were being blocked. But because of point 2 above, I am now using the following wildcard rule:

Unsurprisingly (sadly) Microsoft has not been consistent in signing core bits of the OS with the Microsoft Windows publisher, and you probably don’t want to allow everything signed by Microsoft Corporation because that’ll open up a whole load of unwanted stuff from the Store that your users could install. So you’ll still need to add some other specific rules that fall outside of the patterns above, and you’ll need the machine from point 1 above to do that from, just do that using the option to create a new rule using an installed packaged app as a reference.

You also need to keep an eye out for the following:

Annoyingly, AppLocker publisher rules don’t allow you to mix a wildcard with any other text. So you just need to monitor the stuff AppLocker is blocking and add individual rules for the two above when you see stuff pop up.