Automatizzare il deploy delle app Intune con Chocolatey

Intune non distribuisce software: orchestra installazioni

Se vuoi automatizzare il deploy delle app su Windows con Intune e Chocolatey, il punto da chiarire subito è questo: Intune non sostituisce il packaging, lo governa. Chocolatey si occupa del ciclo di installazione sul client; Intune decide quando, a chi e con quali condizioni farlo partire. La combinazione funziona bene quando smetti di trattarla come “un modo comodo per lanciare un installer” e la imposti come una catena controllata: pacchetto, detection, dipendenze, logging, rollback.

© TrgtKLS • Tech, Sicurezza e Strumenti & guide per Webmaster — https://trgtkls.it — tutti i diritti riservati.

Il vantaggio pratico è evidente nelle flotte miste o distribuite: niente condivisioni SMB esposte, meno GPO fragili, meno script ad-hoc con percorsi hardcoded, più controllo su versioni e assegnazioni. Il rovescio della medaglia è altrettanto concreto: se il pacchetto Chocolatey è fatto male, Intune amplifica il problema perché lo distribuisce in massa. Quindi il design va impostato prima della pubblicazione, non dopo il primo fallimento in produzione.

Architettura minima: Intune come motore di delivery, Chocolatey come runtime di installazione

La soluzione più robusta non è “caricare un exe in Intune” e sperare che basti. Il modello pulito è questo: prepari uno script o un pacchetto Win32 che installa Chocolatey se non è presente, poi usa Chocolatey per installare o aggiornare le applicazioni target. Intune gestisce assegnazione, retry, reporting e finestra di esecuzione; Chocolatey gestisce il repository, le dipendenze e l’idempotenza dell’installazione.

In pratica hai tre livelli. Il primo è il client Windows con i prerequisiti minimi: connettività verso Intune, permessi adeguati, PowerShell funzionante, spazio disco sufficiente. Il secondo è Chocolatey, che può essere installato in modalità machine-wide. Il terzo è il pacchetto applicativo, che può essere un package Chocolatey interno o pubblico, oppure un wrapper che richiama più installazioni in sequenza. La qualità del risultato dipende soprattutto da come definisci detection e stato desiderato.

Perché Chocolatey è utile in Intune e dove invece non conviene forzarlo

Chocolatey è utile quando vuoi standardizzare software ricorrente: browser, tool di produttività, runtime, utility di amministrazione, agenti interni. Dove vince è nella ripetibilità: lo stesso comando produce lo stesso effetto, a patto che il package sia mantenuto bene. Questo è importante perché Intune, da solo, non ti dà una libreria applicativa con dipendenze, checksum e semantica di aggiornamento così chiara.

Non conviene invece usarlo come scorciatoia per ogni cosa. Se l’app richiede trasformazioni MSI complesse, licenze interattive, driver, reboot delicati o logiche di upgrade non lineari, allora è spesso meglio impacchettare il vendor installer in un Win32 app di Intune con script dedicati. Chocolatey resta valido, ma va usato dove aggiunge ordine, non dove introduce un layer in più senza beneficio.

Scelta del modello: package Chocolatey puro o wrapper Intune

Ci sono due approcci pratici. Il primo è distribuire Chocolatey come prerequisito e poi usare script Intune che eseguono `choco install` o `choco upgrade`. Il secondo è creare un pacchetto Win32 di Intune che contiene lo script, i file di supporto e, se serve, l’installer del package. Il primo è più elegante quando hai già una piattaforma Chocolatey interna ben governata. Il secondo è più prevedibile quando vuoi tenere tutto nel perimetro Intune e ridurre dipendenze esterne.

Se la tua priorità è il controllo operativo, di solito conviene partire con il wrapper Win32. Hai una detection unica, un log unico e una gestione più semplice dei prerequisiti. Se invece hai già repository Chocolatey privati, package firmati e un team che li mantiene, allora Intune può limitarsi a orchestrare l’installazione iniziale di Chocolatey e la successiva esecuzione di job standardizzati. Non è una scelta filosofica: è una scelta di governance.

Installazione di Chocolatey sul client: il punto che rompe più spesso i rollout

La fase iniziale va trattata come un change controllato, non come un dettaglio. Chocolatey deve essere installato in modo non interattivo, con privilegi amministrativi, e deve lasciare un log leggibile. Su macchine gestite da Intune, l’errore più comune è presupporre che lo script giri nel contesto corretto senza verificarlo. In realtà devi distinguere tra esecuzione come sistema, come utente e come amministratore locale.

Un controllo rapido prima del rollout è verificare che il client possa raggiungere l’endpoint del repository e che PowerShell abbia i permessi necessari. Se usi repository pubblici o mirror interni, valuta anche proxy e ispezione TLS. Il client deve poter scaricare, verificare e installare senza prompt. Se questa parte non è solida, tutto il resto è solo un trigger di errori ripetuti.

Set-ExecutionPolicy Bypass -Scope Process -Force
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))

Quel classico bootstrap va bene solo come riferimento tecnico. In produzione conviene portarlo dentro uno script versionato, con checksum dove applicabile, logging su file e controllo esplicito dell’esito. Se il tuo standard di sicurezza vieta il download diretto da Internet, sostituiscilo con un mirror interno o con un artefatto già approvato dal tuo repository software.

Detection: se sbagli qui, Intune ti reinstalla tutto o non reinstalla niente

La detection è la parte che più spesso viene sottovalutata. Intune ha bisogno di capire se il dispositivo è già nello stato desiderato. Chocolatey, da solo, sa installare pacchetti; non decide per te se l’app è conforme alla policy. Quindi devi definire una detection che sia stabile, poco ambigua e resistente agli aggiornamenti minori.

Le opzioni migliori sono in genere tre: presenza di chiavi di registro, presenza di file con versione nota, oppure verifica della versione del pacchetto installato. La scelta dipende dall’app. Per software ben strutturato, la chiave di uninstall nel registro è spesso sufficiente. Per tool portabili o wrapper complessi, un file o una directory con versione è più affidabile. Evita detection che si basano solo su processi attivi: un servizio può essere fermo e l’app comunque installata, o viceversa.

Un dettaglio che crea problemi in silenzio è la differenza tra “installato” e “aggiornato all’ultima versione”. Se vuoi usare Chocolatey anche per upgrade automatici, devi decidere se Intune deve verificare la sola presenza o una specifica versione target. In ambienti controllati, la seconda opzione è quasi sempre preferibile, perché evita drift e semplifica il supporto.

Repository interno: il vero salto di qualità per ambienti aziendali

Usare il repository pubblico di Chocolatey può andare bene per test e casi semplici, ma in un ambiente aziendale serio il passo corretto è quasi sempre un repository interno. Questo ti permette di approvare i pacchetti, congelare le versioni, controllare la supply chain e ridurre la dipendenza da Internet. Inoltre ti semplifica la gestione di proxy, firewall e finestre di manutenzione.

Il repository interno non serve solo a “fare caching”. Serve a introdurre un punto di controllo. Puoi pubblicare solo pacchetti validati, bloccare versioni difettose, ritirare rapidamente una release problematica e separare ambiente di test da produzione. Se distribuisci tool amministrativi o agenti di sicurezza, questo controllo è particolarmente importante perché un pacchetto sbagliato può impattare migliaia di endpoint in pochi minuti.

In questo scenario, Intune punta al repository interno o a un package già confezionato che contiene il comando di installazione. Il vantaggio è che la macchina client non deve navigare un ecosistema esterno per capire cosa fare. Sa solo quale artefatto scaricare e quale comando eseguire.

Logging: senza log leggibili non hai automazione, hai solo fede

Se vuoi supportare davvero il deploy automatizzato, devi sapere dove guardare quando qualcosa fallisce. Intune registra lo stato di delivery, ma spesso il dettaglio utile sta nel client: log della gestione Intune, log dello script, log di Chocolatey e log dell’applicazione installata. Il punto non è avere tanti log; è avere un filo logico per correlare evento, comando e risultato.

Su Windows, i log di Intune e del Management Extension sono il primo posto da controllare quando un’app non parte. Chocolatey, invece, deve scrivere in un path noto e stabile, così puoi raccoglierlo o consultarlo in caso di errore. Se lo script gira come sistema, i log devono essere accessibili anche senza sessione utente. Se il tuo team usa un SOC o un sistema di monitoraggio centralizzato, prevedi già il forwarding dei log più utili.

Get-Content 'C:	empuild
un.log' -Tail 50 -Wait

Quel tipo di monitoraggio è utile anche durante i test pilota. Vedere in tempo reale il log di installazione ti dice subito se il problema è download, privilegi, detection o reboot. È molto più veloce che aspettare il report finale di Intune e poi inseguire il guasto a posteriori.

Rollback: pianificalo prima di pubblicare il pacchetto

Ogni distribuzione automatizzata dovrebbe avere un rollback esplicito. Con Chocolatey e Intune, il rollback può voler dire disinstallazione del pacchetto, ripristino della versione precedente, o revoca dell’assegnazione in Intune. Non sempre la disinstallazione è sufficiente: alcune app lasciano profili utente, cache o servizi. Per questo il rollback va definito per classe di applicazione, non in modo generico.

La strategia più prudente è pubblicare prima su un gruppo pilota ristretto, verificare installazione, esecuzione e detection, e solo dopo allargare. Se qualcosa va storto, rimuovi l’assegnazione o blocca la distribuzione prima di cambiare il pacchetto. Questo limita il blast radius e ti dà tempo per correggere il manifest, lo script o il repository senza correre dietro a centinaia di endpoint già in errore.

Quando possibile, conserva sempre la versione precedente del pacchetto nel repository interno. In questo modo puoi tornare indietro con un upgrade forzato alla release nota buona, invece di improvvisare una rimozione di massa. Per software critici, è una differenza importante.

Pattern operativo che funziona davvero

Il flusso più affidabile, in molti ambienti, è questo: prepari un repository Chocolatey interno, definisci un pacchetto per ogni software o gruppo logico, testi il pacchetto in una macchina di validazione, poi lo distribuisci con Intune a un gruppo pilota. Se il pacchetto richiede prerequisiti, li gestisci nello stesso flusso, ma senza mescolare troppe funzioni in uno script unico. Più il pacchetto è prevedibile, meno tempo perdi in supporto.

Un esempio concreto: vuoi distribuire un browser aziendale con estensioni standard e impostazioni iniziali. Chocolatey installa il browser, uno script post-install copia il profilo o le policy locali, Intune assegna il pacchetto a un gruppo di test e verifica la presenza della versione corretta. Se il browser cambia comportamento in una release successiva, aggiorni il pacchetto nel repository interno, non lo script distribuito a mano su ogni device.

Questo approccio ha un vantaggio collaterale: rende più semplice la documentazione operativa. Sai dove guardare per capire cosa è cambiato, chi ha pubblicato il pacchetto, quale versione è stata approvata e quale gruppo la riceve. In un team che gestisce molti endpoint, questa tracciabilità vale quanto l’automazione stessa.

Errori tipici da evitare

Il primo errore è usare uno script troppo generico, senza distinzione tra installazione iniziale e upgrade. Il secondo è basare la detection su un file temporaneo o su un path che cambia tra versioni. Il terzo è distribuire direttamente da repository pubblici senza una policy di approvazione. Il quarto è non testare il comportamento dietro proxy o in assenza di diritti amministrativi locali.

Un altro errore frequente è ignorare il reboot. Alcune installazioni sembrano riuscite ma richiedono riavvio per completarsi davvero. Se non lo gestisci, Intune può marcare il device come conforme mentre l’utente vede ancora un’app incompleta o un servizio non attivo. Anche qui la soluzione è semplice ma va decisa prima: policy di riavvio, finestra di manutenzione o installazione differita.

Infine, attenzione ai segreti. Se il pacchetto o lo script deve autenticarsi verso un repository privato, non inserire credenziali in chiaro nello script. Usa identità gestite, token a scadenza, segreti archiviati in modo appropriato e rotazione periodica. L’automazione non giustifica scorciatoie sulla sicurezza.

Quando il deploy è pronto per la produzione

Un deploy Intune + Chocolatey è pronto quando hai quattro cose: pacchetto deterministico, detection affidabile, logging utile e rollback praticabile. Se ne manca una, la distribuzione non è davvero automatizzata; è solo più veloce da rompere. La differenza, in produzione, si vede subito: meno ticket, meno reinstallazioni manuali, meno eccezioni gestite a mano dagli amministratori.

La combinazione funziona particolarmente bene quando vuoi standardizzare un parco endpoint, ridurre il lavoro ripetitivo e mantenere controllo sulle versioni installate. Se la imposti bene, Intune diventa il piano di controllo e Chocolatey il meccanismo di esecuzione. Se la imposti male, ti ritrovi con due sistemi che si rinfacciano gli errori. La differenza la fanno sempre i dettagli: detection, repository, log e rollback.