Come rimuovere le app Microsoft Store preinstallate con Microsoft Intune

Simone Termine

Introduzione

In molti ambienti aziendali, una delle richieste più frequenti quando si definisce uno standard Windows è quello di avere un sistema più pulito, con meno app consumer e un’esperienza utente più in linea con quello che l’azienda vuole mettere a disposizione. Fino a oggi, per ottenere questo risultato si è spesso passati da script PowerShell, immagini custom distribuite tramite task sequence SCCM o MDT, oppure ancora attività di post-configurazione che bisogna però mantenere nel tempo. Con Windows 11, versione 25H2, arriva invece una modalità nativa in Microsoft Intune per rimuovere un set definito di app Microsoft Store preinstallate. Questa policy del Settings Catalog lavora a livello dispositivo, quindi va progettata come configurazione del computer e non come impostazione legata al singolo utente. In questo articolo vedremo quindi come funziona questa impostazione, come configurarla in Microsoft Intune e quali verifiche conviene fare lato client per capire se il comportamento del device è davvero quello atteso. Vedremo anche i limiti da tenere presenti e i punti a cui prestare attenzione prima di estendere la configurazione su larga scala.

Cosa cambia rispetto ai metodi usati finora

La differenza principale è che qui non stiamo parlando di una normale disinstallazione lanciata manualmente su una singola app. Con questa policy si definisce invece un elenco di app Microsoft Store preinstallate che Windows deve rimuovere dal dispositivo quando la configurazione entra in gioco. Il comportamento, quindi, è diverso da un classico uninstall perché è una gestione nativa del sistema, pensata per lavorare sul provisioning del device e sui successivi accessi utente.

Questo approccio è utile anche dal punto di vista operativo, perché riduce la dipendenza da script PowerShell o da logiche personalizzate che nel tempo diventano più difficili da mantenere. Inoltre, finché un’app resta selezionata nella policy, Windows ne blocca la reinstallazione. Questo significa che non solo l’app viene rimossa, ma che il sistema continua anche a impedirne il ripristino tramite Microsoft Store o sideloading finché la configurazione resta attiva.

Negli ambienti on-premises o ibridi, questo aspetto è ancora più interessante. Come citato nell’introduzione, in passato per ottenere un risultato simile si passava spesso da task sequence SCCM, MDT, script PowerShell o altre personalizzazioni inserite nel processo di deployment. Con questa impostazione nativa disponibile in Intune, invece, la gestione diventa più lineare e molto più pulita, perché non richiede logiche custom dedicate solo alla rimozione delle app inbox. Questo non significa che sostituisca ogni scenario di personalizzazione del sistema operativo, ma per i casi supportati consente di ottenere lo stesso risultato in modo più ordinato e con meno manutenzione nel tempo.

Edizioni supportate, requisiti e limiti

Prima di passare alla demo su Microsoft Intune conviene fissare bene il perimetro di applicazione di queste impostazioni. La funzionalità è supportata solo su Windows 11 versione 25H2 o successiva, e solamente per le edizioni Enterprise e Education. Per il canale Intune il dispositivo deve essere MDM enrolled. Gli ambienti multi-session non sono supportati.

C’è poi un altro punto da non perdere di vista: la policy lavora a livello dispositivo. Questo significa che, se abilitate la rimozione di una determinata app, quella scelta vale per tutti gli utenti che usano quel computer. Se avete device condivisi in cui alcuni utenti devono avere l’app e altri no, questa impostazione da sola non basta. Va considerato anche l’effetto sui dati locali. Quando l’app viene rimossa, vengono rimossi anche i dati su disco associati a quell’app. In uno scenario enterprise questo significa che, prima del rollout, conviene avvisare gli utenti o validare bene il comportamento nel pilota, soprattutto se state toccando app che potrebbero contenere dati locali non sincronizzati.

Quali app si possono rimuovere

Allo stato attuale, la policy non consente di scegliere liberamente la disinstallazione di qualsiasi app installata nel sistema, ma funziona solo su un elenco definito di app Microsoft Store preinstallate. Questa funzione è molto utile ma non nasce come soluzione generica di debloating, copre solo i pacchetti previsti dalla policy RemoveDefaultMicrosoftStorePackages, e l’elenco può essere aggiornato da Microsoft nelle release future. Le app attualmente supportate sono quelle riportate nella tabella seguente, con il nome dell’app e il relativo ID usato nel payload CSP/XML:

Questo aspetto va tenuto presente anche in fase progettuale, perché se l’app che volete rimuovere non rientra tra quelle supportate dalla policy, dovrete necessariamente usare un altro approccio. In questo senso, la funzionalità è molto utile per i casi coperti nativamente da Windows, ma non sostituisce ogni esigenza di standardizzazione, rimozione applicativa o application governance su Windows 11. Microsoft può aggiornare nel tempo l’elenco delle app gestibili, quindi conviene tenere come riferimento la pagina ufficiale Enabling policy-based in-box app removal, in particolare la sezione CSP dedicata a RemoveDefaultMicrosoftStorePackages.

Come creare la policy via Intune

Passiamo ora alla parte operativa e vediamo, passo dopo passo, come creare la policy in Microsoft Intune per la rimozione delle app Microsoft Store preinstallate. Per iniziare, apriamo il Microsoft Intune admin center, andiamo in Devices e creiamo una nuova policy per Windows 10 and later, scegliendo Settings Catalog come tipo di profilo.

Nella sezione Basics assegniamo un nome alla policy, ad esempio “Remove Preinstalled Microsoft Store Apps”, inseriamo una descrizione se la riteniamo utile e poi clicchiamo su Next.

Nella sezione Configuration settings clicchiamo su Add settings e utilizziamo il Settings picker per cercare Microsoft Store packages oppure direttamente Remove default Microsoft Store packages from the system; il setting si trova nella categoria Administrative Templates\Windows Components\App Package Deployment. A questo punto, sulla sinistra, vedrete il setting Remove default Microsoft Store packages from the system che di default ha il toggle impostato su Disabled.

A questo punto abilitiamo il setting Remove default Microsoft Store packages from the system. Quando la policy è su Enabled, Intune mostra l’elenco delle app supportate. Per ogni app che vogliamo rimuovere impostiamo il toggle su True. Le app lasciate su False restano invece nel sistema. Qui conviene fare attenzione a due cose: la prima è che state lavorando su una logica di rimozione per device, quindi la selezione va costruita pensando allo standard del device e non alla preferenza del singolo utente. La seconda è che non serve partire con una lista lunga solo perché la policy lo consente. In un tenant enterprise ha più senso iniziare da poche app (chiaramente non necessarie), validarne il comportamento e poi allargare eventualmente il set.

Per un primo pilota ristretto, una selezione sensata può essere ad esempio Microsoft News, Microsoft Solitaire Collection, Microsoft Sticky Notes e, dove non serve, Xbox Gaming App. In ambienti più restrittivi si può ragionare anche su altre app, ma inizialmente è meglio togliere solo quello che ha davvero senso rimuovere nel vostro contesto. Terminata la configurazione, fare click su Next.

Nella sezione Scope tags (opzionale) possiamo lasciare il valore Default oppure selezionare uno scope tag già presente nel nostro ambiente Intune. Nel nostro caso lasciamo quello predefinito e proseguiamo cliccando su Next.

A questo punto, nella sezione Assignments, assegniamo la policy al gruppo desiderato, così da mantenere un controllo più preciso sulla distribuzione. Per assegnare la policy a un gruppo specifico, clicchiamo su Add groups, cerchiamo il gruppo desiderato, selezioniamolo tramite la relativa checkbox e infine clicchiamo su Select.

Nella stessa sezione Assignments verifichiamo che il gruppo selezionato sia stato aggiunto correttamente all’elenco Included groups. Se necessario, possiamo ancora aggiungere altri gruppi o applicare eventuali filtri; altrimenti proseguiamo cliccando nuovamente su Next.

Nella sezione Review + create controlliamo che tutti i dettagli della policy siano corretti, compresi i gruppi di assegnazione. Se non ci sono modifiche da apportare, clicchiamo su Create.

Dopo pochi istanti la policy sarà disponibile in Intune e pronta per la distribuzione secondo le assegnazioni configurate.

Cosa succede lato client dopo la distribuzione

Su questo punto conviene fermarsi un attimo, perché nei test iniziali è facile interpretare male il comportamento della policy. Quando il profilo arriva sul device, l’app non viene necessariamente rimossa subito nella sessione utente già aperta. La logica prevista da Windows è diversa, infatti la rimozione entra in gioco:

• durante l’OOBE
• al primo accesso successivo a un upgrade del sistema operativo
• al primo accesso successivo a una modifica della policy

In altre parole, se il dispositivo ha già ricevuto il profilo ma l’utente è ancora nella stessa sessione, potete continuare a vedere l’app finché non viene effettuato un nuovo sign-out/sign-in.

Questa distinzione è importante anche quando fate le verifiche sui dispositivi. Dire dopo pochi secondi che la policy è arrivata ma l’app è ancora presente non basta per concludere che qualcosa non stia funzionando. Prima va verificato che il device abbia effettivamente recepito la configurazione, poi va controllato il comportamento nel momento giusto, cioè durante il provisioning del profilo utente oppure al successivo accesso. Per i profili già esistenti, infatti, Windows non forza una rimozione immediata nella sessione in corso.

Lo stesso ragionamento vale anche in scenari Autopilot. Se la policy rientra tra i profili distribuiti al device e l’Enrollment Status Page è configurata per bloccare l’uso del computer finché la configurazione non è completata, la rimozione può avvenire già in fase di setup e l’utente può arrivare al desktop con un ambiente più pulito. Se invece la policy non viene ricevuta in tempo durante quella fase, alcune app possono ancora comparire al primo accesso e sparire solo in un secondo momento, al logon successivo

Troubleshooting

Quando iniziate a fare troubleshooting, conviene partire da Intune e non dal client. Il primo passaggio è verificare se la policy risulta distribuita correttamente, se ci sono errori o conflitti e se il device rientra nel perimetro supportato. Solo dopo ha senso passare ai controlli locali, per confermare che il profilo sia stato recepito e verificare nel dettaglio la rimozione delle app. In questo modo evitate di cercare il problema nel punto sbagliato e arrivate più rapidamente alla causa reale.

Monitoring in Microsoft Intune

Dal lato Intune apriamo la policy appena creata e andiamo nella vista di monitoraggio del profilo. Il controllo più utile è Device status. Un dispositivo compatibile con Windows 11 25H2 o successivo dovrebbe mostrare esito positivo; se invece compare Not applicable (vedi Figura 1 al capitolo Edizioni supportate, requisiti e limiti), la prima cosa da verificare è quasi sempre la versione di Windows, l’edizione del sistema oppure la modalità di assegnazione. Se il profilo risulta distribuito ma sul client non vedete ancora il comportamento atteso, non saltate subito alla conclusione che la policy non funzioni. Come visto prima, il timing conta molto perché la rimozione non è immediata nella sessione in corso e può richiedere il successivo logon o una nuova profilazione del device.

Per controllare rapidamente se il profilo è stato applicato correttamente, apriamo il Microsoft Intune admin center e andiamo in Devices > Configuration, selezioniamo la policy interessata e facciamo clic su View report. Da qui possiamo verificare lo stato di applicazione, eventuali errori, conflitti e il dettaglio per singolo dispositivo.

A questo punto accediamo alla vista di monitoraggio della policy, da cui possiamo verificare lo stato dei dispositivi e degli utenti a cui è stata assegnata la configurazione di rimozione delle app del Microsoft Store preinstallate. Nel report troviamo il dettaglio del check-in, l’ultimo aggiornamento ricevuto dal dispositivo e gli eventuali stati di errore o conflitto, informazioni utili per capire subito se il profilo è stato applicato correttamente oppure se richiede un’analisi più approfondita.

Infine, selezionando il dispositivo di interesse dal report, possiamo approfondire il dettaglio della distribuzione e verificare l’esito delle impostazioni applicate da quella specifica policy. Questo passaggio è utile per capire rapidamente se il profilo risulta distribuito correttamente sul singolo endpoint oppure se sono presenti errori, conflitti o stati pending che richiedono ulteriori verifiche.

Monitoring sul device

Vediamo adesso cosa succede sul nostro dispositivo pilota. In questo scenario, il riferimento più utile è il report MDM, perché raccoglie uno snapshot delle configurazioni e delle policy ricevute dal device ed è quindi molto più centrato, per una policy distribuita tramite Settings Catalog, rispetto a log pensati per altri workload. Per generarlo, apriamo le Impostazioni di Windows (ad esempio con Win + I) e andiamo in Account > Accesso all’azienda o all’istituto di istruzione.

Nella pagina che si apre, dalla sezione Impostazioni correlate facciamo clic su Esporta per generare il report diagnostico. Come indicato nella schermata, i file verranno salvati nel percorso C:\Users\Public\Documents\MDMDiagnostics, cartella utile per analizzare lo stato delle configurazioni MDM ricevute dal dispositivo.

Recandoci nel percorso C:\Users\Public\Documents\MDMDiagnostics, troviamo i file del report MDM appena generato.

Aprendo il report, possiamo cercare il riferimento ApplicationManagement per verificare che il dispositivo abbia ricevuto correttamente la configurazione distribuita tramite Intune. Volendo scendere più nel dettaglio, possiamo cercare anche le singole impostazioni RemoveDefaultMicrosoftStorePackages per controllare quali valori sono stati recepiti dal sistema.

Registro di sistema

Tra i primi controlli da fare lato client c’è anche il registro di sistema di Windows. Quando la policy viene recepita dal dispositivo, le impostazioni vengono scritte sotto il percorso HKLM\SOFTWARE\Policies\Microsoft\Windows\Appx\RemoveDefaultMicrosoftStorePackages. La presenza di questo ramo è già un primo riscontro utile per capire che il device abbia ricevuto correttamente la configurazione.

Nei test di laboratorio, all’interno della chiave è inoltre presente il valore Enabled, di tipo DWORD, impostato a 1. Questo può essere usato come ulteriore verifica rapida lato client. Va però tenuto presente che la presenza della chiave e dei relativi valori non dimostra da sola che l’app sia già stata rimossa nella sessione corrente, perché la rimozione effettiva segue il comportamento previsto dalla policy e può avvenire al provisioning del profilo oppure al successivo accesso dell’utente.

Se apriamo una delle sottochiavi relative alle app gestite dalla policy, possiamo trovare il valore RemovePackage, di tipo DWORD. Quando l’app è stata selezionata per la rimozione, il valore risulta impostato a 1; quando invece non è stata selezionata, il valore risulta 0. È un controllo utile per confrontare il comportamento del client con quanto configurato nella policy, soprattutto durante le verifiche iniziali o nel troubleshooting.

Come verifica aggiuntiva, è possibile controllare anche il ramo HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PolicyManager\current\device\ApplicationManagement, che consente di vedere le policy macchina registrate dal motore MDM. All’interno di questo percorso è possibile trovare anche il riferimento a RemoveDefaultMicrosoftStorePackages, con il payload ricevuto dal client. Questo controllo è utile soprattutto quando volete confermare che la configurazione sia stata scritta correttamente lato MDM, prima di passare alla verifica della rimozione effettiva delle app.

Event Viewer

Tra i controlli lato client, l’Event Viewer resta uno dei punti di riferimento più utili. Per capire se la policy è stata ricevuta correttamente dal dispositivo, conviene partire da Registri applicazioni e servizi > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin dove si possono intercettare errori, warning o eventi informativi legati alla gestione MDM della configurazione.

Per verificare, invece, la rimozione vera e propria delle app, un ulteriore percorso utile è Registri applicazioni e servizi > Microsoft > Windows > AppxDeployment-Server > Operational ed in particolare sono utili i seguenti eventi:

Verifica via PowerShell

Dal lato client potete fare un’ulteriore verifica anche con PowerShell, confrontando la presenza dei pacchetti prima e dopo il successivo accesso utente. Il comando di riferimento è il seguente:

Get-AppxPackage -AllUsers | Select Name, IsPartOfSystem

Questo controllo è utile per verificare se i pacchetti selezionati nella policy risultano ancora presenti sul dispositivo oppure se sono stati rimossi dopo l’applicazione della configurazione. Chiaramente va però letto per quello che è, quindi una vista generale dei pacchetti AppX installati per tutti gli utenti. Per questo motivo conviene usarlo come confronto prima e dopo oppure come verifica mirata sui pacchetti che state testando, affiancandolo agli altri riscontri lato client.

Nel caso mostrato in Figura 23, il comando viene eseguito in una console PowerShell con privilegi elevati e restituisce l’elenco dei pacchetti presenti sul sistema, permettendo di controllare rapidamente se le app oggetto della policy risultano ancora installate.

Errori frequenti

Nelle verifiche si può incorrere in alcuni errori piuttosto noti e ricorrenti. Il primo è l’assegnazione della policy a gruppi utenti invece che a gruppi di dispositivi. In questo caso il comportamento atteso non è quello corretto, perché si tratta di un’impostazione device-level e va gestita nel contesto macchina. Il secondo errore è tentare di usarla su sistemi non supportati, ad esempio dispositivi con Windows 11 Pro oppure con build precedenti alla versione 25H2 (vedi capitolo Edizioni supportate, requisiti e limiti). C’è poi un terzo aspetto che nei test genera facilmente confusione, quello di aspettarsi che l’app venga rimossa immediatamente nella stessa sessione in cui la policy viene ricevuta. Come abbiamo visto, la rimozione segue invece il timing previsto dalla funzionalità e può diventare effettiva al provisioning del profilo o al successivo accesso utente.

Un altro punto da evitare è la doppia gestione della stessa impostazione sullo stesso endpoint, ad esempio via Intune e via Group Policy in un ambiente ibrido. In questo scenario il risultato può diventare poco prevedibile, perché può prevalere l’ultima configurazione ricevuta dal device. Per questa policy conviene quindi scegliere un solo canale di gestione per ciascun computer. A tal proposito, potete recuperare l’articolo dedicato alla procedura da seguire via GPO alla pagina Come rimuovere le app Microsoft Store preinstallate via Group Policy – Endpoint Ninja. 

Va considerato anche lo scenario di reset, reinstallazione o nuova configurazione del dispositivo. Se il computer torna a uno stato iniziale e non riceve nuovamente la policy nelle prime fasi del provisioning, le app inbox possono ricomparire temporaneamente. Per questo motivo, se volete che l’utente trovi un’esperienza già pulita fin dal primo desktop, questa impostazione va pensata come parte del processo di enrollment e provisioning, non come intervento correttivo fatto solo dopo.

Come reinstallare un’app rimossa

Se dovete reinstallare un’app rimossa in precedenza, il primo punto da ricordare è che non ricompare automaticamente solo perché l’avete tolta dalla policy. Prima va aggiornato il profilo, portando il valore dell’app su False, poi va forzata la sincronizzazione del device così che Windows recepisca che quel pacchetto non è più bloccato. Solo dopo ha senso procedere con la reinstallazione tramite Microsoft Store o con un altro canale di distribuzione. In questo scenario, quindi, la policy smette di impedire l’installazione, ma non reinstalla da sola l’app sul dispositivo.

Conclusioni

La possibilità di rimuovere le app Microsoft Store preinstallate tramite Microsoft Intune è una delle novità più interessanti introdotte con Windows 11 25H2 per chi gestisce endpoint in ambito enterprise. Il motivo non è soltanto la pulizia del desktop o dello Start menu, ma il fatto che oggi esiste finalmente un metodo supportato per gestire queste app in modo più ordinato, senza dover dipendere ogni volta da script custom o procedure aggiuntive.

Per ottenere un risultato corretto, però, bisogna leggere bene il funzionamento della feature. Parliamo infatti di una policy device-based, supportata solo su specifiche edizioni e con un comportamento che segue il provisioning del dispositivo e il successivo accesso utente. Se questi aspetti vengono considerati fin dall’inizio, la configurazione può rientrare senza difficoltà nello standard Windows del tenant. Se invece la si prova come se fosse una normale disinstallazione immediata, il rischio è interpretare male i test e arrivare a conclusioni sbagliate sul suo funzionamento.