4 modi per attivare o disattivare Microsoft Store su Windows 11 e 10

Su Windows 10 e 11 Microsoft Store non è un blocco unico, ma il risultato di più componenti: app UWP, criteri di sistema, registro, servizi e provisioning. Se vuoi attivarlo o disattivarlo in modo pulito, la domanda giusta non è “come lo spengo?”, ma “a quale livello voglio intervenire e con quale impatto?”.

In pratica hai quattro strade sensate: criterio di gruppo, PowerShell per rimuovere o ripristinare il pacchetto, registro per limitare l’uso dello Store, e gestione del servizio/aggiornamenti per ridurre la superficie operativa senza toccare tutto il resto. La scelta dipende dal contesto: PC aziendale, macchina condivisa, laboratorio, endpoint di produzione o semplice troubleshooting.

Quando conviene disattivare Microsoft Store

Disattivare lo Store ha senso quando vuoi controllare meglio cosa viene installato, ridurre la possibilità che gli utenti aggiungano app non autorizzate, oppure evitare che un endpoint critico scarichi aggiornamenti in momenti sbagliati. È una misura di governance, non una cura universale.

Va anche detto il contrario: su molti sistemi lo Store serve per aggiornare componenti moderni, app di sistema e pacchetti distribuiti in formato AppX/MSIX. Spegnerlo “a martello” può creare effetti collaterali, soprattutto se l’ambiente usa app aziendali distribuite tramite Store o dipende da aggiornamenti automatici di alcune applicazioni Microsoft.

Regola pratica: se il requisito è impedire agli utenti di installare app, il primo tentativo dovrebbe essere un criterio restrittivo; se il requisito è rimuovere davvero il pacchetto, serve un approccio più aggressivo e quindi più reversibile solo con attenzione.

1) Disattivare Microsoft Store con Criteri di gruppo

È il metodo più pulito in ambienti Pro, Enterprise e Education. Non elimina l’app: la rende inaccessibile secondo la policy impostata. È la scelta giusta quando vuoi applicare una regola centralizzata e facilmente reversibile.

Il percorso classico è questo: apri l’Editor Criteri di gruppo locali e cerca l’impostazione dedicata allo Store. Il nome può variare leggermente con la versione, ma il concetto resta lo stesso: impedire l’accesso all’app Store e alle installazioni da Store.

Se lavori da console, il punto di partenza è:

gpedit.msc

Il ramo da controllare è in genere sotto Configurazione computer → Modelli amministrativi → Componenti di Windows → Store. L’impostazione più rilevante è quella che disattiva l’app Store. Dopo la modifica, forza l’aggiornamento criteri con:

gpupdate /force

Verifica l’effetto aprendo Microsoft Store: in caso di blocco corretto, l’app non deve consentire l’uso normale oppure mostrare un messaggio coerente con il divieto imposto. Se invece vuoi ripristinarlo, basta riportare il criterio su “Non configurato” o “Disabilitato”, quindi rieseguire gpupdate /force.

Questo approccio ha blast radius contenuto: colpisce soprattutto l’accesso allo Store, non il resto del sistema. Il rollback è semplice e non richiede rimozioni manuali. In ambienti con dominio, però, la policy locale può essere sovrascritta da quella di dominio: prima di intervenire, controlla quale GPO sta vincendo con gpresult /h report.html.

2) Rimuovere o ripristinare Microsoft Store con PowerShell

Se vuoi andare oltre la semplice disattivazione logica e intervenire sul pacchetto, PowerShell è la via più diretta. È anche quella con più rischio operativo, perché rimuovere il pacchetto può avere impatti su aggiornamenti e dipendenze di app moderne.

Per capire se Store è presente per l’utente corrente o come provisioning, usa questi controlli:

Get-AppxPackage Microsoft.WindowsStore
Get-AppxProvisionedPackage -Online | Where-Object DisplayName -like '*WindowsStore*'

Se il pacchetto esiste solo per l’utente corrente, la rimozione è più semplice. Se invece è provisioned, significa che può tornare su nuovi profili o dopo alcune operazioni di ripristino del sistema. In quel caso, la rimozione va considerata temporanea e non “definitiva”.

Per rimuovere Microsoft Store dal profilo corrente:

Get-AppxPackage Microsoft.WindowsStore | Remove-AppxPackage

Per rimuovere il provisioning da un sistema dove sia presente:

Get-AppxProvisionedPackage -Online | Where-Object DisplayName -like '*WindowsStore*' | Remove-AppxProvisionedPackage -Online

Il ripristino, quando possibile, passa spesso dal re-register del pacchetto o da un nuovo provisioning. Un comando utile per tentare la registrazione di una app AppX già presente sul disco è:

Get-AppxPackage -AllUsers Microsoft.WindowsStore | ForEach-Object { Add-AppxPackage -DisableDevelopmentMode -Register "$($_.InstallLocation)\AppXManifest.xml" }

Qui il punto non è solo tecnico ma operativo: prima di rimuovere, valuta se l’endpoint usa altre app distribuite via Store o aggiornate tramite componenti correlati. Il blast radius può includere anche app già installate che si aspettano il runtime e i servizi di supporto. Il rollback è possibile, ma non sempre banale come un toggle di policy.

Se vuoi fare change controllato, conviene salvare lo stato iniziale con l’elenco dei pacchetti prima di toccare nulla:

Get-AppxPackage Microsoft.WindowsStore | Select Name, PackageFullName, InstallLocation
Get-AppxProvisionedPackage -Online | Select DisplayName, PackageName

3) Bloccare l’uso di Microsoft Store dal Registro di sistema

Il registro è utile quando non hai gpedit disponibile, per esempio su Windows Home, oppure quando devi applicare una limitazione puntuale e documentabile. Anche qui il principio è bloccare il comportamento, non per forza rimuovere il componente.

La chiave da verificare è normalmente sotto HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WindowsStore. Il valore più noto è RemoveWindowsStore, che può essere impostato a 1 per disabilitare l’uso dello Store e a 0 per tornare alla condizione precedente, se non esistono altre policy più forti.

Da prompt amministrativo, il controllo rapido è:

reg query "HKLM\SOFTWARE\Policies\Microsoft\WindowsStore" /v RemoveWindowsStore

Per impostarlo su 1:

reg add "HKLM\SOFTWARE\Policies\Microsoft\WindowsStore" /v RemoveWindowsStore /t REG_DWORD /d 1 /f

Per ripristinarlo:

reg add "HKLM\SOFTWARE\Policies\Microsoft\WindowsStore" /v RemoveWindowsStore /t REG_DWORD /d 0 /f

Se vuoi evitare errori manuali, meglio esportare la chiave prima della modifica:

reg export "HKLM\SOFTWARE\Policies\Microsoft\WindowsStore" "%USERPROFILE%\Desktop\WindowsStore-backup.reg"

Il vantaggio del registro è la semplicità, il limite è che non sempre copre tutti gli scenari di controllo in modo robusto come una policy. In pratica: su una macchina singola funziona bene; in un parco macchine, è meglio portarlo in GPO o in uno strumento di gestione centralizzata.

4) Limitare Microsoft Store tramite servizio, aggiornamenti e contesto operativo

Questa è la strada meno “pulita” ma in certi casi la più utile: non stai disattivando Store in senso stretto, stai riducendo il suo ruolo operativo. È il caso tipico di PC da chiosco, postazioni bloccate o ambienti dove vuoi evitare traffico e aggiornamenti non necessari senza rompere il resto.

Il primo controllo è capire se il problema è davvero Store oppure il servizio di supporto, la rete o il profilo utente. Se Store non si apre, verifica almeno questi punti: data/ora corretta, accesso a internet, DNS funzionante, account Microsoft o aziendale valido, e assenza di blocchi da proxy o firewall.

Per osservare rapidamente lo stato dell’ecosistema app, puoi controllare i servizi correlati e i log applicativi. Un comando utile è:

Get-Service | Where-Object {$_.Name -like '*Clip*' -or $_.Name -like '*AppXSvc*' -or $_.Name -like '*Install*'}

Se il tuo obiettivo è limitare gli aggiornamenti, attenzione: disabilitare servizi a caso per “spegnere Store” spesso crea un problema più ampio del beneficio ottenuto. Meglio agire con policy di aggiornamento, con controllo delle app consentite o con gestione del traffico verso i domini Microsoft necessari, se davvero il caso d’uso lo richiede.

In alcuni scenari di supporto, la soluzione non è disattivare ma riparare il pacchetto. Per esempio, se Store è corrotto dopo un update, prima di qualunque rimozione aggressiva prova a reimpostarlo dalle impostazioni app oppure a registrarlo di nuovo. La sequenza ordinata è: osserva, ripara, solo dopo rimuovi. Questo evita di confondere un guasto con una policy.

Quale metodo scegliere davvero

Se devi amministrare un parco macchine, la risposta è quasi sempre: policy di gruppo o gestione centralizzata. Se devi lavorare su una singola macchina e vuoi un rollback semplice, il registro è una via rapida. Se devi rimuovere il componente per ragioni forti di controllo o hardening, PowerShell è la leva giusta, ma va usata con più disciplina.

Per capire il livello giusto, fai questa distinzione:

• Bloccare l’uso: GPO o registro.
• Rimuovere dal profilo corrente: PowerShell con Remove-AppxPackage.
• Impedire il ritorno su nuovi profili: rimozione del provisioning.
• Mitigare senza rompere il sistema: policy di accesso, rete e aggiornamenti.

In un contesto enterprise, la differenza tra “disattivare” e “rimuovere” conta molto. Disattivare è reversibile e più adatto a test o ambienti condivisi. Rimuovere è più invasivo e va trattato come change, con finestra, verifica e piano di rollback. Se manca un requisito scritto, non indovinare: chiarisci se l’obiettivo è compliance, riduzione del rischio o semplice blocco operativo.

Verifiche dopo la modifica

Dopo qualsiasi intervento, controlla sempre tre cose: che il comportamento sia quello atteso, che il rollback sia possibile, e che non siano state toccate altre app collegate. La verifica minima può essere fatta così:

winget --version
Get-AppxPackage Microsoft.WindowsStore
reg query "HKLM\SOFTWARE\Policies\Microsoft\WindowsStore" /v RemoveWindowsStore

Se winget è usato nel tuo ambiente, considera che alcune installazioni dipendono proprio dalla presenza di Store o dei suoi componenti. Se il comando fallisce dopo aver bloccato Store, non dare per scontato che il problema sia “winget rotto”: potrebbe essere l’effetto previsto della tua scelta di hardening.

Un buon rollback non è un ripristino improvvisato. Tieni sempre a portata: esportazione della chiave di registro, elenco del pacchetto AppX prima della rimozione, e nota della policy applicata. Senza questi tre elementi, il ritorno indietro diventa una ricostruzione a memoria, che in produzione è il modo migliore per perdere tempo.

Errore comune: confondere Store con le app Microsoft preinstallate

Molti interventi falliscono perché si parte dall’idea sbagliata che Microsoft Store sia isolato. In realtà è legato a un ecosistema di app, runtime e componenti di distribuzione. Per questo una rimozione brutale può avere effetti indiretti: app che non si aggiornano più, pacchetti che non si ripristinano, profili nuovi che si comportano diversamente dai vecchi.

Se l’obiettivo è solo impedire agli utenti di installare software non autorizzato, spesso è più efficace intervenire su account, app consentite, repository aziendali e policy di esecuzione, invece di inseguire ogni singolo componente Microsoft. Lo Store è un vettore, non sempre la causa primaria del problema.

Scelta pratica in una riga

Per un blocco reversibile usa i criteri; per una restrizione rapida su singola macchina usa il registro; per una rimozione reale usa PowerShell; per ambienti gestiti, porta tutto in policy centralizzata e documenta il rollback prima del change.

Assunzione: il sistema è Windows 10 o 11 con privilegi amministrativi disponibili e senza vincoli MDM che sovrascrivano localmente le impostazioni.