1 12/10/2026 9 min

Chocolatey su Windows Server 2012 e 2019: quando usarlo e cosa aspettarsi

Chocolatey è un gestore di pacchetti per Windows utile quando devi standardizzare installazioni, automatizzare update e ridurre il numero di passaggi manuali su server. Su Windows Server 2019 l’installazione è diretta; su Windows Server 2012 e 2012 R2 funziona, ma conviene essere più rigorosi su prerequisiti TLS, PowerShell e policy di esecuzione. Il punto non è “installare un tool”, ma evitare che il server resti in uno stato ambiguo: repository non raggiungibile, TLS vecchio, proxy non dichiarato o permessi insufficienti.

Se il tuo obiettivo è gestire software come 7-Zip, Git, Notepad++, IIS tools o runtime vari, Chocolatey è spesso più pulito di uno script batch pieno di download e silenziatori. Se invece stai lavorando in un ambiente molto chiuso, con proxy ispezionanti o senza accesso diretto a internet, devi prima chiarire il canale di uscita verso i repository e il modello di approvazione dei pacchetti.

Prerequisiti reali: versione, PowerShell, TLS e privilegi

Prima di lanciare il bootstrap, verifica tre cose: privilegi amministrativi, versione di PowerShell e capacità di uscire in HTTPS verso il repository. Su Windows Server 2019 in genere non ci sono sorprese; su 2012/2012 R2 il problema tipico è TLS 1.2 non abilitato come default per il processo PowerShell che scarica lo script di installazione.

Controlli minimi:

powershell -NoProfile -Command "$PSVersionTable.PSVersion"
powershell -NoProfile -Command "[Net.ServicePointManager]::SecurityProtocol"
whoami /groups

Su un server sano, PowerShell 5.1 è la situazione ideale. Se vedi una versione più vecchia, l’installazione può comunque riuscire, ma aumenta la probabilità di problemi con TLS o con cmdlet più moderni. Il controllo dei gruppi serve a confermare che la shell sia elevata: se non hai privilegi amministrativi, l’installazione può fallire nel momento in cui prova a scrivere sotto C:\ProgramData\chocolatey o a modificare variabili di ambiente di sistema.

Abilitare TLS 1.2 prima del bootstrap

Su Windows Server 2012 e 2012 R2 questa è la parte che più spesso fa perdere tempo. Lo script di installazione di Chocolatey viene scaricato via HTTPS; se il processo PowerShell usa protocolli obsoleti, il download può fallire senza un messaggio chiarissimo. La correzione più pulita è forzare TLS 1.2 per la sessione corrente prima di invocare lo script.

powershell -NoProfile -ExecutionPolicy Bypass -Command "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; [Net.ServicePointManager]::SecurityProtocol"

Se il valore restituito include solo TLS 1.2, sei nella condizione giusta per procedere. In ambienti molto vecchi può servire anche l’aggiornamento dei pacchetti di root certificate e delle componenti Schannel, ma non lo dare per scontato: prima osserva l’errore reale. Se il problema è un proxy o un firewall, forzare TLS non basta.

Installazione standard con lo script ufficiale

Il metodo più semplice resta lo script ufficiale. Va eseguito in una shell elevata e, in ambienti controllati, conviene sempre leggere il comando prima di lanciarlo. Non è un caso di fiducia cieca: stai eseguendo un bootstrap che installa un package manager con privilegi amministrativi.

powershell -NoProfile -ExecutionPolicy Bypass -Command "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'))"

Dopo il completamento, verifica che il binario sia presente e che la variabile di ambiente sia stata aggiornata:

where choco
choco -v
$env:ChocolateyInstall

Il percorso tipico è C:\ProgramData\chocolatey. Se where choco non restituisce nulla, spesso basta aprire una nuova sessione PowerShell o CMD per ricaricare il PATH. Se invece il percorso c’è ma il comando non parte, controlla permessi e policy di esecuzione locali.

Installazione su Windows Server 2012: i punti che rompono più spesso

Su Server 2012 il problema non è Chocolatey in sé, ma il contesto. In pratica i casi ricorrenti sono tre: TLS non adeguato, PowerShell troppo vecchio o proxy aziendale non dichiarato. Il primo si risolve con l’impostazione della sessione; il secondo con un aggiornamento del sistema o con una procedura più conservativa; il terzo con la configurazione esplicita del proxy per il processo che scarica lo script.

Se il server esce in internet tramite proxy, prova a verificare la reachability con un test minimale prima di installare:

powershell -NoProfile -Command "(New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1') | Select-Object -First 5"

Se ricevi errore di connessione, il problema è quasi certamente nella rete o nel proxy, non nello script. In quel caso la strada corretta è usare il proxy di sistema o quello della sessione, non tentare workaround opachi. Un esempio di impostazione temporanea per la sessione è questo:

$proxy = New-Object System.Net.WebProxy('http://proxy.example.local:8080')
[System.Net.WebRequest]::DefaultWebProxy = $proxy
[System.Net.WebRequest]::DefaultWebProxy.Credentials = [System.Net.CredentialCache]::DefaultCredentials

Se il proxy richiede autenticazione diversa da quella del contesto corrente, non inserire credenziali in chiaro nello script. Usa un account di servizio dedicato, una vault aziendale o un meccanismo di secret management approvato. Su un server esposto o condiviso, questa è una differenza concreta tra una procedura sostenibile e un debito tecnico che prima o poi si paga.

Verifica post-installazione: non fermarti a “choco -v”

La verifica minima non è solo vedere la versione. Devi controllare che Chocolatey riesca a parlare con il repository, che la cache locale sia scrivibile e che l’utente amministratore possa installare un pacchetto semplice. Un test leggero è installare un pacchetto noto e poco invasivo, ad esempio 7-Zip, oppure limitarti a interrogare il repository.

choco source list
choco search 7zip --limit-output

Se la ricerca restituisce risultati, il canale verso il repository funziona. Se vuoi fare un test completo, installa un pacchetto non critico:

choco install 7zip -y

La presenza del flag -y evita interazioni manuali, utile in automazione. In ambienti di produzione, però, l’installazione automatica va accompagnata da policy di approvazione e da un repository interno se vuoi mantenere controllo sulle versioni. Chocolatey pubblico va bene per bootstrap e test; per un parco server serio, meglio un feed interno o un proxy repository con pacchetti approvati.

Installazione silenziosa e automazione con script

Se devi portare Chocolatey su più server, il vero valore è nella ripetibilità. Uno script PowerShell controllato è preferibile a un copia-incolla manuale. Il blocco minimo sotto forza TLS 1.2, scarica lo script ufficiale ed esegue l’installazione. Va usato in una sessione elevata e con una policy temporanea, non permanente.

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

Se fai automazione con strumenti come SCCM, Ansible, Intune o una semplice GPO con script di startup, la parte importante è conservare il log dell’esecuzione. Non basta sapere che “ha girato”: devi avere un file di log o un output di task scheduler per capire dove si è fermato in caso di errore.

In un runbook serio, il criterio di successo è chiaro: il comando choco -v risponde, il repository è consultabile, il pacchetto di test si installa e non compaiono errori di TLS o di accesso al filesystem.

Hardening minimo dopo l’installazione

Una volta installato, il lavoro non è finito. Chocolatey può essere usato in modo ordinato o in modo caotico; la differenza la fanno poche scelte operative. Primo: limita chi può eseguire installazioni. Secondo: definisci una fonte pacchetti affidabile. Terzo: evita che gli script di post-installazione facciano cose non previste senza audit.

Alcune verifiche utili:

choco feature list
choco source list
Get-ChildItem $env:ChocolateyInstall -Force

Se in azienda vuoi ridurre la superficie d’attacco, la scelta più sensata è usare un repository interno e disabilitare o limitare le sorgenti esterne sui server di produzione. Non è solo una questione di sicurezza, ma anche di stabilità: se il repository pubblico cambia disponibilità o policy, non vuoi che un deploy urgente resti bloccato da un endpoint esterno.

Per i server esposti a più operatori, documenta almeno: chi può lanciare choco install, quale feed è autorizzato, dove finiscono i log e come si revoca un pacchetto problematico. Se usi variabili d’ambiente o file di configurazione, versionali in modo controllato e non salvare token o password in chiaro.

Troubleshooting: errori tipici e lettura corretta

Quando l’installazione fallisce, conviene leggere il sintomo prima della soluzione. Un errore TLS indica quasi sempre protocollo o trust store. Un errore 403/407 punta a proxy o autenticazione. Un errore di scrittura nel path locale suggerisce privilegi o antivirus aggressivo. Un download che si interrompe a metà, invece, può essere una rete instabile o un ispezionatore SSL che rompe il flusso.

Per raccogliere un minimo di evidenza, ripeti il bootstrap con output verboso e conserva la console:

powershell -NoProfile -ExecutionPolicy Bypass -Command "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12; iex ((New-Object System.Net.WebClient).DownloadString('https://community.chocolatey.org/install.ps1'))"

Se il problema è un proxy, non improvvisare bypass globali. Se invece il problema è il firewall, verifica il flusso verso il dominio del repository e la risoluzione DNS. Un test sintetico utile è:

nslookup community.chocolatey.org
Test-NetConnection community.chocolatey.org -Port 443

Su Server 2012, questi controlli ti fanno risparmiare tempo perché separano subito il problema di rete dal problema applicativo. Il punto è sempre lo stesso: prima raccolta evidenze, poi modifica. Se cambi troppe variabili insieme, non saprai mai quale ha davvero risolto.

Rimozione, aggiornamento e rollback operativo

Chocolatey non richiede una disinstallazione complicata, ma anche qui serve disciplina. Se hai installato solo il client e non hai ancora automatizzato pacchetti, il rollback è semplice: rimuovi il percorso, pulisci le variabili d’ambiente e verifica che nessun job dipenda da choco. In ambienti più strutturati, il rollback vero è riportare il server allo stato precedente tramite snapshot o backup, non “cancellare una cartella” e sperare che basti.

Se vuoi verificare l’effettiva presenza dei componenti prima di decidere il rollback, controlla il path e i file principali:

where choco
Get-ChildItem C:\ProgramData\chocolatey -Force

Se devi aggiornare Chocolatey, ricordati che il client può autoaggiornarsi, ma in produzione questo va trattato come qualsiasi altra modifica software: finestra di manutenzione, verifica del repository, e possibilità di tornare indietro. L’aggiornamento non è un atto neutro se il server ospita automazioni o pipeline dipendenti da una specifica versione.

Scelta pratica tra Server 2012 e 2019

Su Windows Server 2019 la strada è lineare: shell elevata, TLS 1.2, installazione, verifica. Su Windows Server 2012 e 2012 R2 devi aggiungere una valutazione del contesto: patch level, proxy, policy di sicurezza e compatibilità della piattaforma. Se il server è vecchio ma ancora in esercizio, Chocolatey può aiutarti a governare il software installato; non sostituisce però la necessità di tenere il sistema aggiornato e supportato per quanto possibile.

In pratica, la regola che funziona meglio è questa: installa Chocolatey solo se hai già chiaro come governerai sorgenti, approvazioni, log e rollback. Se questi quattro elementi mancano, il tool non risolve il problema operativo, lo sposta semplicemente un livello più in là.

Assunzioni: i comandi sono eseguiti da una console amministrativa su Windows Server 2012/2019 con accesso HTTPS al repository Chocolatey; in ambienti con proxy o feed interni, sostituisci l’endpoint pubblico con quello autorizzato.