⚙️🪟💻CP - Security - Microsoft Store
Close the shop floor, keep the delivery entrance open. Users lose the Store app; app updates, Company Portal and Intune-delivered software carry on exactly as before.
What this policy is about 🛍️
The Microsoft Store on a managed device is a small hole in an otherwise controlled app estate. Not a dangerous one, usually. Just a door where users can install things that nobody approved, nobody inventoried and nobody will patch, and then be genuinely surprised when the thing they installed turns out to be a lookalike with a very convincing icon.
This policy removes the Store app from the user's reach. What it deliberately does not do is cut the pipe the Store service uses to keep the built-in apps updated, because that is the mistake almost everyone makes on the first attempt.
The Store is two things wearing one name: a shopfront users browse, and a delivery mechanism Windows uses to patch its own inbox apps. This policy shuts the first and leaves the second running. Confusing the two is how tenants end up with an estate of unpatched Photos, Notepad and Terminal installs.
Why this matters 🕵️
Unmanaged software is where the boring incidents come from. Not the sophisticated ones: the ordinary ones, where somebody installs a free PDF tool that comes with an ad injector, or a "companion app" that turns out to be a credential harvester with five-star reviews written by nobody. On an estate where the only way to get software is through Company Portal, that entire category of problem stops occurring.
It also makes the software inventory mean something. An MSP that can say "here is every application on this fleet, here is who approved it, here is how it patches" is doing something genuinely different from one that can say "here is everything we found last time we looked." Removing the self-service front door is what makes the first sentence true.
And it puts a request process where there was none. Users who want something now have to ask, which sounds like friction until you notice that most of them ask for something the customer already licenses, and the conversation ends with them getting a better tool than the one they were about to install. 🙂
🛠️ Configuration
Where: Intune admin center → Devices → Configuration → Create → Windows → Settings catalog → Administrative Templates → Windows Components → Store.
| Setting | Value |
|---|---|
| Turn off the Store application | Enabled |
| Turn off Automatic Download and Install of updates | Disabled |
| Disable all apps from Microsoft Store | Not configured |
| Assignment, include | 🛡️🪟💻⛓️Group - Windows Devices |
| Assignment, exclude | 🛡️🪟💻👈🔓⚙️Group - Microsoft Store Allowed |
Read the second row twice. Turn off Automatic Download and Install of updates set to Disabled means "do not turn updates off", which is to say: leave them on. It is a double negative in a settings catalog and it is the single most misread setting in this profile. Left unconfigured it usually behaves the same way, but stating it explicitly means the intent survives the next administrator who inherits this tenant.
Leave the third row alone. Disable all apps from Microsoft Store sounds like the thorough option and is a trap. It does not just block new installs, it stops the apps that ship with Windows from running: Photos, Calculator, Notepad, Terminal, Snipping Tool, Company Portal. The tickets arrive within the hour and they do not obviously point back to this profile. Never enable it.
Company Portal and Intune deployments keep working. Apps you push from Intune arrive through the management extension, not the Store shopfront, so the entire managed software catalogue is unaffected. Users lose browsing, not software.
Caveats ⚠️
This tattoos, hence the inverse. The setting writes to HKLM\Software\Policies\Microsoft\WindowsStore, and removing a device from this profile does not clear it. Exclusion stops enforcement; it does not restore the Store. Anything that genuinely needs the Store back must also receive ⚙️🪟💻🔓CP - Security - Microsoft Store - Allow, which writes the values back to their pre-policy state.
Store for Business is gone, and so is the setting that referenced it. Older baselines pointed at Only display the private store within the Microsoft Store, which curated a per-tenant shopfront. Microsoft retired Store for Business and Education, so that setting now configures something that no longer exists. If you find it in an inherited tenant, it is dead weight, not protection.
Some line-of-business software genuinely ships through the Store. A few vendors publish only as Store apps, and a few hardware utilities install their control panel that way, which is a common surprise on machines with certain audio, display or stylus hardware. That is what the exception group is for. Check before a rollout wave rather than after.
Windows 11 Pro is enough. Standard Intune configuration profile, no add-on, no Enterprise edition requirement.
👥 Assignment scope
Baseline for the whole Windows fleet. Kiosk and IoT builds are already restricted by their own shells and do not need separate handling here.
Membership of the exception group should be device-scoped and small, with a named reason per device. A device needing a Store-only vendor tool is a scenario; a user preferring the Store is not.
Worth verifying at tenant takeover: whether a previous administrator reached for Disable all apps from Microsoft Store. It is a quiet source of broken inbox apps and the symptoms rarely lead anyone back to a Store policy.
🔗 Related
- ⚙️🪟💻🔓CP - Security - Microsoft Store - Allow: the paired inverse that puts the Store back for the exception group.
- 🛡️🪟💻👈🔓⚙️Group - Microsoft Store Allowed: the exception group both policies hinge on.
- 🛒🧑💼OS - User-Owned Apps and Services: the tenant-side half of the same idea, one layer up.
Take away the shopfront, keep the loading dock. Users notice less than you expect, and your inventory finally tells the truth. 🛍️