• Cloud, Guide, Microsoft 365, Sistemi Operativi
• 6 Febbraio 2026

WinGet (Windows Package Manager) è entrato in modo silenzioso ma sempre più concreto nella gestione moderna dei dispositivi Windows. È il package manager con cui Microsoft sta spingendo verso una distribuzione e un aggiornamento applicativo più standardizzati e ripetibili, e oggi è frequentemente al centro di molte automazioni che, in azienda, riducono attività manuali e variabilità tra device.

Proprio perché WinGet può diventare un vero canale di installazione software non basta adottarlo, serve sapere dove risiede (App Installer), come garantirne la presenza sui client e, soprattutto, come governarlo. Parliamo di sorgenti abilitate, funzionalità consentite, possibilità di modifica lato utente e hardening. In ambienti reali, tra immagini custom, Microsoft Store limitato e dispositivi appena provisionati, non è scontato che App Installer (e quindi WinGet) sia sempre disponibile o configurato in modo uniforme.

Questo è il primo capitolo di una serie dedicata a WinGet. In questa prima parte restiamo nel perimetro cloud e modern management; vedremo come distribuire WinGet tramite App Installer e come gestirne la governance in modo granulare con Microsoft Intune.

In particolare, tratteremo:

• Cos’è WinGet
  
• Come distribuire WinGet con Microsoft Intune
  
• Come gestire WinGet in azienda
  
• End user experience
  
• Come rendere WinGet sicuro
  
• Considerazioni finali
  
• Conclusione
  

Nei prossimi articoli sposteremo invece il focus sugli scenari on-prem e ibridi, mostrando come governare WinGet tramite Group Policy e come gestirne la distribuzione con strumenti come Configuration Manager (SCCM). In un capitolo successivo entreremo nella parte più operativa: usare WinGet come motore di installazione e upgrade per app Win32 distribuite da Intune o per package gestiti via SCCM, con esempi pratici, logging, detection e troubleshooting.

L’obiettivo della serie è coprire gli scenari più comuni, sia cloud sia on-prem, partendo dalle fondamenta: prima rendere WinGet affidabile e governabile, poi passare all’automazione.

Cos’è WinGet

Partiamo dal principio. WinGet (Windows Package Manager) è il package manager di Microsoft per Windows: uno strumento a riga di comando che consente di cercare, installare, aggiornare e disinstallare applicazioni in modo automatizzato e ripetibile, evitando download manuali, click “Avanti” e inseguimento di versioni diverse macchina per macchina. Microsoft lo ha annunciato nel 2020, con l’idea di portare anche su Windows un’esperienza “da package manager” simile a quella disponibile da anni in altri ecosistemi (apt, yum, Homebrew), ma con un approccio integrabile anche in contesti enterprise.

WinGet nasce per ridurre una frizione storica della gestione software su Windows, spesso manuale e poco standardizzata: installer differenti per architetture o canali, opzioni di installazione silenziosa non uniformi tra vendor, meccanismi di aggiornamento eterogenei e, in generale, difficoltà nel mantenere coerenza tra ambienti diversi come postazioni IT, lab e VDI.

L’idea è semplice, dichiari cosa vuoi installare usando un identificatore univoco del pacchetto e WinGet si occupa del resto, selezionando l’installer appropriato e gestendo, quando possibile, anche l’upgrade in modo coerente. Pensiamo a situazioni del tipo:

• installer diversi per architetture e canali (x86/x64, stable/beta)
• switch di installazione silenziosa non uniformi tra vendor
• aggiornamenti gestiti in modi completamente differenti
• difficoltà nel mantenere coerenza tra ambienti (IT, lab, VDI, ecc.)

WinGet prova a risolvere tutto questo con un modello più consistente, dichiarando cosa voglio installare tramite un ID univoco e lo strumento si occupa del resto.

Come funziona?

WinGet lavora su pacchetti descritti da manifest, file in formato YAML che contengono i metadati necessari per installare e gestire un software: identificatore del pacchetto, versione, URL dell’installer, hash per la verifica di integrità, parametri di installazione, requisiti e così via. Quando lanci un comando del tipo:

Quello che fa WinGet, in sostanza, è:

• risolve il pacchetto interrogando la sorgente indicata e recupera il relativo manifest
• scarica l’installer previsto dal manifest (selezionando quello corretto in base ad architettura e regole dichiarate)
• verifica l’integrità confrontando l’hash dell’installer con quello dichiarato nel manifest
• avvia l’installazione passando, quando disponibili, i parametri non interattivi (silent) previsti dal manifest
• rileva ciò che è installato sul dispositivo e prova a correlare l’app al pacchetto, così da poter gestire in modo più coerente upgrade e versioning nel tempo

Figura 1: Esempio installazione Notepad++ tramite WinGet in modalità silent

Sorgenti e governance

Per impostazione predefinita, il client WinGet arriva con più origini già configurate. In particolare, troviamo la sorgente “winget” per le applicazioni, “msstore” per il catalogo Microsoft Store e “winget-font” per i font (questa, di norma, è impostata come “explicit“, quindi viene interrogata solo se la richiami esplicitamente). È utile chiarire un dettaglio: la sorgente “winget” non punta direttamente al repository GitHub, ma a un endpoint pubblicato da Microsoft; i manifest che descrivono i pacchetti, invece, sono mantenuti nella community repository winget-pkgs su GitHub, che alimenta la sorgente predefinita del Windows Package Manager.

Oltre alle origini di default, WinGet può lavorare con sorgenti aggiuntive, incluse sorgenti private basate su REST. Ed è qui che, in ambito enterprise, entra in gioco la governance: decidere quali sorgenti sono presenti e consentite, se alcune devono essere “explicit“, e quindi controllare in modo molto più granulare cosa è installabile e da dove.

Ed è esattamente il ponte con il tema di questo articolo. WinGet diventa particolarmente interessante quando lo usi come motore di installazione o upgrade, lasciando a Intune (o ad altri sistemi di gestione) assegnazioni, reporting, compliance e detection. In questo modo puoi ridurre la manutenzione del packaging, soprattutto per applicazioni che cambiano spesso, pur mantenendo il governo centrale del ciclo di vita. Potete trovare maggiori informazioni alla pagina WinGet-Cli – Microsoft GitHub.

Come distribuire WinGet (App Installer) sui dispositivi

WinGet non è un componente a sé, su Windows è incluso nel pacchetto App Installer (Microsoft.DesktopAppInstaller). Su Windows 11 e sulle versioni moderne di Windows 10, App Installer è un system component che viene distribuito e aggiornato tramite Microsoft Store, oppure tramite Windows Update nel caso specifico di Windows Server 2025.

Qui arriviamo al punto pratico: in molti ambienti WinGet c’è già, ma non sempre è immediatamente utilizzabile (soprattutto in provisioning/Autopilot o su immagini custom). Microsoft segnala infatti che WinGet potrebbe non essere disponibile finché non avviene il primo accesso utente, perché la registrazione avviene in modo asincrono tramite Store. In ambienti nei quali le immagini dei sistemi vengono create in modo custom, WinGet potrebbe non essere presente.

Verificare se WinGet/App Installer è già presente

Prima di distribuire qualsiasi cosa, conviene fare un check rapido a campione su alcuni device. L’obiettivo è capire se App Installer è installato (e con quale versione) e se il client WinGet è effettivamente disponibile e configurato.

• Verifica versione di App Installer
  
  PowerShell

  1 2	(Get-AppxPackage Microsoft.DesktopAppInstaller).Version

• Verifica informazioni di WinGet per dettagli e policy
  
  PowerShell

  1 2	winget --info

Importante: Get-AppxPackage senza -AllUsers ti mostra solo i pacchetti dell’utente corrente. In contesti enterprise può trarre in inganno, soprattutto se stai verificando da un account admin diverso dall’utente proprietario del pc. Il comando winget –info invece è un ottimo sanity check perché conferma anche che l’eseguibile è raggiungibile nel PATH e ti dà visibilità su sorgenti e impostazioni effettive.

Figura 2: Informazioni WinGet con winget –info

Metodo consigliato: Microsoft Store (gestito da Intune)

Se nel tenant e sui client l’accesso ai servizi del Microsoft Store è consentito, il percorso più lineare per garantire WinGet è distribuire App Installer tramite l’esperienza Microsoft Store app (new) in Intune. In questo modo vi limiterete a mettere sotto gestione il componente che porta WinGet sul client e delegate al Microsoft Store il suo aggiornamento nel tempo, senza dover rimpacchettare periodicamente l’app o rincorrere versioni diverse tra macchine. Di seguito vediamo i passaggi fondamentali:

Per prima cosa, colleghiamoci al Microsoft Intune Admin Center e navighiamo in Apps > Windows

Figura 3: Distribuire WinGet con Microsoft Intune – Parte 1

A questo punto fate click su Create e, all’apparizione della finestra sulla destra dello schermo selezionare Microsoft Store app (new) come App type; infine, fare click su Select

Figura 4: Distribuire WinGet con Microsoft Intune – Parte 2

Nella sezione App Information facciamo click sul link “Search the Microsoft Store app (new)“. Sulla destra apparirà la sezione da cui poter cercare e selezionare l’app desiderata. Uno dei drammi di Intune, ahimé, è che non sempre la ricerca funziona come dovrebbe. Cercando App Installer potrebbe non apparirvi nulla. Per essere più precisi vi suggerisco di effettuare sempre la ricerca per Package identifier; nel nostro caso è 9NBLGGH4NNS1. A questo punto apparirà l’app App Installer, selezioniamola e procediamo facendo click su Select

Figura 5: Distribuire WinGet con Microsoft Intune – Parte 3

A questo punto, nella stessa sezione, appariranno le informazioni dell’app già precompilate e i settaggi dell’installazione. Per il campo Install behavior
vi suggerisco di mettere System. Se volete, potete aggiungere un logo, modificare il nome dell’app o la sua descrizione predefinita. Quando avrete terminato, fare click su Next

Figura 6: Distribuire WinGet con Microsoft Intune – Parte 4

A questo punto, nella pagina Assignments, possiamo assegnare la nostra app al gruppo desiderato. Nella nostra demo renderemo l’applicazione required, quindi fare click su Add groups nella sezione Required, cercare il gruppo desiderato, selezionarlo con l’apposita checkbox ed infine fare click su Select.

Figura 7: Distribuire WinGet con Microsoft Intune – Parte 5

Sempre nella pagina di Assignments verifichiamo che il gruppo selezionato sia stato aggiunto alla lista dei gruppi per il deploy required. Per questa demo non abbiamo bisogno di aggiungere filtri, modificare i metodi di notifica e la deadline del deploy, quindi continuare cliccando nuovamente su Next.

Figura 8: Distribuire WinGet con Microsoft Intune – Parte 6

Nella pagina Review + create controlliamo nuovamente la correttezza di tutte le informazioni configurate per la nostra app; se è tutto ok, procediamo alla creazione dell’app facendo click su Create.

Figura 9: Distribuire WinGet con Microsoft Intune – Parte 7

Dopo poco tempo, Intune avrà creato la nostra app con successo.

Figura 10: Applicazione WinGet creata con successo

Per verificare che l’app sia stata creata correttamente, torniamo alla sezione Apps > Windows di Intune e cerchiamo la nostra applicazione tra quelle disponibili.

Figura 11: Ricerca applicazione WinGet tra le app create

Come gestire WinGet in azienda

WinGet è potente perché standardizza installazione e aggiornamento delle applicazioni, ma proprio per questo va governato. In un contesto enterprise non è solo una CLI “comoda”: di fatto è un canale di distribuzione software. Se lo lasciate totalmente libero, rischiate di ritrovarvi con:

• sorgenti aggiunte manualmente dagli utenti
• installazioni fuori processo e non tracciate dai vostri workflow
• comportamenti diversi tra device (stessa app, risultati diversi)
• troubleshooting più complesso, perché ogni PC diventa un caso a sé

La buona notizia è che Microsoft mette a disposizione policy dedicate per Windows Package Manager tramite Desktop App Installer, distribuibili anche con Microsoft Intune, che permettono di controllare in modo granulare aspetti come abilitazione, gestione delle sorgenti (incluso consentire/bloccare sorgenti aggiuntive), funzionalità sperimentali, uso di manifest locali, possibilità di modificare impostazioni e altro ancora.

Nota pratica: queste impostazioni sono esposte tramite il CSP Policy CSP – DesktopAppInstaller e risultano, in larga parte, supportate su Windows 11 22H2 (build 22621) e successivi. Alcune opzioni più recenti, ad esempio il controllo esplicito delle interfacce a riga di comando (WinGet CLI/WinGet PowerShell) e la feature “Windows Package Manager configuration”, richiedono Windows 11 24H2 (build 26100) e successivi. Potete trovare maggior informazioni alla pagina Microsoft Policy CSP – DesktopAppInstaller.

Configurare WinGet con Intune tramite Settings catalog

Dal punto di vista operativo, l’approccio più pulito è creare un profilo Settings catalog e aggiungere le impostazioni sotto Windows Components > Desktop App Installer (sono policy ADMX-backed mappate su Software\Policies\Microsoft\Windows\AppInstaller). Vediamo come farlo. Per prima cosa, torniamo al Microsoft Intune Admin Center e navighiamo in Device > Configuration, successivamente facciamo click su Create > New Policy. Nel wizard che si apre sulla vostra destra selezionare Platform Windows 10 and later e come Profile type selezionate Settings catalog. Infine, procedete facendo click su Create

Figura 12: Configurazione WinGet tramite Settings catalog in Microsoft Intune – Parte 1

Adesso siamo pronti per configurare la nostra policy. Nella sezione Basics, assegnare un nome al profilo (ad es. “WinGet Configuration”), una descrizione (facoltativo) e procedere cliccando su Next

Figura 13: Configurazione WinGet tramite Settings catalog in Microsoft Intune – Parte 2

Nella sezione Configuration settings fare click su Add settings. Nel wizard che apparirà sulla vostra destra scriviamo nella barra di ricerca “App Installer” e apparirà la categoria “Administrative Templates Windows Components Desktop App Installer”. Selezionandola, appariranno in basso tutti i settings disponibili per configurare il profilo.

Figura 14: Configurazione WinGet tramite Settings catalog in Microsoft Intune – Parte 3

Facendo click su Select all these settings verrà importato sulla sinistra l’Administrative Template
Windows Components > Desktop App Installer con tutti i settaggi che possiamo configurare. Questi settaggi corrispondono alle policy del Policy CSP: DesktopAppInstaller (ADMX-backed). Di seguito vi riporto ogni impostazione presente e che cosa fa se abilitata, in modo che possiate scegliere consapevolmente.

Tabella 1: Impostazioni Windows Components > Desktop App Installer

A questo punto, una volta selezionati i settaggi desiderati, possiamo fare click su Next.
Importante: In un contesto enterprise suggerirei di mantenere disabilitata l’opzione Enable Windows Package Manager command line interfaces per evitare che chiunque possa utilizzare i comandi WinGet per installare o aggiornare app. Lo scopo di questa guida è proprio quello di standardizzarne l’uso per contesti governati a dovere.

Figura 15: Configurazione WinGet tramite Settings catalog in Microsoft Intune – Parte 4

Nella sezione Scope tags (opzionale) lasciare Default, oppure selezionare uno scope tags già creato in precedenza nel vostro ambiente Intune. Nel nostro caso lasceremo quello di default. Successivamente cliccate su Next.

Figura 16: Configurazione WinGet tramite Settings catalog in Microsoft Intune – Parte 5

A questo punto, nella sezione Assignments, possiamo assegnare la nostra policy al gruppo desiderato. Facciamo click su Add groups, cercare il gruppo desiderato, selezionarlo con l’apposita checkbox ed infine fare click su Select.

Figura 17: Configurazione WinGet tramite Settings catalog in Microsoft Intune – Parte 6

Sempre nella pagina di Assignments potete verificare che il gruppo selezionato è stato aggiunto alla lista Included groups. Se volete aggiungere altri gruppi o aggiungere filtri è il momento giusto, altrimenti continuare cliccando nuovamente su Next.

Figura 18: Configurazione WinGet tramite Settings catalog in Microsoft Intune – Parte 7

Arrivati alla sezione Review + create, verificate che tutti i dettagli della policy siano corretti, inclusi i gruppi di assegnazione. Se è tutto ok, proseguire cliccando su Create.

Figura 19: Configurazione WinGet tramite Settings catalog in Microsoft Intune – Parte 8

A questo punto, la nostra policy sarà stata creata.

Figura 20: Policy per la configurazione di WinGet creata con successo

Tornando in Devices > Configuration e cercando la policy appena creata nell’apposita textbox, dopo qualche secondo la troverete correttamente creata e assegnata al gruppo selezionato. Da qui potrete anche modificarla qualora fosse necessario.

Figura 21: Overview nuova policy WinGet Configuration

End user experience

Dopo aver distribuito WinGet e applicato le policy di governance tramite Settings catalog, è utile verificare come si comporta il client dal punto di vista dell’utente finale. In ambienti enterprise, infatti, la differenza tra WinGet installato e WinGet realmente utilizzabile e governato sta tutta nell’esperienza sul dispositivo. Quali sorgenti risultano disponibili? Quali funzionalità sono abilitate o bloccate? E quale feedback viene mostrato quando un’azione non è consentita? In questa sezione vedremo quindi l’esperienza sui pc a cui abbiamo distribuito WinGet e le relative policy, mostrando cosa cambia concretamente lato utente e come validare rapidamente che la configurazione sia stata recepita correttamente.

Come prima cosa verifichiamo che il profilo sia stato correttamente assegnato. Per verificare ciò è possibile accedere alle Impostazioni di Windows > Account > Accedi all’azienda o all’istituto di istruzione > Selezionare la connessione alla vostra azienda e fare click su Informazioni.

Figura 22: Informazioni Account aziendale

Come possiamo vedere, la nostra policy è stata correttamente applicata.

Figura 23: Verifica policy WinGet correttamente applicata al dispositivo

Registro di sistema

Quando distribuiamo le policy di WinGet tramite Settings catalog (Windows components > Desktop App Installer), Intune configura le impostazioni del provider Policy CSP DesktopAppInstaller, che sono policy ADMX-backed. Un modo rapido per verificare cosa è arrivato davvero sul device e cosa risulta effettivamente applicato è controllare le chiavi sotto PolicyManager; è utilissimo quando in portale lo stato risulta “compliant“, ma il comportamento sul client non torna.

Nel percorso HKLM:\SOFTWARE\Microsoft\PolicyManager\Current\Device\DesktopAppInstaller troviamo la configurazione effettiva, ovvero quella che Windows sta utilizzando in quel momento. Spesso alcune voci seguono il pattern *_ADMXInstanceData e non contengono subito un valore leggibile, rimandano infatti all’istanza del provider MDM che ha consegnato la policy, identificata da un GUID.

Figura 24: Troubleshooting policy WinGet via registro di sistema – Parte 1

A questo punto, spostandoci nel percorso HKLM:\SOFTWARE\Microsoft\PolicyManager\Providers\<GUID>\Default\Device\DesktopAppInstaller, possiamo vedere con chiarezza i parametri ricevuti tramite MDM e i relativi valori. Questo è un ottimo riscontro operativo per confrontare rapidamente cosa hai configurato nel profilo Intune con ciò che è stato realmente recapitato e processato dal client

Figura 25: Troubleshooting policy WinGet via registro di sistema – Parte 2

Infine, essendo policy ADMX-backed, la documentazione ufficiale riporta anche la mappatura “GPO-like” delle stesse impostazioni nel percorso HKLM:SOFTWARE\Policies\Microsoft\Windows\AppInstaller (chiave e nomi valori variano in base alla specifica policy). Questo dettaglio è utile soprattutto quando si devono correlare controlli o strumenti che leggono esclusivamente Software\Policies\… per verifiche di conformità

Figura 26: Troubleshooting policy WinGet via registro di sistema – Parte 3

Riga di comando e troubleshooting

Dopo aver distribuito WinGet e applicato le policy, il modo più rapido per capire che cosa sta succedendo su un pc è eseguire alcuni controlli mirati da riga di comando. Facciamolo in modo pratico, partendo da poche domande chiave: WinGet è presente? Le policy sono state recepite e stanno realmente limitando (o abilitando) le funzionalità attese?

WinGet è disponibile sul dispositivo?

Il controllo più rapido, sia da Prompt dei comandi sia da PowerShell, è:

L’output è molto utile perché, oltre alla versione del client, mostra anche metadati di sistema come architettura, percorso dei log, riferimenti agli accordi legali e soprattutto lo stato delle policy (utile per capire al volo se la governance sta impattando il comportamento del client).

Nota pratica: su dispositivi appena provisionati può capitare che WinGet non sia ancora disponibile finché non avviene il primo logon utente (registrazione asincrona legata ad App Installer/Microsoft Store). Quindi il check ha senso farlo dopo un accesso interattivo.

Figura 27: Troubleshooting WinGet via riga di comando – Parte 1

Le policy sono state applicate correttamente?

La Figura 27 mostra l’output di winget –info in una situazione in cui WinGet non sta ancora rilevando criteri amministrativi applicati (oppure non li sta esponendo nell’output in quel momento). Quando le policy distribuite tramite Intune vengono recepite dal dispositivo, ripetendo winget –info dovreste vedere comparire anche le sezioni dedicate ai criteri, in particolare le informazioni relative allo stato delle policy e alle impostazioni amministrative, che riflettono i vincoli configurati (ad esempio funzionalità consentite/bloccate e impostazioni governate dall’amministratore).

Figura 28: Troubleshooting WinGet via riga di comando – Parte 2

Funziona in contesti high privilege?

In scenari enterprise può capitare che WinGet non sia immediatamente utilizzabile in contesto SYSTEM, soprattutto quando viene richiamato da script o installazioni eseguite tramite Intune o SCCM con “install behavior” in contesto non-utente. Il punto non è tanto avere più privilegi, quanto il fatto che WinGet è incluso nel pacchetto Microsoft.DesktopAppInstaller (App Installer). Essendo un’app packaged, la sua registrazione e l’alias di esecuzione winget possono non risultare disponibili per l’account SYSTEM (o Administrator). In questi casi, quando il comando viene lanciato in una sessione SYSTEM (ad esempio con PsExec o tramite agent MDM/RMM), è normale vedere errori come “winget non è riconosciuto…“.

Figura 29: Troubleshooting WinGet via riga di comando – Parte 3

In alternativa, come workaround grezzo ma efficace, potete anche cercare winget.exe ricorsivamente sotto C:\Program Files\WindowsApps\… e richiamarlo da lì (es. sui sistemi x64 il percorso è C:\Program Files\WindowsApps\Microsoft.DesktopAppInstaller_*_x64__8wekyb3d8bbwe\winget.exe).

Nota: la cartella WindowsApps è protetta e tipicamente non accessibile a un normale amministratore, mentre il contesto SYSTEM spesso riesce a leggerla (motivo per cui questo workaround funziona bene nei deployment via agent).

Figura 30: Troubleshooting WinGet via riga di comando – Parte 4

Per fare per automazione, un approccio robusto è richiamare direttamente l’eseguibile dalla cartella di installazione del pacchetto, evitando di dipendere dal PATH o alias. La cartella sotto WindowsApps include la versione nel nome e può cambiare con gli aggiornamenti; quindi, è meglio risolverla dinamicamente. Questa tecnica è particolarmente utile quando esegui in contesto SYSTEM (es. deploy Intune/SCCM):

Approfondiremo questo punto nei prossimi articoli, quando entreremo nella parte più operativa e vedremo come usare WinGet come motore di installazione e upgrade per pacchetti distribuiti via Intune e SCCM.

Figura 31: Troubleshooting WinGet via riga di comando – Parte 5

Come si installa o aggiorna un applicazione?

Per individuare rapidamente quali applicazioni hanno un aggiornamento disponibile, possiamo utilizzare:

L’output mostra l’elenco dei pacchetti per cui WinGet riesce a rilevare una versione più recente rispetto a quella installata, in base alle sorgenti configurate

Figura 32: Troubleshooting WinGet via riga di comando – Parte 6

Per completezza, se vi serve solo vedere quali app hanno update disponibili, esiste anche l’opzione dedicata del comando list, ad esempio:

Figura 33: Troubleshooting WinGet via riga di comando – Parte 7

A questo punto, se decidessimo ad esempio di aggiornare un software specifico, potremmo utilizzare la sintassi winget upgrade <IdApp> <switch_options>. Per esempio, supponiamo di dover aggiornare l’applicazione Google Chrome in modalità silent. In questo caso possiamo utilizzare il seguente comando:

Figura 34: Troubleshooting WinGet via riga di comando – Parte 8

Se invece volessimo installare un applicazione nuova, potremmo utilizzare la sintassi winget install <IdApp> <switch_options>. Ad esempio, supponiamo di voler installare l’applicazione 7-Zip, utilizzeremo il comando:

Figura 35: Troubleshooting WinGet via riga di comando – Parte 9

Può capitare di non avere privilegi sufficienti per installare o aggiornare un’applicazione. In questi casi WinGet lo evidenzia chiaramente: se l’installer richiede elevazione, Windows mostrerà un prompt UAC per proseguire e, se l’elevazione non viene concessa, l’operazione fallirà. Questo scenario è molto comune in ambito enterprise, dove gli utenti operano come standard user. Detto in modo semplice, lasciare la CLI disponibile non significa automaticamente perdere il controllo, perché WinGet non concede privilegi che l’utente non ha. La piena governance si ottiene combinando il modello di privilegi (standard user/UAC) con le policy di Windows Package Manager e di Desktop App Installer (sorgenti consentite, funzionalità abilitate, superfici esposte e possibilità di modifica delle impostazioni), come vedremo nel capitolo successivo.

Figura 36: Troubleshooting WinGet via riga di comando – Parte 10

Naturalmente abbiamo visto finora solamente alcune dei possibili switch di WinGet, per approfondire potete eseguire il comando winget senza altre opzioni (vedi Figura 30) per visualizzare tutte le command options e i vari switch disponibili.

Vogliamo davvero che gli utenti usino WinGet da riga di comando?

Fin qui abbiamo visto come verificare la presenza di WinGet e come installare o aggiornare applicazioni via riga di comando. A questo punto vale la pena fermarsi un attimo e porsi una domanda di governance: vogliamo lasciare agli utenti finali la possibilità di usare WinGet liberamente da CLI?

In alcuni contesti può essere un vantaggio, perché velocizza operazioni, troubleshooting e test. In altri, però, significa introdurre un canale di installazione software parallelo che può aggirare i processi di approvazione, generare drift tra dispositivi e complicare compliance e supporto.

Microsoft mette a disposizione diverse impostazioni per governare WinGet in modo granulare (vedi Tabella 1 nel capitolo “Come gestire WinGet in azienda“), ma è importante chiarire un punto: il setting Enable Windows Package Manager command line interfaces è, di fatto, un “interruttore generale”. Se viene disabilitato, non si blocca solo la WinGet CLI, ma anche i cmdlet PowerShell legati a Windows Package Manager. In pratica, diventa molto più difficile (o impossibile, a seconda dello scenario) usare WinGet come motore richiamabile da script e automazioni sul client, motivo per cui va usato con cautela. Per questo, se l’obiettivo è usare WinGet come motore gestito dall’IT, nella maggior parte degli scenari conviene mantenere abilitate le interfacce e spostare la governance su ciò che conta davvero: sorgenti consentite e non modificabili dall’utente, funzionalità abilitate o bloccate (ad esempio manifest locali e hash override), possibilità di cambiare impostazioni, e anche la superficie di attacco legata al protocollo ms-appinstaller (gestibile via policy).

Figura 37: Troubleshooting WinGet via riga di comando – Parte 11

Come rendere WinGet sicuro

Quando decidiamo di lasciare WinGet utilizzabile da riga di comando, la chiave è ricordare che la CLI non è il vero punto di controllo, ma è solo l’interfaccia. Il setting “Enable Windows Package Manager command line interfaces” va trattato come un interruttore generale perché, se impostato su Disabled, impedisce l’uso di Windows Package Manager tramite interfacce a riga di comando e cmdlet dedicati, impattando di conseguenza anche script e automazioni che si appoggiano a tali interfacce. Proprio per questo, nella maggior parte degli scenari in cui WinGet deve rimanere sfruttabile dall’IT conviene mantenerlo attivo e spostare la governance su ciò che WinGet può fare e da dove può farlo.

Il primo strato di controllo naturale in contesti enterprise resta il least privilege: un utente standard, senza diritti amministrativi, nella maggior parte dei casi non riesce a completare installazioni che richiedono elevazione, perché WinGet arriva fino al punto in cui Windows richiede l’UAC. Questo aiuta, ma non basta da solo: esistono software installabili per-user e flussi che non richiedono privilegi elevati. Quindi l’approccio corretto non è “lascio la CLI perché tanto c’è l’UAC“, ma “lascio la CLI e riduco le superfici che l’utente può sfruttare“.

Qui entrano in gioco le policy di Desktop App Installer distribuite via Settings catalog che abbiamo visto nei capitoli precedenti: se vuoi evitare che WinGet diventi un canale parallelo di installazione, le best practice più solide sono quelle che governano le sorgenti (quali repository sono disponibili e se l’utente può aggiungerne di nuovi) e che disabilitano le scorciatoie più difficili da controllare, come l’installazione da link web tramite protocollo ms-appinstaller e l’uso di manifest locali. Su questo punto c’è anche un fatto importante: Microsoft ha disabilitato per impostazione predefinita l’handler del protocollo ms-appinstaller il 28 dicembre 2023 in risposta ad abusi reali osservati in campagne malware; in contesto enterprise è quindi sensato lasciarlo disabilitato salvo esigenze specifiche e motivate, riabilitandolo solo dove serve e con governance chiara.

Se però l’obiettivo è più ambizioso, del tipo “gli utenti non devono poter installare nulla fuori da ciò che l’IT approva“, allora WinGet non è il bersaglio giusto e il controllo deve spostarsi a livello di application control. In ambiente Microsoft, una combinazione molto pulita è App Control for Business (ex WDAC) con Managed Installer: dopo aver abilitato un managed installer, le applicazioni distribuite tramite canali gestiti come Intune possono essere “taggate” come attendibili e quindi autorizzate automaticamente, mentre ciò che arriva da fuori può essere bloccato. In questo modo puoi tenere WinGet con interfacce abilitate senza trasformarlo in un far west.

Infine, per gestire le inevitabili eccezioni operative senza trasformare gli utenti in local admin, ha senso citare Endpoint Privilege Management (EPM), che consente elevazioni controllate per attività approvate dall’IT (installazioni, tool diagnostici, ecc.), mantenendo l’utente standard come baseline. Il quadro si chiude bene: WinGet resta disponibile, ma privilegi ed eccezioni vengono gestiti in modo governato.

Vi lascio qualche link utile per approfondire:

• App Control for Business policy and Managed Installers for Microsoft Intune
• Endpoint Privilege Management with Microsoft Intune
• Policy CSP – DesktopAppInstaller

Considerazioni finali

WinGet è uno strumento semplice da usare ma, in contesto enterprise, non va trattato come una comodità da power user. Questo tool è un vero e proprio canale di distribuzione software e, proprio per questo, prima di pensare ad automazioni e installazioni massive, conviene fare due cose:

• assicurarsi che App Installer/WinGet sia distribuito in modo centralizzato su tutti i dispositivi
• definire una governance chiara tramite le policy di Desktop App Installer

La parte interessante che ho voluto mostrarvi in questo articolo è che Intune permette di arrivare a un buon equilibrio. WinGet può rimanere disponibile (anche via CLI, se serve), ma con sorgenti governate, funzionalità più sensibili limitate e un comportamento più prevedibile sull’intero parco macchine. Il risultato è meno drift tra dispositivi e una base più solida per i passi successivi, che si tratti dell’adozione del nuovo Microsoft Store, dell’automazione di install/upgrade o dell’integrazione con processi di modern management.

Se l’obiettivo è impedire in modo rigoroso installazioni non approvate, è importante essere realistici: la governance di WinGet, da sola, non sostituisce strumenti di application control o di gestione delle elevazioni. Tuttavia, come primo passo, distribuire e governare WinGet è esattamente il tipo di fondazione che evita sorprese quando poi lo userete in scenari più operativi.

Conclusioni

In questo primo capitolo abbiamo messo a terra le basi: cos’è WinGet, come distribuirlo con Microsoft Intune e, soprattutto, come governarlo in modo granulare tramite le policy di Desktop App Installer. L’obiettivo non è far funzionare winget su un pc, ma renderlo prevedibile e controllabile su un parco macchine reale, con le tipiche variabili enterprise (Store limitato, provisioning, policy, contesti ad alto privilegio).

Da qui in avanti, tutto diventa più semplice. Infatti, quando WinGet è distribuito correttamente e sorgenti e funzionalità sono sotto controllo, potete decidere con serenità se abilitarlo anche per alcuni profili di utenti, se chiuderlo ulteriormente, oppure se usarlo come motore operativo per scenari più avanzati (Win32, upgrade controllati, troubleshooting standardizzato). Nei prossimi articoli entreremo proprio in quella parte: governance on-prem (GPO/ADMX, SCCM) e utilizzo pratico per la distribuzione software in modo centralizzato, sfruttando le potenzialità di questo strumento.

WinGet non è un comando in più, è una scelta di governance. E quando la governance è fatta bene, l’automazione smette di essere un rischio e diventa un vantaggio.